Supported annotations
Values are case-insensitive and whitespace is trimmed.
"false" explicitly disables the exclusion; any other value is ignored and logged as a warning by the exporter.
Set the annotations on the pod template of the owning workload so every pod carries them:
Trace direction
Metoro’s eBPF traces record both sides of a connection, andmetoro.io/exclude-traces lets a pod opt out of either role independently:
"server"drops spans for requests received by the pod."client"drops spans for requests made by the pod."true"drops both.
How it works
- The exporter watches pods in the cluster and evaluates annotations locally: no round trip to Metoro, and annotation changes take effect as soon as the Kubernetes API reflects them.
- Telemetry arriving shortly after a pod is deleted is still filtered: the exporter remembers a deleted pod’s annotations for a few minutes.
- Drops are observable via the exporter’s
metoro.exporter.annotation_dropped_recordsmetric, broken down by signal and direction.
Annotation-based exclusion is enabled by default. It can be disabled by
setting
METORO_HONOR_WORKLOAD_TELEMETRY_ANNOTATIONS=false on the
metoro-exporter deployment, after which the annotations are ignored
cluster-wide.Fluent Bit compatibility
If you are migrating from a Fluent Bit-based logging pipeline, the exporter can also honor thefluentbit.io/exclude annotation ("true" drops the pod’s logs, same semantics as metoro.io/exclude-logs). This is off by default; enable it by setting METORO_HONOR_FLUENTBIT_ANNOTATIONS=true on the metoro-exporter deployment.