Getting Started with the OpenTelemetry Helm Chart in K8s

Managing observability in cloud-native environments can feel like juggling a thousand things at once. OpenTelemetry makes this easier by becoming a favorite among developers for collecting, processing, and exporting telemetry data without breaking a sweat.

Now, let’s talk about the OpenTelemetry Helm Chart. It’s like having a shortcut button for deploying OpenTelemetry in Kubernetes. Instead of wrestling with configurations, you get a smoother way to monitor your applications and keep things running smoothly.

In this blog, we’ll break down how the Helm Chart makes life easier, the perks it brings, and how you can get rolling with it. Plus, we’ll throw in some best practices and tips to give you an extra edge.

What is OpenTelemetry?

Before getting into the Helm Chart details, let’s revisit OpenTelemetry.

It’s an open-source framework that equips developers with APIs, libraries, agents, and instrumentation to capture telemetry data—spanning traces, metrics, and logs—from their applications.

Designed to be vendor-agnostic, OpenTelemetry integrates with a variety of backends, such as Prometheus, Jaeger, and others, ensuring flexibility and compatibility for diverse observability needs.

For more on setting up observability in Kubernetes with OpenTelemetry, check out our detailed guide on using the OpenTelemetry Operator here.

Why Use the OpenTelemetry Helm Chart?

Helm charts simplify managing Kubernetes applications by packaging configurations and deployment logic into a reusable format.

The OpenTelemetry Helm Chart uses this convenience to automate the deployment of OpenTelemetry components within a Kubernetes cluster.

Here’s why it’s a key tool:

1. Simplified Deployment

Deploying OpenTelemetry components manually in Kubernetes can involve a steep learning curve, with numerous configurations and dependencies to manage.

The Helm Chart eliminates this complexity by offering pre-configured templates for the OpenTelemetry Collector, Agent, and Exporters.

It reduces the risk of errors and saves time, enabling developers to focus on refining their telemetry pipelines rather than wrestling with deployment hurdles.

To learn more about monitoring with the OpenTelemetry Collector, check out our full guide here.

2. Uniformity Across Clusters

For cloud-native observability, consistency is crucial. The Helm Chart ensures that your deployments maintain identical configurations across different Kubernetes clusters.

This uniformity guarantees that telemetry data is collected, processed, and exported predictably, regardless of the environment.

3. Flexible Configuration Options

While the Helm Chart provides ready-to-use defaults, it also supports extensive customization.

By adjusting the values.yaml file, you can fine-tune your deployment to meet specific requirements. Configure exporters, modify resource requests and limits or enable optional OpenTelemetry components—all while retaining the efficiency of a template-based deployment process.

4. Built-in Scalability

As Kubernetes workloads scale, so does the volume of telemetry data. The OpenTelemetry Helm Chart is designed to handle this growth, providing a robust framework to manage increased metrics and trace data seamlessly.

Its scalability ensures that your observability setup remains performant and reliable, even as your infrastructure expands.

For insights on capturing host metrics with OpenTelemetry, check out our detailed guide here.

How to Install the OpenTelemetry Helm Chart

Step 1: Add the OpenTelemetry Helm Repository

Start by adding the OpenTelemetry Helm Chart repository to your Helm configuration.

Run the following commands to add the repository and update your Helm repository list:

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

Step 2: Install the Chart

Once the repository is added, you can install the chart using the following command:

helm install opentelemetry open-telemetry/opentelemetry-operator

This will deploy the OpenTelemetry operator, which takes care of managing OpenTelemetry resources within your Kubernetes cluster.

Step 3: Customize the Configuration

The values.yaml file lets you tailor OpenTelemetry components to meet your specific requirements. Here are some common configuration options:

Enable specific exporters: Specify exporters such as Jaeger, Prometheus, or Zipkin to handle tracing and metrics.
Configure resource requests and limits: Adjust CPU and memory allocations to align with your cluster’s resource availability.
Enable sampling: Define trace sampling configurations to control the amount of telemetry data sent to your chosen backend.

💡

For a step-by-step guide on instrumenting your Kubernetes cluster with OpenTelemetry and sending logs to Last9, check out the full documentation here.

Step 4: Verify the Installation

After the installation, verify the deployment status to ensure everything is working as expected. Use the following command:

kubectl get pods -n opentelemetry

This will display the running OpenTelemetry components, confirming they are ready to collect and export telemetry data.

What Are Presets for Metrics and Logs?

In Kubernetes environments, presets act like templates, saving you from the hassle of manual setup when collecting metrics and logs. These pre-configured settings help you gather critical data for common use cases efficiently. Here’s an overview of the available presets:

