A Comprehensive Overview of Monitoring Systems: Fundamentals, Popular Open‑Source Solutions, and Selection Guidance

This article provides a systematic overview of monitoring systems, covering essential monitoring knowledge, common metrics, basic monitoring workflow, and comparative analysis of three popular open‑source monitoring solutions.

1. Essential Monitoring Fundamentals

Monitoring is likened to ancient sentries: it raises early warnings when problems arise, allowing rapid response. For applications, monitoring acts as a "third eye" to pinpoint issues such as Redis failures or memory exhaustion, and can proactively trigger alerts to prevent incidents.

Help locate faults: Use metric data to assist fault analysis and pinpoint the source.

Alert to reduce failure rate: Issue early warnings for potential problems.

Assist capacity planning: Provide data for server, middleware, and cluster capacity decisions.

Assist performance tuning: Optimize JVM GC, interface latency, slow SQL, etc.

2. Common Monitoring Objects and Metrics

Server monitoring: CPU, memory, disk usage, disk I/O throughput, network traffic, etc.

MySQL monitoring: TPS, QPS, connection count, slow queries, InnoDB buffer hit rate, etc.

Redis monitoring: Memory usage, cache hit rate, key count, response time, client connections, persistence metrics, etc.

MQ monitoring: Connection count, queue length, production/consumption rates, message backlog, etc.

Application monitoring: HTTP interface: URL health, request volume, latency, error count. JVM: GC count, GC time, memory region sizes, thread count, deadlock threads. Thread pool: active threads, task queue size, execution latency, rejected tasks.

3. Basic Monitoring Process

Data collection: Methods include log instrumentation, JMX, REST APIs, command‑line tools, or SDKs.

Data transmission: Push or pull via TCP/UDP/HTTP to the monitoring system.

Data storage: Relational databases (MySQL, Oracle) or time‑series databases (RRDTool, OpenTSDB, InfluxDB, HBase).

Data visualization: Graphical presentation of metrics.

Monitoring alerts: Flexible alert rules with email, SMS, IM, etc.

4. Comparison of Common Open‑Source Monitoring Systems

Below are brief introductions, architectures, and pros/cons of three widely used monitoring tools.

1. Zabbix Introduction

Zabbix, launched in 1998, has a C‑based core and a PHP web UI. It is a mature, feature‑rich solution used by many internet companies.

Zabbix architecture includes:

Zabbix Server: Core component receiving data from Agents/Proxies, storing data, and triggering alerts.

Zabbix Proxy: Optional distributed collector to reduce server load.

Zabbix Agentd: Deployed on monitored hosts, supports push and pull data collection.

Database: Stores configuration and metrics; supports MySQL, Oracle, and newer time‑series DBs.

Web Server: PHP‑based GUI for data display and alert configuration.

Zabbix的优势 :

Product maturity: Long history, extensive documentation, and many plugins.

Rich collection methods: Agent, SNMP, JMX, SSH, etc.

Zabbix的劣势 :

Requires agents on monitored hosts; large data volume stored in databases can become a bottleneck.

2. Open‑Falcon (Xiaomi)

Open‑Falcon, open‑sourced by Xiaomi in 2015, is built with Go and Python. It follows a Server‑Agent model with additional components for scalability.

Falcon‑agent: Go‑based collector on monitored machines, gathering ~200 metrics.

Transfer: Distributes data to Graph (storage) and Judge (alerting), supports OpenTSDB export.

Graph: Stores metrics using RRDTool, handling high write rates.

Judge & Alarm: Real‑time alert calculation and convergence handling.

API: Provides unified query interface for users.

Open-Falcon优势 :

Automatic collection: 200+ built‑in metrics without configuration.

Strong storage: Distributed time‑series storage with consistent hashing.

Flexible data model: Tag‑based multi‑dimensional aggregation.

Unified plugin management: Centralized script distribution via HeartBeat Server.

Custom monitoring support: Easy to add application‑level metrics via Proxy‑gateway.

缺点:

Limited monitoring types (e.g., no native Tomcat/Apache support).

Community activity is low; updates are infrequent.

3. Prometheus (Next‑Gen Monitoring)

Prometheus, released by former Google engineers in 2015, is a Go‑based open‑source monitoring and alerting framework with strong community support and native Kubernetes integration.

Key components:

Exporter: Exposes metrics via HTTP for Prometheus to scrape (e.g., node_exporter, mysqld_exporter).

Prometheus Server: Pulls metrics, stores them in a local time‑series DB, and provides PromQL for queries.

Pushgateway: Allows short‑lived jobs to push metrics for Prometheus to scrape.

Alertmanager: Handles alert deduplication, grouping, and routing to email, WeChat, webhook, etc.

Web UI: Simple built‑in console; often paired with Grafana for dashboards.

Prometheus优点 :

Active community: Over 40k GitHub stars and continuous maintenance.

Efficient storage: Single binary, local disk storage, no external DB dependencies.

Excellent container monitoring: Auto‑discovery, native k8s and etcd support.

Pull‑model architecture: Flexible deployment across environments.

Prometheus缺点 :

Focused on metrics; does not cover logs, events, or tracing.

All scrape targets must be reachable, requiring careful network planning.

Large metric sets may need pruning.

5. Selection Recommendations

Clearly define monitoring requirements: objects, scale, and alerting needs.

Start with an open‑source solution; avoid over‑engineering an all‑in‑one platform initially.

For hundreds of nodes , Zabbix is mature and stable; performance can be improved with proxies, sharding, SSDs, or push collection.

Zabbix excels at server monitoring but lacks deep application‑level insights; Open‑Falcon and Prometheus handle custom metrics better.

New‑generation systems offer flexible data models, modern time‑series storage, and powerful alerts—choose Open‑Falcon for massive scale or Prometheus for container/Kubernetes environments.

All three integrate well with Grafana for rich visualizations.

Multiple monitoring systems can coexist; consider future integration with CMDB or custom APIs.

END