Beeks' mission is to bring cloud-like flexibility to capital markets co-location and on-premise environments.

One of the key gaps in the generic public cloud offerings is around observability. Capital markets clients require precision timing, from the wire, in order to manage their trading and pricing activity. This has not been available in the public cloud.

Looking at the challenge of observability for capital markets from the other perspective, existing widespread capital markets observability solutions have often been developed in proprietary silos which limit interoperability with other tools. The capital markets -specific tools are often lacking in open interfaces and industry engagement, and have not evolved to include some useful improvements to observability that have been pioneered by organisations such as the Cloud Native Computing Foundation (CNCF) project.

Beeks Analytics aims to bridge these two worlds by bringing the CNCF outlook to our capital markets analytics tools. This will provide the following benefits for users:

  • Monitor cloud-native style deployments (such as Kubernetes clusters and public cloud deployments) and capital markets colo and on-premises deployments using consistent dashboards and monitoring techniques.

  • Consistent language for describing the monitoring and data exhaust requirements for observability tooling, whether we’re talking about public cloud deployments, colo, or on-premise deployments.

See the OpenTelemetry website for more information about the project.

OpenTelemetry overview

The public cloud is starting to address some of these challenges.

OpenTelemetry is an observability framework for instrumenting, generating, collecting, and exporting telemetry data.

OpenTelemetry allows you to learn a single set of APIs and conventions for accessing information about your application.

Although the OpenTelemetry project’s main focus is around cloud-native software instrumentation, we believe that extending this framework to enable combined application-oriented visibility of the underlying infrastructure performance is a key requirement for performance-sensitive capital markets deployments, which require minimally invasive monitoring with high precision timing and without application overhead.

Key OpenTelemetry terminology

Observability allows users to understand a system’s performance from the outside. In order to do this, the system must be properly instrumented by sending signals that communicate its performance. OpenTelemetry breaks these signals down into three main areas:

  • Logs
    A timestamped message emitted by services or other components. These are not necessarily related to a specific business transaction.

  • Span
    A span represents a unit of work or operation. A log may be included within a span, but a span adds metadata ('Attributes') to provide information about the operation it tracks.

  • Distributed Traces (more commonly known as a Trace)
    A distribute trace records the path taken by business requests as they propagate through multi-service architecture. A trace is made of one or more spans.

In addition, open telemetry often talks about metrics - a metric is a measurement of a service captured at runtime.

The integration points that our Core Data Feed makes available are based around the OpenTelemetry distributed tracing concepts.

Each Agent Event can be considered a Span.

Each Item can be considered a Trace.

For more background information on Agent Events and Items, see the Analytics Concepts Guide.