OpenTelemetry is a set of APIs, SDKs, tooling, and integrations that are designed for the creation and management of telemetry data such as traces, metrics, and logs. One of the main components of OpenTelemetry, or OTel for short, is the OpenTelemetry Collector. The OpenTelemetry Collector, or Otel Collector, is a vendor-agnostic proxy that can receive, process, and export telemetry data.

Properly leveraging telemetry is a true game-changer for any IT department looking to optimize and stabilize its systems. Telemetry provides the first step to answering the all-important question, “What’s happening in my network?” It’s your eye into the inner workings of your system, giving you a view into how different components are performing.

The recent release of Grafana 8.5 marks the start of enabling the jump from traces directly to Splunk logs. It’s a big leap that now allows you to draw a straight line between your traces — whether they are coming from Tempo, Zipkin, or Jaeger — to even more third-party logging data, all from the comfort of your traces view. Previously, the Grafana trace to logs enablement included only Loki logs.

Application Monitoring, or Application Tracing, is an important piece of Observability within your application and stack. Application tracing involves installing an API and/or SDK in your application which then instruments, or wraps your application code with other code that measures the time spent in certain areas of your code, and adds important contextual information to the traces.

In a previous blog post, Adam Quan presented a great introduction to setting up observability for a Spring Boot application. For metrics, Adam used the Prometheus Java Client library and showed how to link metrics and traces using exemplars. However, the Prometheus Java Client library is not the only way to get metrics out of a Spring Boot app. One alternative is to use the OpenTelemetry Java instrumentation agent for exposing Spring’s metrics directly in OpenTelemetry format.

As more organizations adopt cloud-native technologies and microservices-based architectures, application troubleshooting is becoming increasingly complex. With so many moving parts in an environment that is both dynamic and distributed, it is difficult to get the full picture. Yet complete visibility is crucial in order to find and fix issues quickly — especially ones that impact the bottom line.

observIQ’s OpenTelemetry members contributed Riak metric monitoring support to OpenTelemetry! You can now monitor your Riak agent performance with OpenTelemetry, and deploy simply with the oIQ OpenTelemetry Collector. You can add the Riak metric receiver to any OpenTelemetry collector. This post demonstrates a configuration for shipping metrics to Google Cloud Operations with OpenTelemetry components.

Grafana Tempo 1.4 has been released and features a new optional component: metrics generator, which automatically generates RED metrics and service graphs from your traces. We’re actively rolling out the metrics-generator service to our own Grafana Cloud offering and are looking for Grafana Cloud Traces customers wanting early access. If interested, you can email our support team for more details.

As systems get ever more complicated with more layers in the application stack, it can become more difficult to keep track of what is happening at all of the different, discrete levels and this is where distributed tracing comes into play.