Exploring the Landscape of Observability: OpenTelemetry, MetricsHub, and More

OpenTelemetry, Prometheus, Grafana Alloy, Loki, and other big names in observability can seem daunting to newcomers. This article demystifies the observability landscape, explains MetricsHub's role in the OpenTelemetry ecosystem, and explores its integration with other components.

OpenTelemetry: The New Standard in Observability

Understanding OpenTelemetry

OpenTelemetry has emerged as a new standard in observability, yet it is not a one-size-fits-all solution. So, what exactly does it do and how does it work?

To start, the application we aim to monitor must be made observable through instrumentation using the OpenTelemetry SDK available in languages like Java, Go, JS, and Rust. When an application is instrumented with OpenTelemetry, it sends telemetry signals — logs, metrics, and traces — via the OTLP protocol over HTTPS or gRPC.

Diagram of an application instrumented with OpenTelemetry sending metrics to an OpenTelemetry Collector

These signals typically go to an OpenTelemetry Collector, a versatile agent developed by the OpenTelemetry community. This collector processes the incoming logs, metrics, and traces before exporting them to various observability platforms, either via OTLP or other specific APIs (like Prometheus or Datadog).

Ultimately, these data points are stored within an observability platform where users can manage alerts, craft dashboards, and perform a range of operational tasks.

Role of the OpenTelemetry Collector

Think of the OpenTelemetry Collector as a proxy or aggregator for telemetry data. While applications instrumented with OpenTelemetry can send data directly to observability platforms (if they natively support OTLP), it’s often advisable to use one or several collectors to:

  1. Aggregate signals from various applications.
  2. Process data (e.g., adding attributes, filtering, renaming metrics).
  3. Relay processed data to one or more observability platforms.

Much like Linux, the OpenTelemetry community offers several distributions of the collector, each featuring different components and capabilities:

Distribution Description
OpenTelemetry Collector Core distribution, primarily supporting OTLP and Prometheus.
OpenTelemetry Collector Contrib Comprehensive distribution with all components provided by the community and various observability vendors.
OpenTelemetry Collector for Kubernetes Tailored for monitoring Kubernetes and services within Kubernetes environments.

Developers are also free to create their own distribution using the OpenTelemetry Collector builder, with several third-party vendors offering supported versions.

Major Observability Platforms Supporting OpenTelemetry

Most of the monitoring and observability vendors offer excellent support for OpenTelemetry. Here’s a summary of the most prominent platforms, including long-standing tools as well as newer and emerging platforms that are gaining traction for their performance or unique features:

Vendor Name Platform Name (with URL) OpenTelemetry Support (Metrics)
Amazon Web Services AWS CloudWatch Through exporter
Datadog Datadog Through exporter
Dynatrace Dynatrace Native support
Elastic Elastic APM Native support
Google Google Cloud’s Operations Suite Native support
Grafana Grafana Cloud Native support through Grafana Alloy
Honeycomb Honeycomb Native support
InfluxData InfluxDB Through exporter
Microsoft Azure Monitor Native support
New Relic New Relic One Native support
Prometheus Prometheus Native support in v3.x; earlier versions through exporter
Red Hat Red Hat OpenShift Observability Through exporter for Prometheus
Splunk Splunk Observability (formerly SignalFx) Native support
ServiceNow ServiceNow Cloud Observability (formerly LightStep) Native support
Sumo Logic Sumo Logic Continuous Intelligence Through exporter
VictoriaMetrics VictoriaMetrics Native support (with specific settings)

Integrating Non-OpenTelemetry Metrics into the OpenTelemetry Ecosystem

What if your existing applications aren’t developed with OpenTelemetry? How can you gather performance metrics from your systems, databases, or any part of your infrastructure, including older network devices or storage systems? Or what if you need to pull specific business metrics from an external service?

Receivers in OpenTelemetry Collector

OpenTelemetry Collector Contrib does provide a bunch of receivers to incorporate metrics, logs, and traces from non-OpenTelemetry applications and systems, notably to import data from other monitoring and observability platforms, like Prometheus, AWS X-Ray, InfluxDB, syslog, etc.

There are also a few receivers that are actually collectors for various sources: system metrics, databases, SNMP, Windows Event Logs, etc. The problem is that each receiver has its own logic, its own configuration, its own set of metrics, attributes, etc. and it may become difficult to configure so many different receivers to cover your use cases.

Bridging Gaps with MetricsHub

MetricsHub acts as an agent within your infrastructure, pulling data from systems and applications through various protocols — SNMP, WMI, REST APIs, or even SSH for CLI interfaces.

Diagram of the MetricsHub agent collecting data from systems and applications and pushing metrics to an observability platforms

