KING TECHNOLOGYSolutions Group

Research · Observability and AI operations

How observability platforms learn

Published October 2026 · Sources checked October 18, 2026

1. The question about the future

By 2028-2030, how much of the "learning" inside observability and AIOps platforms will an organization be able to shape to its own systems and business cycles, and what has to be in place today for that learning to be trustworthy?

Most teams meet machine learning in their monitoring tools as a feature: a shaded band around a chart, an "anomaly" badge, a list of grouped alerts, a suggested root cause. Those features rest on a small number of well-studied ideas. Knowing how those ideas work, and what they need, is the most reliable way to judge where the tools are heading and what to prepare.

2. The signals today

2.1 How the learning is built, in plain language

Dynamic baselining and seasonality. A baseline is the system's learned sense of "normal" for a metric at a given moment. Rather than one fixed threshold, the model looks at history and estimates the expected value and a band around it. A well-known way to do this splits a time series into parts that add together. A 2017 forecasting paper by Taylor and Letham describes the series as trend, plus periodic seasonality, plus holiday and event effects, plus error. Seasonality is represented with Fourier terms (sums of sine and cosine waves) for each cycle, such as weekly and yearly, and new cycles can be added without restructuring the model. Holidays and events are supplied by analysts as custom lists, each with its own effect. [S1]

The practical point is that a baseline is only as good as its knowledge of the business calendar. If the model has never been told about month-end close, a payroll run, a tax deadline, or a school-term start, it will read those normal peaks as anomalies, or it will absorb a real problem into a "seasonal" pattern.

Anomaly detection. Once there is an expectation, an anomaly is a meaningful departure from it. Methods come in families: forecasting-based (compare actual to predicted), distance- or density-based (how far a point sits from its neighbors), reconstruction-based (how badly a learned model can reproduce the data), and others. The largest independent comparison we found, published in the Proceedings of the VLDB Endowment in 2022, re-implemented 71 algorithms and ran them on 976 time-series datasets. Its findings are directly useful for buyers: "there is no clear winner"; every family performed well on some anomaly types; simple methods performed almost as well as sophisticated ones; deep-learning approaches were not yet competitive for their training cost; and parameter sensitivity was high, which the authors say creates demand for self-tuning methods. [S2]

Turning anomalies into alerts people trust. Detection is not the same as alerting. The chapter on monitoring distributed systems in the book Site Reliability Engineering sets two tests for any page: "Every page should be actionable," and "Every page response should require intelligence." It distinguishes symptoms (what is broken) from causes (why), and it is openly skeptical of "magic" systems that try to learn thresholds or detect causality automatically. [S3] The companion SRE workbook describes how to judge an alerting setup with four measures: precision (share of alerts that were significant), recall (share of significant events that alerted), detection time and reset time. It recommends alerting on how fast a service consumes its error budget (the "burn rate"), checked over a long and a short window together so that alerts fire quickly for severe problems and stop promptly once the problem ends. [S4]

Read together, these sources suggest a sensible division of labor: learned baselines are good at finding unusual behavior; service-level objectives (SLOs) are good at deciding whether that behavior deserves a human's attention right now.

Event correlation and clustering. Large estates produce floods of near-duplicate events. Platforms reduce them in three common ways:

  • Text clustering. Log lines are reduced to templates by stripping out the variable parts (IDs, timestamps, numbers). A widely cited 2017 approach does this in a streaming fashion: it groups messages by length, routes them through a shallow tree using their leading words, and joins a message to an existing template if it is similar enough. [S5]
  • Time-window grouping. Events that start close together are grouped.
  • Topology grouping. Events on components that are connected (a host and the services on it; a service and its database) are grouped. A survey of anomaly detection and root-cause analysis for microservice applications classifies techniques as log-based, trace-based and monitoring-based, and describes root-cause methods that walk topology or causality graphs. [S6]

Root-cause ranking. Ranking "most likely cause" is the hardest task on the list. A 2024 study evaluated nine causal-discovery methods and twenty-one root-cause methods on synthetic data and on benchmark microservice systems. Its conclusions are sobering: no method stood out in all situations; many common methods performed about as well as random selection; causal discovery struggled to scale with the number of services and metrics; tuning helped on small graphs but not reliably on large ones; and longer input data substantially improved results. [S7] The microservices survey adds that baselines trained on past runs can produce false positives and false negatives when workloads or deployments change, and that operators need explanations, not just rankings. [S6]

Our interpretation: when a platform already knows how components connect (from traces, a service map or a configuration management database), it has to infer less, and inference is the weak spot that the research identifies.

