MCMMCM DocsEngineering (Internal)
HLDModulesObservability
v1.2 is unreleased — see v1.1 for the current stable release.

Observability Overview

Real-time metrics, log streaming, and distributed trace collection across cloud resources via the ELK stack.

Observability

The Observability module provides real-time infrastructure and application monitoring across three pillars — Metrics, Logs, and Traces. All telemetry is collected by Elastic Beats agents, enriched by Logstash, stored in Elasticsearch, and surfaced in the MCM UI.

Canonical Observability tool usage by provider and resource type is tracked in the Provider and Resource Reference.


Provider Support

Supported

  • AWS AWS
  • Azure Azure
  • GCP GCP
  • Ubuntu Ubuntu
  • Docker Docker
  • Kubernetes Kubernetes

Not Supported

  • GitHub GitHub
  • Docker Hub Docker Hub

Three Pillars


ELK Stack Architecture


Agent Deployment by Resource Type

Resource TypeAgent DeploymentSSH Setup Required
AWS EC2MCM deploys Metricbeat + Filebeat + APM agent over SSHYes — via UI setup dialog
Ubuntu HostMetricbeat + Filebeat installed during host onboardingNo — pre-configured
Azure VMMCM deploys agents over SSHYes — via UI setup dialog
GCP Compute EngineMCM deploys agents over SSHYes — via UI setup dialog
Docker ContainerMetricbeat + Filebeat as sidecar containers via Docker labelsNo — pre-configured
K8s Cluster / PodMetricbeat + Filebeat deployed as a DaemonSet in the clusterNo — pre-configured

Resources that require SSH setup (EC2, Azure VM, GCP) display a Set Up Observability prompt in the MCM UI until the SSH credentials are provided. Resources that are pre-configured (Ubuntu, Docker, Kubernetes) skip this step entirely — Observability is active as soon as the resource is onboarded.


Use-Cases

  • Real-time CPU and memory monitoring with configurable alert thresholds.
  • Centralised log search across all cloud resources from a single UI.
  • Distributed trace analysis to identify latency bottlenecks and error sources.
  • Fleet-wide Observability dashboard showing resource health across all accounts.
  • Per-account and per-resource drill-down into metrics, logs, and traces.

Tool Reference

ToolRoleTargetsStorage
MetricbeatMetrics collectionAll resource typesElasticsearch
FilebeatLog shippingAll resource typesElasticsearch (via Logstash)
LogstashLog parsing & enrichmentLog pipelineElasticsearch
Elastic APM ServerTrace ingestionAPM-instrumented applicationsElasticsearch
ElasticsearchCentral telemetry storeAll three pillars

Metricbeat

Targets: Linux/Windows hosts, containers, Kubernetes pods.

Modules used:

  • System module: CPU, memory, network, disk I/O at configurable intervals (default 10s).
  • Docker module: Container-level CPU, memory, network, and block I/O metrics.
  • Kubernetes module: Node, pod, and namespace resource metrics via the Kubernetes API.

Filebeat

Targets: Log files, container stdout/stderr, Kubernetes pod logs.

Inputs:

  • filestream input for log files (/var/log/syslog, /var/log/auth.log, application log paths).
  • container input for Docker container logs via the Docker socket.
  • kubernetes autodiscovery for pod log collection in Kubernetes clusters.

All log events are forwarded to Logstash for parsing before landing in Elasticsearch.


Logstash

Role: Receives raw log events from Filebeat, applies grok patterns for syslog and common log formats, enriches events with resource metadata (account ID, region, resource type), and writes structured documents to Elasticsearch.


Elastic APM Server

Targets: Applications instrumented with Elastic APM agents or any OpenTelemetry SDK (via the OTLP endpoint).

Data collected: Trace ID, operation name, duration, HTTP status, span tree, and error details. See Traces for full field reference.

On this page