> ## Documentation Index
> Fetch the complete documentation index at: https://metoro.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Pod Annotations

> Exclude all logs or trace spans from specific pods by annotating them

For workloads whose telemetry you never want ingested, you can opt them out directly with pod annotations, with no filter rules needed. The Metoro exporter checks the annotations of the pod that produced each log line or trace span, and drops matching records **before they leave the cluster**, the same enforcement point as [log filters](/docs/ingestion-settings/log-filters) and [trace filters](/docs/ingestion-settings/trace-filters).

Annotations are the right tool when the decision belongs to the workload itself ("this pod's logs should never be collected") and can ship alongside it in its own manifests. For content-based rules, environment-scoped rules, or rules maintained by a central team, use the UI filters or [CRD Managed Ingestion Rules](/docs/ingestion-settings/crd-managed-ingestion-rules) instead.

## Supported annotations

| Annotation                 | Values                           | Effect                                                                              |
| -------------------------- | -------------------------------- | ----------------------------------------------------------------------------------- |
| `metoro.io/exclude-logs`   | `"true"`                         | Drop all log lines from the pod's containers.                                       |
| `metoro.io/exclude-traces` | `"true"`, `"server"`, `"client"` | Drop spans where the pod is the server side, the client side, or either (`"true"`). |

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:

```yaml theme={null}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: noisy-batch-job
spec:
  template:
    metadata:
      annotations:
        metoro.io/exclude-logs: "true"
        metoro.io/exclude-traces: "true"
    spec:
      containers:
        - name: worker
          image: noisy-batch-job:latest
```

## Trace direction

Metoro's eBPF traces record both sides of a connection, and `metoro.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.

Each span is evaluated individually: a span is dropped when the server-side pod excludes server traces **or** the client-side pod excludes client traces. Other spans of the same trace are exported normally.

## 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_records` metric, broken down by signal and direction.

<Note>
  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.
</Note>

## Fluent Bit compatibility

If you are migrating from a Fluent Bit-based logging pipeline, the exporter can also honor the [`fluentbit.io/exclude`](https://docs.fluentbit.io/manual/pipeline/filters/kubernetes) 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.