Architecture

ITRS Analytics components Copied

ITRS Analytics is composed of the following components:

• Platform — the core of ITRS Analytics that ingests data from various sources, stores it, and provides gRPC interfaces for Apps.
• Web Console — a special app used to provide a common UI (user interface) for all ITRS Analytics apps.
• Apps — modular applications that provide different monitoring and analysis capabilities.

Platform Copied

The ITRS Analytics platform consists of an operator, which manages services across the whole Kubernetes cluster, and at least one ITRS Analytics instance that provides platform functionality.

You can run multiple ITRS Analytics instances in different namespaces to separate different concerns. Any ITRS Analytics apps must be installed in the same namespace as their Platform instance.

Additionally, ITRS Analytics is capable of coexisting with other applications running in the same cluster.

App design Copied

An App typically consists of the following components:

• A Collection Agent plugin.
• An App backend that fetches data from the Platform and applies any business logic to process that data.
• A user interface plugin for the Web Console.

When you install a new App using a Helm chart the backend and user interface are automatically connected to the Platform and Webconsole. However, you may need to setup new Collection Agent plugins to collect metrics.

Geneos Copied

In general, ITRS Analytics works with other parts of the Geneos system to collect data. Metrics can be published to ITRS Analytics as unmodified Collection Agent datapoints or in legacy Geneos formats. In either case, you must configure your Gateway to publish data to ITRS Analytics. To do this, follow the instructions in the Gateway ITRS Analytics Quickstart.

Data model Copied

The canonical ITRS Analytics data model is an internal, normalised, model for representing data that is collected, processed, or stored by the ITRS Analytics platform.

Entities Copied

An Entity is an emitter (whether actual, or conceptual) of observable data and is uniquely defined by a dictionary of unordered dimensions (key/value pairs).

As a result:

1. Entities are considered identical if and only if their dimensions are identical.
2. Entities with non-identical dimensions are considered distinct.

This strict definition ensures that the way ITRS Analytics treats observable data is independent of how data is collected or processed and allows ITRS Analytics to maintain the notion of Entity identification across multiple samples.

Different associations between and grouping of different entities can be obtained by slicing and dicing dimensions in multiple ways.

Datapoints Copied

Datapoints are the format used by ITRS Analytics and other tools to communicate. A datapoint represents a single piece of observable data emitted by, or collected from, an Entity.

A datapoint is associated exactly with a single Entity in a self-describing way. That is, every datapoint contains the fully qualified dimensions of the emitting Entity rather than an internal or abbreviated representation.

Note that each datapoint:

• Has a name (mandatory).
• Has a namespace which defines the uniqueness domain for all the time series in that namespace. It is optional at collection time (ideally the namespace is set by the collector) but is filled in by the first downstream consumer that knows its own namespace.
• Has a combination of dimensions, metric name, and namespace that uniquely identifies a datapoint time series.
• Has properties (optional). Properties are arbitrary key/value pairs which may be attached on a per data point basis for the purpose of conveying some internal context to downstream components.

Datapoint types Copied

• Counter: Incrementing long integer value.
• Gauge: Arbitrary floating-point value.
• GenericHistogram: Records floating-point or integer values with min/max/count/percentile statistics.
• Attribute: Key/Value that describes an Entity — its value rarely or never changes.
• GenericEvent: Event emitted by an Entity containing a message, severity and count.
• LogEvent: Log message emitted by an application containing a message, severity and count.
• EntityGroupSnapshot: Point-in-time snapshot of a group of related entities.
• DownsampledMetric: Down-sampled, aggregate metric values over a time frame containing min/max/count/first/last/percentile statistics.
• StatusMetric: A text status that may change over time.

Timestamps Copied

In order to make datapoints amenable to processing as a time series, datapoints are transmitted regardless of how they are collected or whether they have changed over an interval. This means that consecutive datapoints in time may be identical except for their timestamp fields.

Note the following:

• Datapoint timestamps represent nanoseconds since the Linux epoch.
• Event timestamp: The timestamp at which the datapoint was emitted by the Entity (if known).
• Observed timestamp: The timestamp at which the datapoint was collected by an ITRS component.