TCO Optimizer
The Total Cost of Ownership (TCO) Optimizer for logs and traces reduces costs by aligning data priorities with the business value of your data. Critical data remains instantly searchable for real-time analysis and alerting, while lower-value data is routed to cost-efficient storage.
Overview
TCO Optimizer gives you precise control over how logs and traces are processed and stored. You create policies using the fields application
, subsystem
, and severity
so that each data type is handled according to its importance.
This enables you to balance cost and performance—keeping high-priority logs hot for analysis, archiving compliance data, and managing monitoring data at scale—delivering full observability at a fraction of the cost.
TCO priority levels explained
When logs and traces are ingested, they are routed to one of three pipelines, known as priority levels, or blocked, based on your policies.
High
Business-critical or high-severity data is stored on fast, replicated SSDs, allowing queries, alerts, and investigations to complete within seconds. This is the default priority for unmatched logs and traces.
Medium
Data used for monitoring and statistics remain fully accessible for dashboards, alerts, anomaly detection, and ongoing analysis at scale.
Low
Data retained for compliance or post‑processing is archived immediately to minimize storage costs while remaining retrievable when needed.
Blocked
Data is dropped at ingestion and not stored.
Features by priority level
Each priority level provides different capabilities across the platform:
Feature | High | Medium | Low |
---|---|---|---|
AI Evaluators | ✅ | ✅ | |
Alerts | ✅ | ✅ | |
Anomalies | ✅ | ✅ | |
APM with Events2Metrics | ✅ | ✅ | |
APM with Span Metrics | ✅ | ✅ | ✅ |
Archive | ✅ | ✅ | ✅ |
Background Queries | ✅ | ✅ | ✅ |
Dashboards | ✅ | ✅ | ✅ |
Data Enrichment | ✅ | ✅ | ✅ |
Events2Metrics | ✅ | ✅ | |
Lightning Queries | ✅ | ||
LiveTail | ✅ | ✅ | ✅ |
Log Parsing | ✅ | ✅ | ✅ |
Loggregation | ✅ | ✅ | |
Real User Monitoring | ✅ | ✅ | |
Session Replay | ✅ | ✅ | ✅ |
Note
Service Map and Service Catalog for APM are available regardless of priority.
About log & trace policies
Data is routed to priority levels based on the policies that you create. Policies use the fields application
, subsystem
, and severity
to match logs and traces.
Evaluation order matters. Policies are evaluated from top to bottom. When a log or trace matches the first policy, no subsequent policies are applied. Logs and traces that do not match any policy go to the High priority by default. Reorder policies in the UI via drag‑and‑drop.
Create a general policy
Open the new policy form
Navigate to Data Flow > TCO Optimizer, then select + New policy.
Define details
Policy name
— RequiredDescription
— Optional context for collaboratorsPolicy order
— ChooseFirst
(highest precedence) orLast
(applies after existing policies)
Add filters
Use the Builder to choose which logs this policy applies to.
- Click Select field and add one or more conditions for
application
,subsystem
, and/orseverity
using operatorsis
,is not
,includes
,starts with
. - Use + Add filter to combine conditions.
Examples
application = "payments-service"
subsystem = "worker"
severity IN ["ERROR", "WARN"]
Set priority
Choose the target priority for matching data: high (default)
, medium
, low
, or block
.
As you select a priority, the card displays the estimated Units (U) and the expected change compared to your baseline.
Set retention policy
Choose your archive retention policy: none
, default
, short
, intermediate
, or long
.
Create
Click Create. The policy appears in the TCO Optimizer list in the order it was created.
Create a granular policy
You can reroute a subset of logs that would otherwise match a broader policy.
Example
- General rule: all severities for
application = "azure"
andsubsystem = "cdn"
go tohigh
. - Exception: logs with
severity = "INFO"
should go toLow
.
Create a specific policy for the exception either in Log policies or directly from Log statistics. A more granular policy created from Log statistics is placed above the general policy, so it takes precedence.
Log overrides: End-of-life and migration
The Override table in your TCO UI is slated for deprecation on March 31, 2026. From that point forward, all existing override rules will automatically appear as policies at the top of the Log policies panel. As granular policies, they will be executed before more general policies, preserving the current override functionality.
Before March 31, 2026, during the hybrid phase, the Override panel will continue to exist, and override APIs will remain functional.
How can I prepare?
UI users are strongly encouraged to migrate their overrides to granular log policies before that time. To do so, hover over an override, then click on
- The rule is removed from the override table.
- A new TCO policy is created with the same conditions and settings.
- The converted rule appears in the Log policies table and follows its execution order.
- This action can’t be undone.
Should I delete or convert an existing override?
Compare the override TCO priority with the fallback priority - the priority that applies if the override is not applied, due to an existing policy or default state. If the override priority and fallback priority are identical, the override may be deleted.
Statistics
Statistics show all ingested logs or traces organized by application
, subsystem
, and severity
, along with data usage for each group. Use it to understand where your data volume originates and to convert insights into precise TCO policies.
Use this view to:
- Group by
application
,subsystem
,severity
,affecting policy
, andpriority
. - Expand an
application
to see itssubsystem
s, then expand asubsystem
to see itsseverity
breakdown. - See contribution to % Quota, Data sent, and Units (U) for each combination.
- Validate expected impact before saving.
Row menu actions
Row menu actions include:
- Add rule — Pre‑fills the policy form with the row’s values.
- Drill into logs — Opens a query filtered to the row’s values.
- Copy as filter — Copies
application
/subsystem
/severity
chips for reuse.
Slice and filter the data
- Group by chips — Choose which fields (e.g.,
application
,subsystem
,severity
) to include in the breakdown. Drag and drop chips to rearrange them. - Search — Filter rows by name (supports partial matches).
- Include/exclude values — Use chip menus to add or remove specific values.
- Reset — Clear temporary filters and return to the default settings.
Create a policy from statistics
Turn any selection into a policy without leaving the page:
- Select a row.
- Choose Add rule. The Create policy form opens with the Builder pre‑filled:
application = "<selected-application>"
subsystem = "<selected-subsystem>"
(when applicable)severity IN ["<selected-severity>"]
- Choose a Priority:
High (default)
,Medium
,Low
, orBlock
. - (Optional) Set Archive retention:
None
,Default
,Short
,Intermediate
, orLong
. - Review the Preview panel for Data sent, % quota, and Units (U) impact.
- Toggle Enable policy on to activate immediately.
- Click Create.
The new policy appears in the TCO rules table. Remember that order matters; set Policy order to place it First
(highest precedence) or Last
.
Understand the “affecting policy” column
When a combination already matches a policy, the Affecting policy displays the policy that is currently in effect.
Use it to:
- Avoid creating duplicate policies.
- Spot combinations that fall into the default
high
priority (shown as—
ornone
). - Decide whether to edit an existing policy or add a higher‑precedence one.