Logs

Presets for logs simplify the collection of application logs, system logs, and container logs. With minimal effort, you can ensure the right logs are captured, simplifying your troubleshooting and observability workflows.

Kubernetes Attributes

Presets enable effortless collection of Kubernetes-specific attributes such as pod names, namespaces, labels, and annotations. These attributes help you correlate metrics and logs with specific resources, making it easier to understand what’s happening in your clusters.

Kubelet Metrics

The kubelet is responsible for node-level metrics and presets and configures the collection of these automatically. This ensures that critical metrics, like node health and resource utilization, are available without manual configuration.

For a guide on Kubernetes log collection using the OpenTelemetry FileLog receiver, check out the full article here.

Cluster Metrics

These presets focus on the overall health and performance of your Kubernetes clusters. They include metrics such as node resource usage, pod statuses, and cluster-wide events, giving you a high-level view of your environment’s state.

Kubernetes Events

Presets for Kubernetes events help you track significant cluster activities, like pod failures, scaling events, or deployments. They make sure these insights are logged without requiring additional setup.

Host Metrics

Presets for host metrics capture key performance indicators for the underlying infrastructure, including CPU, memory, disk, and network usage. This ensures that you’re monitoring the health of your hosts alongside your Kubernetes resources.

Why Use Presets?

These presets provide a strong starting point for your observability strategy. They cater to common monitoring scenarios, enabling you to quickly set up telemetry collection and focus on analyzing and acting on the data.

To learn how to use Jaeger with OpenTelemetry, check out our detailed guide here.

OpenTelemetry Collector Structure and Environment

The OpenTelemetry Collector is a versatile tool designed for collecting, processing, and exporting telemetry data, including metrics, logs, and traces. Its structure and deployment in Kubernetes environments are key to an effective observability setup.

Here’s a detailed look at its components and interactions:

OpenTelemetry Collector Structure and Environment

Collector Components

Receivers
Receivers act as the entry points for telemetry data. The Collector supports various receivers for gathering data from different sources. In Kubernetes, common receivers include:
- Prometheus for scraping metrics.
- Kubernetes API servers for cluster-specific data.
- Logging systems for collecting logs from pods and system components.
Processors
Processors handle data after it’s received, enabling modifications and enhancements such as:
- Batching data for efficient transmission.
- Filtering unwanted data.
- Enriching telemetry with additional context.
Exporters
Exporters send processed data to external destinations like:
- Time-series databases (e.g., Prometheus).
- Visualization tools (e.g., Grafana).
- Cloud-based monitoring platforms.
  These components are essential for integrating telemetry data into your observability ecosystem.

Collector Deployment in Kubernetes

DaemonSet
Deploying the Collector as a DaemonSet ensures it runs on every node in the cluster. This setup is ideal for collecting node-level and pod-level telemetry data across the entire infrastructure.
StatefulSets or Deployments
For centralized telemetry collection, the Collector can be deployed using StatefulSets or Deployments. These approaches allow for a fixed number of replicas with persistent configurations.

Collector Configurations

The Collector’s configuration is defined in a YAML file, specifying the receivers, processors, and exporters. In Kubernetes, this file is typically managed as a ConfigMap or a secret, enabling seamless updates across the cluster. Examples of Kubernetes-specific configurations include:

Scraping Kubernetes metrics and logs.
Accessing the Kubernetes API for real-time cluster data.

Environment Variables and Resource Allocation

The Collector’s performance relies heavily on its environment settings:

Resource Allocation: Kubernetes lets you define CPU and memory limits for Collector pods to ensure smooth data handling without overwhelming the cluster.
Environment Variables: Use environment variables to manage settings like authentication, proxy configurations, and exporter-specific options. Kubernetes allows integration with secrets for securely handling sensitive details, such as API keys or tokens.

Interactivity with Kubernetes

The Collector interacts extensively with the Kubernetes API to gather telemetry data about pods, nodes, and cluster resources. It collects logs from applications and system components, acting as a critical element of your observability stack in Kubernetes.

Conclusion

The OpenTelemetry Helm Chart is a great way to simplify observability in Kubernetes. It’s easy to deploy, scales well, and offers the flexibility needed for cloud-native environments.

If you're looking to tie all your telemetry data together, Last9 can help bring metrics, logs, and traces into a single view, making it easier to track down issues, manage alerts, and keep your systems running smoothly.

Probo Cuts Monitoring Costs by 90% with Last9

It integrates easily with tools like Prometheus and OpenTelemetry, giving you better visibility into performance and errors—especially in complex, distributed setups.

Schedule a demo with us to know more!