Architecture

Obcerv components Copied

The Obcerv system is composed of the following components:

• Platform — the core of Obcerv 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 Obcerv Apps.
• Apps — modular applications that provide different monitoring and analysis capabilities.

Platform Copied

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

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

Additionally, Obcerv 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, Obcerv works with other parts of the Geneos system to collect data. Metrics can be published to Obcerv as unmodified Collection Agent datapoints or in legacy Geneos formats. In either case, you must configure your Gateway to publish data to Obcerv. To do this, follow the instructions in the Gateway Obcerv Quickstart.

Data model Copied

The canonical Obcerv data model is an internal, normalised, model for representing data that is collected, processed, or stored by the Obcerv 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 Obcerv treats observable data is independent of how data is collected or processed and allows Obcerv 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 Obcerv 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.