Ideal OTeL Configurations for Bare-Metal and Kubernetes (Part 2)

Search for a command to run...

No comments yet. Be the first to comment.
An SRE agent starts every investigation missing the same thing: a model of how the system is wired. Which services call which, what each one reads from, where workloads are co-resident, how much redun

OpenClaw's role as a constantly running agent that performs various encoded tasks has been exciting. Its focus on prioritizing communication channels and its strong emphasis on sessions are particularly noteworthy. However, security concerns have inc...

As AI agents flood the enterprise software landscape, companies must integrate their existing data hubs. In the data analytics world, this can include platforms like Snowflake. In CRM / front-office land, platforms like Salesforce. In Observability, ...

There have been several posts about AI SRE solutions being deployed in a "fire and forget" manner, even for complex setups. One post that tested this idea is from the Clickhouse team. They concluded that "Models are not ready" and needed guidance thr...

A while ago, we explored different LLM use cases through “Skillet”. During our experiments, we quickly realized the advantages of using tools, precise integration with observability data sources, and sparse tokenization. The ecosystem has been evolvi...

In Part 1, we explored the hostmetricsreceiver as an excellent way to get system metrics. Moving onto a K8s environment, we must consider the importance of additional metadata and the importance of metrics at a component level. Before diving into the conventional ways of configuring (verbose configurations), one can utilize ready-made presets via Helm. Here is an example values.yaml:
opentelemetry-collector:
presets:
logsCollection:
enabled: true
kubernetesAttributes:
enabled: true
kubeletMetrics:
enabled: true
hostMetrics:
enabled: true
clusterMetrics:
enabled: true
kubernetesEvents:
enabled: true
The above concisely covers most of what observability practitioners would want to cover. We can dive into each individually.
The logsCollection preset is essentially the filelogreceiver. By default it will collect /var/log/pods/*/*/*.log
The Kubernetes Attributes Processor is probably considered the most important component. It specifically adds Kubernetes context to telemetry for effective correlation and filtration. Additional options should also be examined for further metadata extraction:
opentelemetry-collector:
presets:
kubernetesAttributes:
enabled: true
# When enabled the processor will extra all labels for an associated pod and add them as resource attributes.
# The label's exact name will be the key.
extractAllPodLabels: false
# When enabled the processor will extra all annotations for an associated pod and add them as resource attributes.
# The annotation's exact name will be the key.
extractAllPodAnnotations: false
This is recommended for most deployments to maximize metadata decoration. In our minimal example we can expect these attributes by default:
k8s.pod.uid
k8s.pod.start_time
This preset adds the kubeletstatsreceiver to the configuration and collects node, pod and container metrics. The metrics definitions, such as container.cpu.time, k8s.pod.cpu.utilization can be found here.
Similar to Part 1, we can get details about the host (or node) by adding a hostmetricsreceiver
Cluster level metrics can be collected by enabling this (adding a k8sclusterreceiver). Similarly to Kublet Metrics, we have definitions of metrics here
This adds the k8sobjectsreceiver and pulls/watches (via the K8s API) for K8s events. This is outputted as individual logs in the collector pipeline.
Beyond the presets, within the values.yaml, one can provide specific configurations in the config section:
opentelemetry-collector:
presets:
kubernetesAttributes:
enabled: true
kubeletMetrics:
enabled: true
hostMetrics:
enabled: true
clusterMetrics:
enabled: true
kubernetesEvents:
enabled: true
config:
receivers:
kubeletstats:
insecure_skip_verify: true
extensions:
bearertokenauth:
token: $API_KEY
exporters:
otlphttp/example:
endpoint: "https://intake.test_domain.com"
auth:
authenticator: bearertokenauth
service:
pipelines:
traces:
exporters: [spanmetrics, otlphttp/example]
metrics:
exporters: [otlphttp/example]
logs:
exporters: [otlphttp/example]
extensions: [health_check, bearertokenauth]
telemetry:
metrics:
level: "none"
In this configuration example, we are defining exporter configurations with authentication. Additionally, we are modifying the kubeletstatsreceiver from the preset, and adding a config option (insecure_skip_verify: true).
In Part 1 and 2, we introduce ideal configuration options that add health metrics and attributes that can benefit observability practitioners as soon as they deploy an OTeL collector. In future blog posts, we will continue to explore configuration profiles.