Forecasting. Capacity and saturation forecasts use the same decomposition ideas as baselines: project the trend, re-apply the cycles and known events, and widen the band as the horizon lengthens. The 2017 paper describes an "analyst in the loop" design: interpretable settings (capacity limits, known changepoints, holidays) that a person who knows the series can adjust, plus automatic flagging of forecasts that look wrong for review. [S1]

Large language models (LLMs) in incident work. Researchers at a large cloud provider studied more than 40,000 of their own production incidents and compared language models, used without task-specific training, fine-tuned, and multi-task, at suggesting root causes and mitigation steps, with human evaluation by the incident owners. [S8] It is one company's data, and the public abstract does not give detailed accuracy figures, but it is an early, documented signal that incident history is a usable training and evaluation resource.

2.2 What the learning depends on

Across the sources above, the same inputs keep deciding the outcome:

  1. Data quality and consistent naming. A model cannot join a latency spike to a log error and a configuration change unless all three carry the same name for the same service. OpenTelemetry's semantic conventions exist to standardize those names. The resource conventions define standard attributes for describing where telemetry comes from; service.name gets special handling and the SDK must supply a default for it. The resource page is marked "Mixed" stability, with some sections stable and others still in development, under semantic conventions version 1.44.0. [S9]
  2. Topology and configuration context. Topology turns "these events happened at the same time" into "these events are on connected components," which is what the root-cause research says inference alone struggles to provide. [S6][S7]
  3. History long enough to cover the cycles. Seasonal models need to have seen each cycle; the root-cause study found longer input windows help. [S1][S7]
  4. Labels from incidents. Precision and recall can only be measured if someone records which alerts mattered. [S4] Incident records are also the raw material for the LLM work. [S8]
  5. Change and maintenance context. The microservices survey's warning about deployments shifting baselines points to change records as essential input. [S6]

2.3 Standards and governance signals

  • OpenTelemetry semantic conventions continue to mature (version 1.44.0 at the time of writing). The generative-AI conventions, including agent spans and the Model Context Protocol, moved to a dedicated repository in 2026 and, as far as we could confirm, are not yet marked stable, so attribute names can still change between releases. [S9][S10] That matters for the future: if AI agents start acting on production systems, their actions can be traced with the same tooling as the systems themselves.
  • NIST AI Risk Management Framework (AI RMF 1.0), released January 26, 2023, is voluntary and organized around four functions: govern, map, measure and manage. [S11] Its FAQ, updated August 13, 2026, lists the trustworthiness characteristics (valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed) and notes that the July 23, 2025 AI Action Plan tasked NIST with revising the framework. [S12] NIST's Generative AI Profile (NIST AI 600-1) was published July 26, 2024. [S13]

2.4 How the learning can be tuned to one organization

Every lever below is grounded in the sources above. Where we suggest a specific value, it is labelled Illustrative.

LeverWhat it doesWhat to decide locally
Training windowHow much history the baseline learns fromLong enough to include each cycle you care about. Illustrative: several weeks for daily and weekly cycles; a full year or more if annual peaks matter.
SeasonalityWhich cycles the model expectsDaily, weekly, monthly close, fiscal year-end, enrollment or tax season. [S1]
Event calendarKnown one-off effectsHolidays, campaigns, planned migrations, as custom lists. [S1]
SensitivityWidth of the "normal" bandTrade precision against recall, and measure both. [S4]
SuppressionWhen not to alertMaintenance and approved change windows; downstream symptoms of a known upstream cause. [S3]
Grouping rulesWhat counts as "one problem"Time window, template similarity, topology hops. [S5][S6]
Feedback loopTeaching the system what matteredMark alerts useful or noise; link alerts to incident records. [S4][S8]
Domain modelsDifferent "normal" for different service typesBatch jobs, customer-facing APIs and network links behave differently; the evaluation research shows no single method suits all. [S2]
LLM summarizationPlain-language incident narrativesGround summaries in the organization's own incident and change records; keep a human reviewer. [S8][S13]

2.5 Where the research is heading: foundation models for time series

Two 2023-2024 papers describe pretrained "foundation" models for time series. One converts time-series values into a fixed vocabulary of tokens (by scaling and quantizing them) and trains standard language-model architectures, from about 20 million to 710 million parameters, on public and synthetic data; on a 42-dataset benchmark it reports zero-shot accuracy on unseen datasets comparable to, and occasionally better than, models trained on those datasets. [S14] Another uses a decoder-only design pretrained on a large time-series corpus and reports zero-shot accuracy close to supervised models trained per dataset. [S15]

