---
icon: material/connection
title: "Integration"
---

How 10x sits in front of Datadog, from Fluent Bit or through the Datadog Agent, how the Standard index, Flex Logs, S3 and metrics fit together, what the metric output costs in custom metrics, and the AWS Lambda path.

### :material-connection: Datadog Agent Integration

??? tenx-integration "How do I integrate 10x with Datadog Agent"

    10x runs **before** logs reach Datadog, as a sidecar to the log forwarder. The Receiver sits in the forwarder's pipeline; on the Datadog Agent path the Agent reads the Receiver's output through its standard `logs_config` file input.

    **Two paths:**

    **Path 1: Fluent Bit or Fluentd with the 10x sidecar (recommended)**

    Fluent Bit hands each event to the Receiver and gets it back carrying `routeState`, then ships to Datadog through its own output plugin and API key:

    ```
    Application logs → Fluent Bit (10x sidecar) → Datadog
    ```

    **Fluent Bit output to Datadog:**

    ```ini
    [OUTPUT]
    Name datadog
    Match *
    apikey ${DD_API_KEY}
    json_date_key timestamp
    dd_service myapp
    dd_source myapp_logs
    ```

    **Path 2: Datadog Agent file input**

    Fluent Bit with the 10x sidecar reads the application's log folder and writes the processed stream to a second folder. The Datadog Agent tails that folder with its standard `logs_config` and ships to Datadog, keeping its buffering, retries and host tagging ([Datadog Agent input](https://doc.log10x.com/run/input/forwarder/datadogAgent/)):

    ```yaml
    logs:
      - type: file
        path: /var/log/app/optimized/*.log   # the folder the Receiver writes, not the application's own
        service: myapp
        source: myapp_logs
    ```

    **Cost:**

    Datadog meters ingestion per GB and, separately, Standard indexing per million events at a rate set by retention. A tier_down event leaves the Standard count for a Flex Logs index, still searchable in Datadog, and still pays ingestion; an offloaded event leaves Datadog for S3 and pays neither. What a Flex move nets against the indexing it avoids is worked through at list price in [benchmarks/datadog-flex-accounting](https://github.com/log-10x/benchmarks/tree/main/datadog-flex-accounting){target="_blank"}. Ask the [MCP server](https://github.com/log-10x/log10x-mcp){target="_blank"} for a local cost POC; it states the events and GB a plan would move out of the Standard index.

??? tenx-integration "What is the performance overhead of 10x with Datadog Agent"

    The Receiver processes events at the edge before they reach Datadog. Memory is bounded by the container limit and CPU by `threadPoolSize`. For resource requirements and Kubernetes resource specs, see [Node counting](https://doc.log10x.com/faq/pricing/node-counting/).

    **Agent interaction:** on the Datadog Agent path the Receiver writes to a file and the Agent tails it asynchronously, so each side runs at its own pace.

    **Agent load:** the Agent ships fewer bytes only on the offload and drop slices. A tier_down event still passes through the Agent to Datadog; it changes index, not volume.

    **Search time unchanged:** events sent to Datadog, in Standard and in Flex, are standard log events. Compact events, losslessly reduced, live in S3, where the [Retriever](https://doc.log10x.com/apps/retriever/) expands them, so every expansion happens outside Datadog.

??? tenx-integration "Can I use 10x with Datadog's exclusion filters"

    **Yes.** They act at different points.

    - **Datadog [exclusion filters](https://docs.datadoghq.com/logs/log_configuration/indexes/#exclusion-filters){target="_blank"}:** a query per index, sampled at 0 to 100%. The excluded logs are still ingested and pay ingestion; they leave the index.
    - **10x:** a cap per pattern on the forwarder, before Datadog. The excess over the cap takes the service's action: tier_down to a Flex Logs index, still searchable in Datadog; offload to S3, where the Retriever fetches it back; sample; or drop. tier_down and offload keep the data; sample and drop are the lossy actions.
    - **Together:** an exclusion filter and a cap on the same pattern each remove their share; the filter runs on what the cap passed.

    Which to write first is on the [Comparisons](comparisons.md) page.

### :material-sitemap: Architecture

??? tenx-integration "How do the 10x products work together for Datadog"

    Five paths, deployed one at a time:

    1. **Standard index, Receiver → Datadog:** every event under its pattern's cap goes to Datadog unchanged, within its service's total, which a scheduled run, hourly by default, sets from the team's monthly number for Standard indexing. Above the cap the first five events of a pattern in each window (4 minutes by default) always pass, and so do up to 50 lines over the cap of each ERROR, CRITICAL or FATAL statement in each window on each node, released in four slices across the window; caps apply from a container's first line on each node. The allowance is enforced continuously, so a burst cannot spend a day's allowance at once. The settings are on the [rate regulator](https://doc.log10x.com/run/receive/rate/) page.

    2. **Flex Logs, Receiver → a Flex Logs index:** under a tier_down action the Receiver marks the excess over each cap `routeState: tier_down`, and an index filter on `@routeState:tier_down` lands it in a Flex Logs index. The slice stays searchable in Log Explorer with no rehydration, log-based metrics and Live Tail still see it, and it pays ingestion. Datadog runs no monitors on Flex Logs.

    3. **S3, Receiver → the team's bucket:** under an offload action the excess leaves Datadog for S3, compact and lossless in storage. The [Retriever](https://doc.log10x.com/apps/retriever/) expands and streams it back on demand, paying Datadog ingestion only on what comes back.

    4. **Metrics, repetitive patterns → Datadog metrics:** the [Retriever](https://doc.log10x.com/apps/retriever/) aggregates repetitive S3 events into data points on Datadog's time-series API, for dashboards at metric pricing rather than log pricing.

    5. **Lambda:** the [Extension](https://doc.log10x.com/engine/launcher/extension/){target="_blank"} runs the engine inside each function's execution environment and regulates events before they leave the function. Events for Datadog ship to the Logs API; under offload, the excess goes to S3.

    See [Retriever use cases](https://doc.log10x.com/apps/retriever/#use-cases){target="_blank"} for the workflows: incident investigation, dashboard population, compliance queries and metric aggregation.

??? tenx-arch "What the Receiver's Datadog metric output costs in custom metrics"

    Datadog counts a custom metric for each distinct metric name and tag set. Its [price list](https://www.datadoghq.com/pricing/list/){target="_blank"} gives $5 per 100 custom metrics a month, and its [billing page](https://docs.datadoghq.com/account_management/billing/custom_metrics/){target="_blank"} states that indexed custom metrics bill beyond the allotment at the rate in the customer's contract and ingested custom metrics at $0.10 per 100; the allotment is 100 per host on Pro and 200 on Enterprise (prices as read on 2026-10-11).

    The Receiver's [Datadog metric output](https://doc.log10x.com/run/output/metric/datadog/) tags each per-pattern series with the pattern and where it ran (`message_pattern`, `tenx_hash`, `tenx_user_service`, `severity_level`, `routeState`, `k8s_container`, `k8s_namespace`, and `tenx_team` when [`k8sTeamLabel`](https://doc.log10x.com/run/initialize/k8s/#k8steamlabel) names a pod label) and with the runtime attributes (`tenx_app`, `tenx_env`), and every tag is shared across nodes and processes, so the same series comes from every node and the count stays flat as the fleet grows and processes restart.

    The output publishes the 200 tag sets with the most bytes (`topSeries`, configurable; `0` publishes all). Datadog bills a distribution as five custom metrics (count, sum, min, max and avg) for each tag set, so with the two shipped aggregators and two counters each that is 4,000 custom metrics, inside a Pro allotment from 40 hosts up. A pattern outside the top is published once it costs more than the smallest one inside. On the OpenTelemetry demo capture the top 200 patterns carried 98.8% of the bytes. To tag the host as well, add it as a runtime attribute, `host_name:<host>`, and expect the count to multiply by the number of nodes.

??? tenx-arch "Which events belong in Standard, Flex and S3"

    **Standard index:** every event under its pattern's cap and its service's total, the always-pass lines, up to 50 lines over the cap of each error statement in each window on each node, released across the window, and every pattern a monitor, a dashboard or an SLO reads. Datadog runs no monitors on Flex Logs.

    **Flex Logs, through tier_down:** the excess of patterns that still need searching in Datadog. Flex is searchable in Log Explorer with no rehydration, and the slice pays ingestion.

    **S3, through offload:** the excess of patterns that do not need to be in Datadog, kept in a bucket the team owns. The [Retriever](https://doc.log10x.com/apps/retriever/) streams a time range and pattern back into Datadog on demand, paying ingestion only on what comes back.

    **Services with no rule:** with a monthly number, the scheduled run holds a service it has not seen yet at the level the known services share, from its first line. Without one, a service the POC report gives no rule of its own takes the fleet default limit. A statement's lines above that limit go to Flex through the same `@routeState:tier_down` index filter, or to S3 on an account without Flex, and up to 1,800 lines a day of every statement still reach Standard on each node. The limit is twice the daily lines of the largest statement the plan keeps in Standard, per node, and the POC report states it in lines a day.

    An error monitor sees every ERROR, CRITICAL and FATAL line under the limit, the always-pass lines and up to 50 lines over the limit of each error statement in each window on each node, released across the window, under either action. A service with a rule keeps one threshold and one action. The [Optimization](optimization.md) page has the details.

    **Before and after a move:** before a rule moves statements off Standard, the MCP lists the log monitors and log-based metrics that read them; after the install, its weekly change report lists the statements new in each service, the rule that held each one, and the owning team when the team label (`k8sTeamLabel`) is set.

### :fontawesome-brands-aws: AWS Lambda

??? tenx-lambda "Can I optimize Datadog logs from AWS Lambda functions"

    **Yes, for functions that ship logs through the OTel collector extension.** Attach the published `tenx-receive` layer: the [Extension](https://doc.log10x.com/engine/launcher/extension/) runs the engine inside each function's execution environment and regulates events before they leave the function.

    **How it works:** the collector hands each log record to the engine over loopback and gets it back carrying `tenx_hash` and `routeState`. A routing connector ships the Datadog slice through the collector's existing exporter and lands the offload slice in S3, where the [Retriever](https://doc.log10x.com/apps/retriever/) fetches it back on demand.

    **Cost levers:** a mute file in S3 caps noisy patterns, tier_down routes the excess to a Datadog Flex Logs index, still searchable, and offload sends it to S3.

    [Deployment guide](https://doc.log10x.com/engine/launcher/extension/)