Observability 2.0: OpenTelemetry, AIOps, and Treating Observability as a Platform

Throughout the 2010s, enterprise observability suffered from telemetry fragmentation. Distributed services utilized disparate logging formats, proprietary metric agents, and siloed tracing backends. Incident triage demanded correlating disparate dashboards and manually aligning timestamps across incompatible schemas, turning root-cause analysis into an exercise in organizational archaeology.

This approach does not scale. As the number of micro‑services grows, the manual effort multiplies. Observability 2.0 recognizes that observability must be a platform concern, standardized, automatic, and available to every service by default, not a per‑team implementation choice.

The Three Pillars, and Why They Need to Be Connected

Observability is conventionally described as three pillars: logs, metrics, and traces. The pillars are only useful when they are connected.

• Logs record discrete events: a request arrived, an error occurred, a payment was processed. They are high‑cardinality and human‑readable, but expensive to store and slow to query at scale. Because each log line can contain unique identifiers, storing millions per second quickly inflates storage costs and makes ad‑hoc searches sluggish.
• Metrics record aggregated measurements over time: request rate, error rate, latency percentiles, CPU usage. They are cheap to store and fast to query, but they lose the detail needed to diagnose individual failures. Aggregations collapse the raw data into buckets, so when an anomaly appears you cannot trace it back to a single request without additional context.
• Traces record the path of a single request through a distributed system: which services it touched, how long each took, where it failed. They are essential for diagnosing latency and errors in distributed systems, but they require instrumentation at every service boundary. If a service omits the tracing hook, the request’s journey breaks, leaving gaps in the end‑to‑end view.

The problem with treating these as separate pillars is that a spike in the error‑rate metric tells you that something is wrong, but not why. To find out why, you need to jump from the metric to the logs for that time window, then find the trace ID in the logs, then open the trace. If those three systems use different identifiers, different timestamps, or different service names, that correlation is manual and error‑prone. Because each system stores its data in a silo, the engineer must perform several look‑ups, increasing mean‑time‑to‑resolution.

OpenTelemetry solves this by standardizing the data model and the instrumentation API across all three signals.

OpenTelemetry: The De Facto Standard

OpenTelemetry (OTel) is a CNCF project that provides a vendor‑neutral SDK, API, and collector for generating, collecting, and exporting telemetry data. It has become the de facto standard for instrumentation in cloud‑native systems.

The key design decision: OpenTelemetry separates instrumentation from export. You instrument your code once using the OTel API. You configure the collector to export to whatever backend you use, Jaeger, Prometheus, Grafana Tempo, Datadog, Honeycomb, or any other OTel‑compatible backend. Switching backends does not require re‑instrumenting your code. Because the collector acts as a translation layer, you can point it at a new endpoint and instantly start feeding data to a different UI.

// OpenTelemetry instrumentation - instrument once, export anywhere
import { trace, metrics, context } from '@opentelemetry/api';

const tracer = trace.getTracer('order-service', '1.0.0');
const meter = metrics.getMeter('order-service', '1.0.0');

const orderCounter = meter.createCounter('orders.created', {
  description: 'Number of orders created',
});

async function createOrder(orderData: OrderInput): Promise<Order> {
  return tracer.startActiveSpan('createOrder', async (span) => {
    try {
      span.setAttributes({
        'order.customerId': orderData.customerId,
        'order.itemCount': orderData.items.length,
      });

      const order = await orderRepository.save(orderData);

      orderCounter.add(1, { 'order.channel': orderData.channel });
      span.setStatus({ code: SpanStatusCode.OK });
      return order;
    } catch (error) {
      span.recordException(error as Error);
      span.setStatus({ code: SpanStatusCode.ERROR });
      throw error;
    } finally {
      span.end();
    }
  });
}

Auto-instrumentation

For common frameworks and libraries, OTel provides auto‑instrumentation packages that add tracing and metrics without modifying application code. For Node.js:

// sdk.ts - loaded before application code
import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: 'http://otel-collector:4318/v1/traces' }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

This automatically instruments HTTP clients, Express/Fastify/Hapi routes, database clients (pg, mongoose, redis), and more, without touching application code. Consequently, developers can focus on business logic while the runtime records the necessary signals.

The OTel Collector

The OTel Collector is a standalone process that receives telemetry from applications, processes it (filtering, sampling, enriching), and exports it to one or more backends. Running a collector sidecar or daemonset means applications only need to know one endpoint, the collector handles routing. By centralising processing, you can apply consistent sampling policies and enrich every span with environment metadata without touching each service.

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
  otlp/jaeger:
    endpoint: jaeger:4317
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [otlp/jaeger]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]