Both are forecasting benchmarks, not operational-telemetry trials. They are a credible signal that "learning from scratch on your data" may become "starting pretrained and adjusting to your data." They do not yet show that pretrained models beat the simple methods the 2022 evaluation found competitive for anomaly detection. [S2]

3. Plausible outcomes to 2028-2030

These are scenarios, not predictions. Each lists the signals that would tip things its way.

Scenario A: Pretrained by default, tuned by exception. Baselines and forecasts start from pretrained time-series models and work reasonably well on day one. Local effort moves from training to telling the model about the business: calendars, SLOs, suppression rules and feedback.

Signals that would tip toward A: independent, published benchmarks on operational telemetry (not only general forecasting datasets) showing pretrained models matching or beating simple methods; telemetry naming conventions reaching stable status in more areas, which makes cross-organization pretraining more practical. [S2][S9][S14][S15]

Scenario B: Context is the differentiator. Detection algorithms become broadly similar. The gap between good and poor results comes from context: accurate topology, change records, consistent naming and labelled incident history. Organizations with that context get usable root-cause ranking; those without it get more noise.

Signals that would tip toward B: new root-cause research continuing to show inference-only methods struggling at scale while topology-aware methods improve; buyers increasingly asking for semantic-convention compliance and data portability. [S6][S7][S9]

Scenario C: Agents act inside guardrails. LLM-based agents not only summarize but take low-risk remediation steps (restart, scale, roll back) under pre-approved rules, with every step traced and reviewable.

Signals that would tip toward C: generative-AI and agent telemetry conventions maturing; the revised NIST AI RMF giving concrete guidance on autonomous actions; published incident studies showing agent-suggested mitigations performing well under human evaluation. [S8][S10][S12]

The three are not exclusive. A likely blend is pretrained models (A) whose usefulness depends on context (B), with automation (C) limited to the places where context is strongest.

4. What to do now

Each step below helps in all three scenarios.

For IT operations teams

  • Adopt consistent service naming now. Align on service.name and related resource attributes across metrics, logs and traces, following OpenTelemetry's resource conventions. This one step feeds every learning feature. [S9]
  • Write down the business calendar. List cycles (daily, weekly, month-end, fiscal year-end) and known events, and keep it where monitoring configuration can use it. [S1]
  • Separate "unusual" from "page-worthy." Let learned baselines raise unusual behavior to dashboards and tickets; reserve pages for SLO burn-rate conditions. Track precision, recall, detection time and reset time. [S3][S4]
  • Close the feedback loop. Make it easy to mark an alert as useful or noise, and link alerts to the incident they belonged to. This builds the labelled history that every scenario needs. [S4][S8]
  • Feed change and maintenance windows into suppression. Deployments shift baselines; the system should know when one happened. [S6]
  • Pilot with a holdout. When trying a new detection method, run it alongside the current one on the same services and compare measured precision and recall before switching. The 2022 evaluation shows outcomes vary widely by data. [S2]

For CIOs and CFOs

  • Fund context as well as features. Topology accuracy, configuration data and naming hygiene are where the research points for better root-cause ranking. [S6][S7]
  • Ask vendors for evidence on your data. Request a time-boxed trial with agreed measures (precision, recall, detection time) instead of relying on general claims. [S2][S4]
  • Protect portability. Prefer telemetry collected under open conventions so that learning features can be compared or changed later without re-instrumenting. [S9]
  • Map AI features to a governance framework. Use the NIST AI RMF functions (govern, map, measure, manage) to record who owns each learning feature, how it is measured and how it is switched off. [S11][S12]

For public-sector buyers

  • Write the calendar into requirements. Fiscal-year close, legislative sessions, enrollment periods and public-facing deadlines are predictable peaks; make tuning for them part of the statement of work. [S1]
  • Require explainability and audit trails. Ask that grouped alerts and root-cause suggestions show the evidence they used, and that any automated action is logged. [S6][S11]
  • Reference open standards in solicitations. Naming OpenTelemetry semantic conventions as a preferred data model supports competition and later re-procurement. [S9]
  • Reference NIST AI RMF and the Generative AI Profile when procuring LLM-assisted summarization or automation. [S12][S13]

Drafted with AI assistance; sources checked and interpreted by King Tech.

Planning for this in your organization?

King Tech collaborates on custom solution architecture: we work alongside your team to design an approach that fits your systems, your constraints and your timeline. Contact King Tech to start the conversation.

Book a consultation Ask a question

Sources