Equipped with built-in connectors for Windows, Linux, and hardware monitoring, the Enterprise version of MetricsHub includes over 200 connectors for enterprise infrastructure management — from Dell EMC and NetApp to HPE — spanning servers to storage systems and databases.

MetricsHub allows for custom configuration to pull metrics via SNMP, CLI outputs, HTTP/REST responses, WMI, WBEM, etc., enabling it to meet any specific requirements you might have and integrate seamlessly with OpenTelemetry.

Metrics collected by MetricsHub are then pushed to any OpenTelemetry-compatible observability platform, using an OpenTelemetry Collector as a bridge if necessary.

MetricsHub in Combination with Other Collectors and Agents

MetricsHub and the OpenTelemetry Collector

MetricsHub utilizes the OTLP protocol to transmit data, akin to applications instrumented with OpenTelemetry. Although MetricsHub can directly send metrics to observability platforms that support OpenTelemetry natively, it is typically recommended in production environments to use an OpenTelemetry Collector to:

  • Aggregate metrics across different sources.
  • Serve as a proxy, particularly in firewall-secured areas.
  • Manage error handling, including retries.

Bundled with OpenTelemetry Collector Contrib, MetricsHub Enterprise facilitates connections to over 30 different observability platforms, effectively replacing the need for multiple specific receivers within the OpenTelemetry Collector Contrib that handle various protocol metrics.

MetricsHub and Prometheus

Version 2.x of Prometheus

Direct integration between MetricsHub and Prometheus v2.x is not supported. Instead, to forward metrics to Prometheus, the OpenTelemetry Collector is employed along with its Prometheus exporters:

Version 3.x of Prometheus

The upcoming September 2024 release of Prometheus v3.x will support OTLP metrics natively, enabling MetricsHub to send metrics directly without the intermediary of an OpenTelemetry Collector. Prior to this version, OTLP metric ingestion is possible through a specific feature flag.

Prometheus v3.x also introduces support for UTF-8 characters in metric names, eliminating the need for certain naming conversions. The details of how these metrics are processed in the new version remain under discussion.

MetricsHub and Grafana Alloy

Grafana introduced Grafana Alloy in April 2024, a specialized distribution of the OpenTelemetry Collector designed to enhance integration within the Grafana ecosystem. Grafana Alloy can seamlessly ingest metrics collected by MetricsHub, making it an ideal solution for environments using Grafana tools.

MetricsHub and Datadog

The Datadog Agent supports ingesting OpenTelemetry metrics, logs, and traces, providing a straightforward integration path for MetricsHub metrics. To connect MetricsHub with Datadog:

  1. Install the Datadog Agent alongside MetricsHub (they can operate on the same host).
  2. Enable OTLP ingestion on the Datadog Agent.
  3. Configure MetricsHub to target the OTLP endpoint of the Datadog Agent.

Alternatively, the OpenTelemetry Collector Contrib also includes a Datadog exporter, offering similar integration capabilities.

MetricsHub and Fluent Bit

Fluent Bit now features an OpenTelemetry input plugin, which facilitates the ingestion of logs, metrics, and traces from OpenTelemetry. With this plugin, MetricsHub can be configured to push metrics directly to Fluent Bit, leveraging Fluent Bit’s extensive output plugin system to forward data to various destinations.

Conclusion

As we’ve explored the capabilities of OpenTelemetry and MetricsHub throughout this article, it’s clear that these tools are more than just buzzwords in the tech community. They are fundamentally changing how we approach the complex task of monitoring and observing our IT environments.

What stands out most is the synergy between these tools. MetricsHub complements the flexibility of the OpenTelemetry Collector, reflecting a shift towards more unified and streamlined monitoring solutions. This approach not only simplifies the integration of different technologies but also enhances the overall efficiency of our monitoring strategies.

Diagram showing the combination of MetricsHub and OpenTelemetry Collector to monitor applications and infrastructure

As technology landscapes become increasingly complex, the role of sophisticated observability tools becomes indispensable. They ensure that we can manage vast, distributed systems not just effectively, but also in a way that aligns with broader business objectives. Improved performance, reliability, and customer satisfaction are just a few of the benefits of a well-orchestrated observability setup.

Adopting MetricsHub alongside OpenTelemetry standards can elevate your monitoring capabilities, allowing you to not just cope with, but capitalize on the complexities of modern IT infrastructures. The integration and scalability of your observability tools are key to this process, empowering your teams to focus more on innovation and growth.

As the observability landscape continues to evolve, staying informed and adaptable is crucial. Embracing these changes will not only streamline your monitoring processes but will also position your organization to thrive in a rapidly changing technological environment.

In summary, diving into the world of observability with tools like MetricsHub and OpenTelemetry isn’t just about keeping up: it’s about setting the pace, ensuring your monitoring practices are as dynamic and forward-thinking as the rest of your operations.

Share this post