Azure Monitor
Cut Azure Monitor Logs (Log Analytics) costs by down-tiering low-value patterns to the cheaper Basic or Auxiliary table plan and offloading to your own storage. Analyze spend, prevent over-billing, and keep everything KQL-queryable. Works with Log Analytics across AKS, Virtual Machines, Container Apps, and Functions.
Compatibility
Does 10x work with the Azure Monitor Agent
Yes. The Azure Monitor Agent (AMA) is built on the OpenTelemetry Collector, so 10x connects to it natively, no agent swap needed.
The MCP server's SIEM-sample tool and Retriever are agentless, working via the Log Analytics query API and your object store regardless of your forwarder. Also supported: Fluent Bit, Fluentd, and Logstash.
How does 10x integrate with Azure Monitor
10x integrates at the forwarder level before logs reach the Log Analytics workspace.
Supported forwarders: Fluent Bit, Fluentd, Logstash, and the OpenTelemetry Collector (Azure Monitor Agent).
It reduces ingestion volume with non-destructive levers (tier_down to a cheaper table plan, offload to your own storage) that keep the data reachable, plus sampling and drop, which are lossy choices you opt into. No changes to your application code, SDKs, or Log Analytics configuration required.
One requirement for tier_down: routing to a Basic or Auxiliary table goes through the Logs Ingestion API (a Data Collection Endpoint and Rule). The forwarder output must support it, Fluent Bit's azure_logs_ingestion or the Logstash Microsoft Sentinel output. The legacy HTTP Data Collector API writes Analytics-plan _CL tables only and cannot target a cheaper plan.
Will my existing KQL queries still work
Yes. The 10x Engine operates pre-ingestion. Events that pass through arrive in standard Log Analytics format. KQL queries, workbooks, dashboards, and alert rules all work unchanged on the Analytics tier. Zero reconfiguration.
Important: Basic and Auxiliary tables stay KQL-queryable but on a different footing, they bill a per-GB query fee, are queried through the Log Analytics search API (not the standard query API), and do not support scheduled alert rules. Keep alert-critical patterns on the Analytics tier and down-tier the low-value slice. Events routed to your own storage (offload) aren't in the workspace until Retriever fetches them back by pattern identity.
Does the 10x Engine work with AKS, VMs, and Functions
Yes. The 10x Engine works with the Azure compute services that send logs to a Log Analytics workspace:
- AKS: the Receiver runs as a sidecar container alongside Fluent Bit or the OTel Collector; the Reporter deploys as a separate DaemonSet alongside them (logs never pass through it)
- Container Apps: the Receiver deploys as a sidecar alongside your log forwarder
- Virtual Machines / VM Scale Sets: process-level deployment alongside your log forwarder (Receiver) or an independent process (Reporter)
- Functions: for agentless workspace-side analysis without an in-path deployment, use the MCP server's SIEM-sample tool via the Log Analytics query API
Cost Optimization
What's the typical cost reduction for Azure Monitor Logs
The Analytics table plan charges $2.30/GB for ingestion, the single biggest line item for most teams. A 10TB/month environment pays ~$23,000/month just to ingest.
Down-tier to a cheaper table plan: route the low-value slice to a Basic Logs table at $0.50/GB (~78% off the $2.30 Analytics rate), still KQL-queryable, or to an Auxiliary Logs table at $0.05/GB (~98% off) for archive-oriented data. Both are set as a create-time table property via a Data Collection Rule. Down-tiering half of a 10TB/month volume to Basic saves ~$9,000/month on ingest alone (5TB x $1.80 saved).
The tradeoff to weigh: Basic and Auxiliary bill a per-GB query fee, so the win is ingest-side. Down-tier patterns you rarely query at query time; keep hot, frequently-queried patterns on Analytics.
Offload to your own storage: route the bulk slice to a customer-owned Azure Blob or S3 bucket and fetch it back with Retriever only when you query. For compliance and archival profiles where most volume is offloaded, total savings are higher still.
Down-tiering and offload keep the data reachable. Sampling and drop are lossy choices you opt into.
Azure Monitor pricing as of Jan 2026
Can I prevent Azure Monitor billing spikes
Yes. At $2.30/GB on the Analytics plan, a single noisy deployment can add thousands to your bill in hours. Receiver tracks actual cost per event type (bytes x $/GB) and enforces per-type budgets automatically, severity-aware, so ERRORs are kept while DEBUG is throttled first.
For AKS environments, per-app budgets prevent individual services from bypassing limits by scaling pods. For surgical per-pattern caps, commit a field-set mute file to git and let GitOps push it to every receiver.
How does offload reduce Azure Monitor costs
Retriever offloads logs to your own Azure Blob or S3 storage at a fraction of Log Analytics costs, then fetches selected data back on-demand.
- Logs stay reachable in your bucket, fetched back by pattern identity when you query
- Pay Log Analytics ingestion only for logs you actively keep in the workspace
- A large cost reduction for archival scenarios where most volume is rarely queried
Operations
How does optimization affect log data
The levers that move the Azure Monitor bill handle data differently. The non-destructive ones keep every line reachable. Sampling and drop are lossy choices you opt into:
- Receiver (tier_down): routes the low-value slice to a cheaper Basic or Auxiliary table, preserving every field and keeping it KQL-queryable (with a per-GB query fee)
- Retriever (offload): keeps full data in your own Azure Blob or S3 bucket and controls what reaches the workspace
- Receiver (sampling and drop): you choose which event types to cap or discard; these are lossy by design
What is the processing overhead
Events arrive in standard Log Analytics format, no expansion needed, no query-time overhead on the Analytics tier. KQL queries, workbooks, and alert rules work unchanged.
The 10x Engine adds minimal per-event overhead. Memory is capped via -Xmx, CPU via threadPoolSize. For resource requirements, scaling tables, and architecture details, see Performance FAQ.
What about real-time alerting and monitoring
Your Analytics-tier alert rules and workbooks continue working on the optimized stream. Because Basic and Auxiliary tables do not support scheduled alert rules, keep alert-critical patterns on the Analytics tier, Receiver can be configured to always pass error-level logs through at the Analytics tier and down-tier only the low-value slice.
Getting Started
How do I test this on my Azure Monitor logs
- Dev, run on your exported Log Analytics data locally. One-line install, results in minutes. No account, no credit card.
- Reporter, deploy as a DaemonSet for cost visibility before logs reach the workspace. Alternatively, use the MCP server's SIEM-sample tool for agentless analysis via the Log Analytics query API.
- Receiver, deploy via Helm chart alongside your forwarder. Sampling caps noisy patterns; tier_down routes the low-value slice to a cheaper Basic or Auxiliary table (still KQL-queryable). Pre-provision the down-tier table and its Data Collection Rule, whose stream is named
Custom-<table>while the forwarder targets the bare table name; ~30 min setup. - Retriever, offload events to your own Azure Blob or S3 bucket and fetch selected data back on-demand.
Each step is independent, start with Dev to see your reduction ratio, then move to production when ready.
Is the deployment reversible? Can I roll back
Yes, 100% reversible. Rolling back takes minutes:
- Configuration change: point your forwarder output back to the Analytics-tier Log Analytics table directly
- No data migration: your workspace and tables are unchanged, same structure, same alert rules
- No downtime: switch traffic with a config reload (no restart required)
Why it's safe: The 10x Engine sits between your applications and the Log Analytics workspace. It doesn't modify your workspace, tables, or KQL queries.
We recommend keeping bypass routing configured for instant rollback during initial deployment.