OpenTelemetry Collector Contrib

The k8sattributes processor automatically discovers Kubernetes resources (pods), extracts metadata from them, and adds that metadata to the resource attributes of spans, metrics, and logs. It uses the Kubernetes API to maintain a record of pod IP addresses, pod UIDs, and other metadata.

Association between telemetry data and pod metadata is determined by the pod_association configuration, which executes a list of association rules in order until a match is found.

The probabilisticsampler processor provides stateless, per-request sampling for spans and log records. It supports multiple consistent sampling modes to ensure that if a trace is sampled at a lower probability, it would also have been sampled at a higher probability, helping maintain sub-trace completeness across different collector tiers.

Key Capabilities:

• Trace Spans: Samples based on a configured percentage applied to the TraceID.
• Log Records: Can sample based on the embedded TraceID or by hashing a specific log record attribute.
• Sampling Priority: Supports an override mechanism via a priority attribute to force 0% or 100% sampling.
• Consistency: Ensures that multiple collectors with different sampling probabilities can work together without breaking sub-trace completeness.

The k8sclusterreceiver collects cluster-level metrics and entity events from the Kubernetes API server by listening for updates. It is recommended to use a single instance of this receiver per cluster to monitor it.

Stability Status:

• Logs: development
• Metrics: beta

The awscontainerinsight receiver is an AWS-specific component designed to support CloudWatch Container Insights. It collects, aggregates, and summarizes metrics and logs from containerized applications using the Embedded Metric Format (EMF).

This receiver allows you to migrate existing CloudWatch Container Insights users to OpenTelemetry while maintaining the same experience for the following platforms:

• Amazon ECS
• Amazon EKS
• Kubernetes platforms on Amazon EC2

The GitHub receiver collects data from GitHub using two primary methods:

1. Metrics Scraping: Scrapes version control system (VCS) metrics from GitHub repositories and organizations using GraphQL and REST APIs. These metrics can serve as leading indicators for DORA metrics.
2. Traces: Receives GitHub Actions events by serving a webhook endpoint and converting those events into traces.

Stability Level: alpha (for both metrics and traces).

The metrics_transform processor allows you to manipulate metrics within a batch. You can rename metrics, add, rename, or delete label keys and values, perform scaling, and execute aggregations across labels or label values.

Important Limitation: This processor only supports transformations and aggregations within a single batch of metrics. It does not aggregate across different batches, making it unsuitable for aggregating metrics from multiple sources (like different nodes or clients).

The receiver_creator is a specialized receiver that dynamically instantiates other receivers at runtime. It works by watching networked endpoints discovered by configured observers. When an observed endpoint matches a user-defined rule, the receiver_creator starts the corresponding receiver against that endpoint.

Stability Levels:

• Logs, Traces, Profiles: [alpha]
• Metrics: [beta]

Note on Telemetry Types: If you use the receiver_creator in multiple pipelines with different telemetry types (e.g., metrics and traces), and a dynamically created receiver does not support one of those types, it will result in a logged no-op rather than a collector failure.

The awsecscontainermetrics receiver reads task metadata and docker stats from the Amazon ECS Task Metadata Endpoint to generate resource usage metrics (CPU, memory, network, and disk).

Requirements:

• Must use ECS Task Metadata Endpoint V4.
• Fargate tasks: Must use platform version 1.4.0 or later.
• EC2 tasks: Must use Amazon ECS container agent version 1.39.0 or later.

OpenTelemetry Transformation Language (OTTL) is a domain-specific programming language designed to process telemetry data using OpenTelemetry-native concepts. It is used to transform, filter, or route data within the OpenTelemetry Collector.

An OTTL statement consists of two parts:

1. A function that transforms the telemetry.
2. An optional condition (using the where clause) that determines if the function executes.

Note: OTTL does not currently support cross-signal interactions (e.g., you cannot use a value from a log to set an attribute on a span).

set(span.attributes["test"], "pass") where span.attributes["test"] == nil