Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.odigos.io/llms.txt

Use this file to discover all available pages before exploring further.

Noisy Operation rules drop or down-sample traffic that you treat as having little or no value—for example Kubernetes liveness and readiness probes, periodic health checks, or scraper traffic. They are the first stage in the rule evaluation pipeline: a trace that matches a Noisy rule is not evaluated against Highly Relevant or Cost Reduction rules.

​
How they’re evaluated

  • Head sampling at the root span. The keep/drop decision is made on the entry span, before child spans are processed.
  • No trace buffering. Because the decision happens at the start of the trace, the gateway does not need to wait for an aggregation window.
  • Lowest overhead. Head sampling is the most efficient sampling type, with the least CPU and memory impact on collectors and gateway.
Head-sampled Noisy rules require an instrumentation agent that supports head sampling. Today this includes Node.js, Python, Java, and Go. For other languages or runtimes, Noisy rules are evaluated at tail-sampling time instead—the trace is buffered for the full aggregation window before the drop happens, so the efficiency advantages above (no buffering, lowest overhead) do not apply.

​
Possible outcomes

A matching trace is either:
  • Dropped — never exported and never evaluated against Highly Relevant or Cost Reduction rules.
  • Sampled down — kept at a configured percentage. The kept fraction also skips later categories.
Dropped traces do not continue to other categories. If you need a noisy route to remain visible when something goes wrong (for example a failing health check), replace the Noisy rule with a Highly Relevant rule on errors and use a Cost Reduction rule to cap the successful traffic.

​
Built-in rule: Kubernetes Health Probes

Odigos ships a single built-in Noisy rule, Kubernetes Health Probes, which drops traces for the liveness, readiness, and startup probe paths discovered on each workload’s Kubernetes manifest. The rule’s Keep Percentage controls how much probe traffic is retained. Common configurations:
  • 0% — drop everything (default). Probes carry no signal about application behavior, so dropping them keeps the pipeline focused on real traffic and minimizes cost.
  • ~2% — sparse liveness signal. For services with little or no real traffic, a small permanent value keeps a handful of probe traces flowing. The retained samples act as a “service is up” indicator on dashboards that would otherwise look empty, helping distinguish a quiet service from a silently broken one.
  • 100% — debug probe failures. Temporarily raise while investigating failing or flaky probes, then reset to your normal value once resolved.
Only HTTPGet probes declared on the manifest are matched. Probes defined as exec or tcpSocket, or probes routed through different paths (custom configuration, ingress rewrites, service-mesh wrappers), are not auto-handled; add an explicit Noisy rule for those paths if needed.

​
Typical use cases

  • Kubernetes liveness, readiness, and startup probes
  • Internal /health and /healthz endpoints
  • Prometheus /metrics scrape traffic
  • Background heartbeats and keep-alive pings
  • High-volume, low-value endpoints — for example a static asset route, a polling endpoint, or an autocomplete API that produces many traces without contributing to debugging or SLOs