--- icon: material/help-circle-outline title: "FAQ" --- The [Reporter](https://doc.log10x.com/apps/reporter/) identifies storage and licensing cost drivers by analyzing app/infra events _before_ forwarders ship them to log analyzers. It deploys as a **DaemonSet alongside your forwarder**, not a sidecar injected into it, and not a cloud app polling your analyzer.
- [:material-information-outline: **Overview**](#overview) - [:material-connection: **Integration**](#integration-deployment) - [:material-gauge: **Performance**](#performance) - [:material-lightbulb-outline: **Use Cases**](#use-cases)
### :material-information-outline: Overview ??? tenx-overview "What is the Reporter and what metrics does it provide" The Reporter is a read-only DaemonSet that tails the same event stream your forwarder sees, pre-ingestion. It doesn't modify, filter, or redirect any data, and logs never pass through it. It provides real-time metrics including: - **Bytes processed** by [message pattern](https://doc.log10x.com/run/initialize/message/){target="_blank"}, application, and log type - **Event counts** across your pipeline - **Estimated analyzer costs** broken down by [message pattern](https://doc.log10x.com/run/initialize/message/){target="_blank"} Unlike analyzer-side analysis, the Reporter captures pre-transport metrics, you see exactly what you're sending and what it will cost before data reaches your destination. ??? tenx-overview "Does the Reporter reduce my costs directly" The Reporter provides visibility. It shows where every dollar goes by classifying events using pre-compiled log templates from your source code. To reduce costs, pair the Reporter with the [Receiver](https://doc.log10x.com/apps/receiver/): - [Filter mode](https://doc.log10x.com/apps/receiver/): budget caps, rate sampling, declarative mute files - [Compact mode](https://doc.log10x.com/apps/receiver/compact/): lossless volume reduction where the destination supports it (Splunk, self-hosted Elasticsearch/OpenSearch; a no-op on Datadog, CloudWatch, Azure, GCP, Sumo, and managed Elasticsearch), with an analyzer-side expand plugin Start with an MCP cost POC to preview savings locally, then deploy the Reporter (DaemonSet) for pre-ingestion cost visibility. For agentless analyzer-side analysis without deploying a DaemonSet, the [MCP server](https://github.com/log-10x/log10x-mcp) offers an on-demand SIEM-sample tool. ??? tenx-overview "What visibility does the Reporter provide vs. my analyzer's built-in metrics" Analyzer-side metrics show what arrived at your platform but lack granular per-event-type attribution and pre-transport context. They also reflect the analyzer's post-sampling view, you can't use them to claim "we see more than our analyzer." The Reporter captures metrics at the origin (pre-ingestion) and automatically [enriches](https://doc.log10x.com/run/initialize/){target="_blank"} every event, no manual regex or configuration required: - [Message extraction](https://doc.log10x.com/run/initialize/message/){target="_blank"}: identifies the core message pattern from each event for cost-per-event-type metrics - [Kubernetes context](https://doc.log10x.com/run/initialize/k8s/){target="_blank"}: container, pod, and namespace for per-workload cost attribution - [Severity level](https://doc.log10x.com/run/initialize/level/){target="_blank"}: classifies by level (DEBUG, INFO, WARN, ERROR) to surface excessive debug logging - [Multi-line grouping](https://doc.log10x.com/run/initialize/group/){target="_blank"}: groups stack traces as single logical events for accurate costing - [HTTP codes](https://doc.log10x.com/run/initialize/httpCode/){target="_blank"} and [GeoIP](https://doc.log10x.com/run/initialize/geoIP/){target="_blank"} enrichment from log content This surfaces optimization opportunities not available from the analyzer side, like which specific services, event types, or severity levels drive costs. The breakdowns land in your own time-series backend as [metrics](https://doc.log10x.com/run/output/metric/){target="_blank"}, where you explore them in the dashboards you already run. ### :material-connection: Integration & Deployment ??? tenx-integration "Which log forwarders does the Reporter support" The Reporter works with all eight supported [log forwarders](https://doc.log10x.com/run/input/forwarder/){target="_blank"}: - [Fluent Bit](https://doc.log10x.com/run/input/forwarder/fluentbit/){target="_blank"} - [Fluentd](https://doc.log10x.com/run/input/forwarder/fluentd/){target="_blank"} - [Logstash](https://doc.log10x.com/run/input/forwarder/logstash/){target="_blank"} - [OpenTelemetry Collector](https://doc.log10x.com/run/input/forwarder/otel-collector/){target="_blank"} - [Vector](https://doc.log10x.com/run/input/forwarder/vector/){target="_blank"} - [Filebeat](https://doc.log10x.com/run/input/forwarder/filebeat/){target="_blank"} - [Splunk Universal Forwarder](https://doc.log10x.com/run/input/forwarder/splunkUF/){target="_blank"} - [Datadog Agent](https://doc.log10x.com/run/input/forwarder/datadogAgent/){target="_blank"} **Deployment:** a DaemonSet alongside your forwarder, *not* a mutating webhook that injects into forwarder pods, and *not* a sidecar inside them. Similar pattern to `datadog-agent` or `splunk-otel-collector`. Kubernetes deployment via [Helm chart](https://doc.log10x.com/apps/reporter/deploy/){target="_blank"}. Setup time: ~20 minutes. The Reporter tails the same source your forwarder tails. No changes to existing fluent-bit / fluentd / otel-collector configs. **Resource requirements:** Same engine as the Receiver, 512 MB heap + 2 threads handles 100+ GB/day per node. The Reporter is async and never in the data path, so it adds zero latency to log shipping. See [Node counting](https://doc.log10x.com/faq/pricing/node-counting/) for sizing details. ??? tenx-integration "Does the Reporter replace my existing forwarder" **No.** The Reporter runs alongside your forwarder, not in place of it. Your existing fluent-bit / fluentd / otel-collector / filebeat continues to ship logs to your analyzer exactly as before. The Reporter reads the same files/streams in parallel to extract cost insight metrics. ??? tenx-integration "Can the Reporter block or delay log delivery" **No.** The Reporter fails independently. If it goes down, your logs continue flowing to the analyzer uninterrupted, you temporarily lose cost-visibility metrics on that node until the DaemonSet pod respawns. ??? tenx-integration "Where do the metrics go" The Reporter exports metrics to any [supported time-series database](https://doc.log10x.com/run/output/metric/): - [Prometheus](https://doc.log10x.com/run/output/metric/prometheus/){target="_blank"} (scrape endpoint or remote write) - Datadog - CloudWatch - Elastic Metrics include volume by [message pattern](https://doc.log10x.com/run/initialize/message/){target="_blank"}, event counts, and cost estimates. Build dashboards in your existing tools, set alerts on cost thresholds, and correlate log costs with application metrics. All metric destinations can be configured simultaneously. The system is [extensible](https://doc.log10x.com/api/output/#micrometer){target="_blank"}, define custom registries to add support for additional time-series systems. ### :material-gauge: Performance ??? tenx-throughput "What latency does the Reporter add" Zero. The Reporter is a separate DaemonSet pod, it is not in the data path. Metrics calculation runs in parallel with forwarding. If the Reporter stops, logs continue flowing to their destination unchanged. ??? tenx-throughput "What happens if the Reporter fails" Insights go stale; logs continue to the analyzer uninterrupted. The DaemonSet controller respawns the pod automatically. | Scenario | Behavior | |---|---| | Reporter pod crash or OOM | Kubernetes restarts the pod; metrics resume on next collection cycle. Logs unaffected. | | Volume exceeds Reporter capacity | Reporter falls behind on metric emission; logs unaffected. Increase DaemonSet resources or sampling if sustained. | | Forwarder crashes | Unrelated, Reporter tails source logs directly and is independent of the forwarder lifecycle. | | Network interruption | No effect on log shipping. Reporter queues metrics until Prometheus is reachable again. | | Downstream analyzer slow or unreachable | Unrelated, Reporter does not ship to the analyzer. | | Rollback | `helm uninstall` removes the DaemonSet; forwarders unaffected. | ### :material-lightbulb-outline: Use Cases ??? tenx-start "Can I use the Reporter without other 10x products" Yes, the Reporter is standalone. It can be used independently to understand log cost distribution without other 10x components. The metrics are valuable on their own for: - **Capacity planning** and trend analysis - **Budget forecasting** with real volume data - **Chargeback allocation** across teams - **Anomaly detection** on volume spikes All metrics feed your time-series backend (Prometheus, Datadog, Elastic, and others), where cost dashboards break spend down by application, severity, and pattern. ??? tenx-start "Can the Reporter identify repeated stack traces as cost drivers" Yes. Exception stack traces spanning 50-100 lines repeated thousands of times are a common cost driver. The Reporter measures stack trace volume pre-ingestion and quantifies the savings potential: - Original: 80-line trace x 10,000 occurrences = 800,000 lines - After [Receiver Compact mode](https://doc.log10x.com/apps/receiver/compact/){target="_blank"} compacts (on a destination where compact applies: Splunk, self-hosted Elasticsearch/OpenSearch; a no-op on Datadog, CloudWatch, Azure, GCP, Sumo, and managed Elasticsearch): 80-line template + 10,000 references = ~80,100 lines - Reduction for this pattern: modeled where the destination supports it; repeated stack traces reduce the most Works with all languages: Python tracebacks, Java/Kotlin, Node.js, Go panic dumps, Ruby, C# .NET, PHP. Deploy the [Receiver](https://doc.log10x.com/apps/receiver/){target="_blank"} to act on the findings (filter mode to cap, compact mode to shrink).