How to Build a Unified Monitoring System for Microservices: Key Dimensions & Scenarios

Introduction

Microservices are an architectural style where a large, complex application consists of many loosely coupled services that can be deployed independently, each focusing on a single responsibility.

Compared with monolithic applications, microservice monitoring is more complex because business logic is spread across many processes; locating the root cause of an issue can feel like finding a needle in a haystack, necessitating a robust monitoring system.

Building such a system takes time and must evolve with changing business scenarios. This article discusses several monitoring dimensions and atomic scenarios to help you design a unified data collection and visualization platform.

Monitoring Dimensions in Microservices

Unlike traditional monitoring that focuses on machines, microservice monitoring adopts a service‑centric view and can be layered into data, resource, and code dimensions.

Data Dimension : Most services are web‑based, receiving requests through an entry point (APP or web page) that passes through a load balancer or gateway before reaching the backend, which then processes the request and writes to a database.

Resource Dimension : Services often run in the cloud on virtual machines. Monitoring must capture VM performance metrics (CPU, memory, disk I/O) as well as underlying physical host metrics and virtual network bandwidth.

Code Dimension : Application Performance Monitoring (APM) collects runtime information from the code side, essential for tracing calls across dozens of services in a microservice flow.

Key Monitoring Scenarios

Microservice monitoring is characterized by a large number of services and complex inter‑service calls. Rapid fault isolation relies on key metrics. Based on the three dimensions, eight atomic monitoring scenarios are identified:

URL Monitoring : Measure response time and status codes of API calls initiated via URLs to assess overall business health.

Host Monitoring : Deploy agents to collect basic host metrics (CPU, memory, I/O) and optionally enable data collection for open‑source components like Tomcat or Nginx.

Product Monitoring : Cloud providers expose resources (hosts, networks, storage, middleware) as products; each product reports its own health metrics.

Component Monitoring : Collect metrics from open‑source components (Tomcat, Nginx, Netty) via agents.

Custom Monitoring : Service instances report business‑specific data via APIs, supporting multi‑instance reporting and multidimensional alert queries.

Resource Monitoring : Users report custom data per resource, with each resource having independent monitoring items.

APM : Implement language‑specific agents to capture function call relationships, service call topologies, and response times, either by SDK injection or meta‑programming.

Event Monitoring : Track discrete events in public‑cloud products or business logic (e.g., disk unavailability, SSD reset) with unified storage, analysis, and visualization.

By collecting data for these atomic scenarios, a unified UI can display metrics across the three dimensions, using time‑series charts, pie charts, or bar charts to support user‑centric analysis.

The article focuses on data collection and visualization; storage and alerting mechanisms are left for future articles.