Skip to content

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 S3 or S3-compatible 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 reports the cost of each event type (bytes x $/GB) and, once a cap is set, caps each type's bytes per window, severity-aware: by default an over-cap type keeps at least half of its ERROR, CRITICAL and FATAL events, 30% of WARN and 10% of every other level. The cost is reported; the regulator decides on bytes.

For AKS environments, per-app budgets prevent individual services from bypassing limits by scaling pods. For per-pattern rates, commit a 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 S3 or S3-compatible storage at a fraction of Log Analytics costs, then fetches selected data back on-demand. Logs already in Azure Blob Storage are indexed and fetched the same way.

  • 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

Routing Key

What does 10x add to Azure Monitor's own routing

A Basic or Auxiliary table or your own S3 stores the cheaper slice, and today a person writes the rules that choose it: data collection rules send rows to a table on the Basic or Auxiliary plan. 10x keeps those rules current per pattern: the rules key on the pattern, which is the same on every pod from its first line, whatever lines that pod has seen and whenever it started. A miner at the edge depends on both: two Drain3 instances that each see half of one stream name a line seen 2 to 10 times differently 39.78% of the time (pattern-identity benchmark). The compiler runs in CI or on a schedule, so new log statements, including ones a coding agent wrote, are named as the code ships; a scheduled check (tenx-recur) costs each pattern, routing changes arrive as pull requests to the policy repo, and caps act on their own.

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 S3 or S3-compatible 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 by the container limit, CPU via threadPoolSize. For resource requirements and Kubernetes resource specs, see Node counting.

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
  1. Cost POC, install the 10x MCP and ask it to run a POC on your exported Log Analytics data. The engine runs on your own machine, results in minutes. No account, no credit card.
  2. 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.
  3. 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.
  4. Retriever, offload events to your own S3 or S3-compatible bucket and fetch selected data back on-demand.

Each step is independent, start with the cost POC 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.