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.
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:
- Aggregate signals from various applications.
- Process data (e.g., adding attributes, filtering, renaming metrics).
- 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 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.
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:
- Prometheus Exporter, which provides a
/metrics
endpoint featuring all metrics collected by MetricsHub. - Prometheus Remote Write Exporter, recommended for sending MetricsHub’s metrics to a Prometheus server efficiently.
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:
- Install the Datadog Agent alongside MetricsHub (they can operate on the same host).
- Enable OTLP ingestion on the Datadog Agent.
- 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.
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.