Observability as a Platform Concern

The shift from per‑team observability to platform observability means that instrumentation, collection, and baseline dashboards are provided by the platform, not implemented by each team.

A platform observability setup typically provides:

• Auto-instrumentation by default: services get traces and metrics without writing instrumentation code, through sidecar injection or SDK defaults. The platform injects the OTel SDK at container start‑up, so every request is automatically captured.
• Standardized service metadata: every span and metric carries consistent attributes, service.name, service.version, deployment.environment, k8s.pod.name, so queries work across all services. When you query for a specific version, the attribute filters uniformly across logs, metrics, and traces.
• Baseline dashboards: every service automatically gets a RED dashboard (Rate, Errors, Duration) without any team‑specific configuration. These dashboards surface the three core health signals and let you spot regressions instantly.
• Correlation IDs propagated automatically: a trace ID generated at the API gateway is propagated through every downstream service call, so a single trace shows the full request path. Because the ID travels in HTTP headers, no manual stitching is required.

Standardized instrumentation ensures every newly provisioned service exports uniform OTLP telemetry on day one. Platform-level telemetry injection compresses service onboarding cycles, eliminating manual tracing boilerplate and guaranteeing consistent cross-service trace propagation.

AIOps: AI‑Assisted Anomaly Detection and Root Cause Analysis

Standard observability tells you what happened. AIOps uses machine learning to tell you what is unusual and why.

Anomaly detection

Traditional alerting uses static thresholds: alert when error rate exceeds 1%. Static thresholds produce false positives during expected traffic spikes and miss anomalies that stay below the threshold. ML‑based anomaly detection learns the normal pattern for each metric, including seasonality, day‑of‑week effects, and deployment‑correlated changes, and alerts when the pattern deviates unexpectedly. The model continuously updates its baseline, so a sudden drop after a rollout triggers an alert even if the absolute value remains low.

Tools such as Grafana's ML anomaly detection, Datadog's Watchdog, and Dynatrace's Davis AI apply this approach. The key requirement is sufficient historical data, typically several weeks, to establish a reliable baseline.

Root cause analysis

When an incident occurs, the hardest part is often identifying the root cause across dozens of services and hundreds of metrics. AIOps tools can correlate anomalies across services, identify which metric changed first (the likely cause rather than the symptom), and surface the relevant traces and logs automatically. The system surfaces a timeline that highlights the earliest deviation, letting engineers focus their investigation.

This does not replace human judgment. An AI that identifies “database query latency increased 300 ms before the API error rate spiked” is providing a useful hypothesis, not a confirmed diagnosis. The engineer still needs to verify the hypothesis and decide on the fix.

Practical limits

AIOps tools are most useful for known failure patterns, the kinds of incidents that have happened before and left a pattern in the telemetry. Novel failure modes, configuration errors, and logic bugs often do not produce the kind of metric anomalies that ML models are trained to detect. Human investigation remains essential.

The Observability Maturity Model

Level	Characteristics
0, Blind	No structured logging, no metrics, no tracing
1, Reactive	Logs exist; metrics are ad hoc; debugging requires SSH
2, Proactive	Structured logs, basic metrics, alerting on thresholds
3, Correlated	Traces connect logs and metrics; RED dashboards for all services
4, Platform	Auto‑instrumentation, standardized metadata, baseline dashboards by default
5, Intelligent	Anomaly detection, automated correlation, AI‑assisted root cause analysis

Most organizations are at level 2 or 3. The jump to level 4, platform observability, is the highest‑leverage investment, because it makes every subsequent service observable without additional work. Once every service emits uniform signals, you can layer analytics and alerts on top without per‑team tweaks.

Why This Order Matters

The maturity levels are not arbitrary. Each level is a prerequisite for the next. You cannot do meaningful AIOps (level 5) without correlated signals (level 3), because ML anomaly detection needs a consistent data model to correlate across services. You cannot get correlated signals without standardized instrumentation (level 4), because correlation requires shared identifiers, trace IDs, service names, timestamps, that only exist if every service emits them in the same format. If you skip steps, the downstream layers inherit gaps, and the AI model churns on noisy inputs.

This is why teams that skip to AIOps tooling without first achieving platform observability get poor results: the ML models are correlating inconsistent data and producing noisy, unreliable alerts. The investment in standardization pays off at every subsequent level. A clean, uniform pipeline reduces false positives and shortens the time from detection to remediation.