Linux Server Monitoring
最近因工作需要，研究了一下Linux服务器的监控方案，收获颇丰。
1 监控需求
服务器需要监控什么？可以分为硬件和软件，或者系统数据和业务数据。一般的监控解决方案，都是针对硬件、操作系统和常用软件（比如数据库、Docker之类）。涉及业务数据，需要二次开发。
2 监控方案设计
一般的监控方案，分为采集、存储、展示、告警，这四大模块或者功能。针对被监控服务器的数量，可灵活实施四个模块的部署方式。比较完善的整体解决方案，还包括“控制”模块，实现服务器集群的统一管理。
2.1 采集
数据采集程序，或者叫“探针”，一般是部署在被监控服务器上的程序。用于采集相关数据，要求占用系统资源小（主要是CPU、内存、磁盘、网络等），对系统影响小。
数据采集的方式，可以采用“推”（push）和“拉”（pull）模式。
“推”是数据采集程序主动把数据从采集端发到存储端。数据具有良好的实时性，方便内网部署并推送到外网服务器。但采集端太多，或者采集的数据比较大，需要考虑存储端的承受能力。遇到存储端没有收到数据时，不能确定是网络问题还是采集端问题。
“拉”是数据采集程序暴露出来，例如开放HTTP服务的端口，存储端去访问并获取数据。存储端也有更多的主动权，决定拉取频率，甚至决定采集样本，能降低带宽、减轻存储端的压力。采集不到数据时，能区分网络问题和采集端问题。如果对数据有实时需求，采集端需要保存未拉走的数据。
针对采集端有时只能部署在内网的情况，有的解决方案会提供“代理”或者“跳板”功能，实现采集端与存储断之间的数据连接。
2.2 存储
数据存储，就是把监控数据持久化，可以是文件（比如CSV文件），也可以是数据库（比如MySQL、InfluxDB）。目前主流的方案，基本采用时序数据库，例如InfluxDB。专门针对这种大量连续时间的数据，提供存储、查询、统计等功能。
- 时序数据库入门系列：什么是时序数据库
https://zhuanlan.zhihu.com/p/350041920
2.3 展示
数据展示，一般是把监控数据生成图表，以便更直观地查看和分析。简单的方案是用Microsoft Excel之类的软件，根据导出CSV文件的数据，生成各种图表。主流和灵活的方案是使用可视化软件，例如Grafana，连接时序数据库并生成各种图表。Grafana能够实现实时展示和历史分析。
2.4 告警
通过检测采集的数据，发现超过指定危险指标时，向相关人员发送消息，就是告警。由于相关人员一般不会24小时盯着服务器，所以需要机器进行告警。InfluxDB、Prometheus、Grafana等都有告警功能。一般开源系统只提供邮件或Web Hook（调用钉钉接口）通知，商业系统（例如：阿里云的云监控）会有短信或电话通知。
3 解决方案
服务器监控的解决方案，像编程语言一样，没有一个万能方案，需要根据情况进行选择。这里列举一些相关软件或方案。
3.1 dstat
基于Python。默认一秒采集一条数据，数据定制性高。数据可显示在终端，也可导出CSV文件。需要使用第三方软件，例如Microsoft Excel之类，生成图表和分析数据。高级玩法是，搭配Fluentd，保存数据到InfluxDB，再用Grafana展示、分析。
优点是占用资源小，数据简单。缺点是由于使用CSV格式，复杂数据记录得不够好。而且当前版本（0.7.4）有bug，部署时需要自己修正。
3.2 njmon
C语言开发。nmon的升级版，可设置不收集的数据，数据格式采用JSON。不支持终端显示，原生支持导出文件和发送到InfluxDB。有官方工具处理保存的JSON文件。推荐的玩法是njmon + InfluxDB + Grafana。
优点是占用资源小，作者对整个监控方案考虑比较全面。缺点是对AIX较好但对Linux支持不足。比如Debian 11需要自己编译。Grafana的njmon模板大多针对AIX，而且仅有的Linux模板是针对InfluxDB v1，即使用InfluxQL而不是Flux。
3.3 glances
- 官网：https://nicolargo.github.io/glances/
- 源码：https://github.com/nicolargo/glances
- 文档：https://glances.readthedocs.io/en/latest/
基于Python，开源跨平台，界面优秀。支持三种模式：单独运行、C/S、Web。提供XML-RPC服务、RESTful JSON接口，也可把数据保存到其它系统，包括InfluxDB。本身支持配置“Actions”，根据事件触发相应脚本，实现告警。
占用资源较大（包括CPU和磁盘空间），界面优秀，玩法多。适合桌面系统的监控。
3.4 InfluxDB
- 官网：https://www.influxdata.com/
- 源码：https://github.com/influxdata/influxdb
- 文档：https://university.influxdata.com/
- 数据收集方案：https://university.influxdata.com/courses/data-collection-with-telegraf-tutorial/
InfluxDB只是个时序数据库，但是该公司开发了Telegraf作为数据收集工具（采用“推”模式），并且InfluxDB新增了告警和图形化展示，形成一个完整的数据收集方案。
3.5 Prometheus
- 官网：https://prometheus.io/
- 源码：https://github.com/prometheus/prometheus
- 文档：https://prometheus.io/docs/introduction/overview/
基于Go，监控、告警工具，使用“拉”模式采集数据。
3.6 Zabbix
企业级的开源的服务器监控管理系统，是完整的解决方案，基本可以替代阿里云的云监控之类的系统。Web控制台基于PHP，支持中文显示；采集端基于C，升级版改为Go；数据存储使用MySQL，未支持时序数据库是最突出的缺点。另外，告警功能不支持电话和短信通知。
非常适合企业内部管理服务器集群，便于运维人员使用。
3.7 阿里云的云监控
一般云主机的服务商都提供云监控功能，且基本监控免费，高级功能收费。阿里云的云监控，还能监控非阿里云的主机。使用这些云监控前，要确定是否可以把服务器监控数据发给云厂商，甚至安装云厂商的采集软件。
4 方案选型
根据不同的情况，总结一下各个方案的选型。
4.1 云主机
如果是购买云主机，可以考虑云服务提供商的云监控，一般免费提供基础监控功能，例如阿里云的云监控。但前提是，云主机可以安装云监控的采集端软件，并且接受相关数据上传到云服务提供商那边。另外，高级监控功能，需要付额使用。
4.2 运维管理的服务器集群
企业内部，有专门的运维人员管理服务器，针对硬件或操作系统相关数据的监控，则可以考虑Zabbix。
4.3 业务数据
node_exporter + Prometheus + Grafana，或者 Telegraf + InfluxDB + Grafana，这种方案适合收集业务日志。部署了InfluxDB，还能存储其它数据，个人觉得比较好玩。