Choosing the Right Open‑Source Monitoring System: Zabbix, Open‑Falcon, Prometheus

01 Essential Monitoring Basics

Monitoring systems, often called the "third eye," are essential; four fundamental concepts are must‑knows.

1. Seven Core Functions of Monitoring Systems

Real‑time data collection : hardware, OS, middleware, applications, etc.

Real‑time status feedback : multi‑dimensional statistics and visualization show normal or abnormal state.

Predictive fault and alerting : anticipate failures and issue alerts.

Assist fault localization : provide metric data for analysis.

Assist performance tuning : data for slow SQL, response time, etc.

Assist capacity planning : support planning for servers, middleware, clusters.

Assist automation : data for auto‑scaling or SLA‑based degradation.

2. Proper Use of Monitoring Systems

Any online incident inevitably involves a monitoring problem.

When reviewing incidents, ask three monitoring‑related questions: Is monitoring in place? Is it timely? Does the information help locate the issue quickly?

A mature team defines a monitoring specification to standardize usage.

Understand the monitored object's operation : e.g., know JVM heap structure and GC mechanism before monitoring JVM.

Define appropriate metrics : e.g., request count, latency, timeout, error count for an API.

Set reasonable alert thresholds and levels : avoid noisy alerts.

Establish a fault‑handling process : ensure on‑call mechanisms are in place.

3. Monitoring Targets and Metrics

Monitoring covers hardware, server basics, databases, middleware, and applications.

3.1 Hardware Monitoring

Power, CPU, temperature, fan, physical disks, RAID, memory, NIC status.

3.2 Server Basic Monitoring

CPU usage (per core and overall)

Memory used/available

Disk usage and I/O throughput

Network inbound/outbound traffic and TCP connections

3.3 Database Monitoring

Connection count, QPS, TPS, session concurrency, cache hit rate, replication lag, lock status, slow queries.

3.4 Middleware Monitoring

Nginx: active, waiting, dropped connections; request volume, latency, 5XX rate.

Tomcat: max threads, current threads, request volume, latency, error count, heap usage, GC count and duration.

Cache: successful connections, blocked connections, used memory, fragmentation, request volume, latency, hit rate.

Message queue: connection count, queue depth, production/consumption rates, backlog.

3.5 Application Monitoring

HTTP API: availability, request volume, latency, error count.

RPC API: request volume, latency, timeout, rejection.

JVM: GC count, GC time, memory region sizes, thread count, deadlock threads.

Thread pool: active threads, queue size, execution latency, rejected tasks.

Connection pool: total and active connections.

Log monitoring: access and error logs.

Business metrics: e.g., PV, order count.

4. Basic Monitoring Workflow

Data collection : log agents, JMX, REST APIs, command line, SDKs.

Data transport : push or pull via TCP/UDP/HTTP.

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

Data visualization : graphical dashboards.

Alerting : flexible rules with email, SMS, IM notifications.

02 Mainstream Open‑Source Monitoring Systems

Three widely used solutions are introduced: Zabbix, Open‑Falcon, and Prometheus.

1. Zabbix

Zabbix, created in 1998, uses C for core components and PHP for the web UI. It offers comprehensive monitoring and is used by roughly 70 % of internet companies.

Key components:

Zabbix Server : receives data from agents/proxies, supports JMX, SNMP, stores data, triggers alerts.

Zabbix Proxy : optional distributed collector.

Zabbix Agentd : installed on hosts, collects data, supports push and pull.

Database : stores configuration and metrics; supports MySQL, Oracle, and optional time‑series DB.

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

Advantages: mature product, rich data collection methods, strong extensibility, easy web‑based configuration.

Disadvantages: relational DB write bottleneck at scale, limited application‑level monitoring, lack of tags for multidimensional aggregation, C‑based code makes deep customization harder.

2. Open‑Falcon

Open‑Falcon, open‑sourced by Xiaomi in 2015, is built with Go and Python, offering high performance and extensibility.

Key components:

Falcon‑agent : collects over 200 basic metrics automatically; supports custom plugins and HTTP push.

Transfer : distributes data to Graph and Judge, supports sharding and OpenTSDB export.

Graph : stores metrics using RRDTool, handles high write rates.

Judge & Alarm : evaluates data for alerts and consolidates notifications.

API : hides storage details and serves query results.

Advantages: automatic metric collection, strong storage scalability, tag‑based multidimensional model, unified plugin management, easy custom monitoring via Proxy‑gateway.

Disadvantages: limited community activity, complex UI, installation complexity due to many components.

3. Prometheus

Prometheus, launched in 2015 by former Google engineers, is Go‑based and backed by the Cloud Native Computing Foundation.

Key components:

Prometheus Server : scrapes targets, stores data locally, provides PromQL for queries.

Exporter : exposes metrics over HTTP for pull‑based collection.

Push Gateway : buffers short‑lived job metrics.

Alert Manager : handles alert routing.

Web UI : simple console; often paired with Grafana.

Advantages: lightweight deployment, high processing capacity, tag‑enabled multidimensional model, powerful PromQL, native support for containers and Kubernetes.

Disadvantages: lacks built‑in clustering and long‑term storage, requires network planning for pull model.

03 Monitoring System Selection Advice

When choosing a solution, clarify monitoring requirements, scale, and alert needs. For small‑to‑medium environments, Zabbix works well if you stay within a few hundred nodes. For application‑level metrics and container environments, Open‑Falcon or Prometheus are preferable.

Consider maturity, data model flexibility, and integration with Grafana for visualization. Multiple monitoring systems can coexist during early stages, and custom development may be needed as needs evolve.

Final Thoughts

This article systematically outlines monitoring fundamentals, architectures, and the strengths and weaknesses of three major open‑source systems to help readers make informed technology selections.