监控服务概述
无监控，不运维，监控是自动化运维的重要组成部分。下面是常用的监控对象以及监控指标：
硬件监控
电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态
服务器基础监控
- CPU：单个CPU以及整体的使用情况
- 内存：已用内存、可用内存
- 磁盘：磁盘使用率、磁盘读写的吞吐量
- 网络：出口流量、入口流量、TCP连接状态
数据库监控
数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询
中间件监控
- Nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
- Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
- 缓存 ：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
- 消息队列：连接数、队列数、生产速率、消费速率、消息堆积量
应用监控
- HTTP接口：URL存活、请求量、耗时、异常量
- RPC接口：请求量、耗时、超时量、拒绝量
- JVM ：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
- 线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数
- 连接池：总连接数、活跃连接数
- 日志监控：访问日志、错误日志
- 业务指标：视业务来定，比如PV、订单量等
主流监控软件
目前主流的监控软件比如zabbix、Prometheus、Nagios等各有优劣。选择监控工具的原则是根据公司业务场景选择。
Zabbix
Zabbix是老牌监控软件的优秀代表，监控功能很全面，使用也很广泛。核心组件采用C语言开发，Web端采用PHP开发。
优势：
- 产品成熟：由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景。
- 采集方式丰富：支持Agent、SNMP、JMX、SSH等多种采集方式，以及主动和被动的数据传输方式。
- 较强的扩展性：支持Proxy分布式监控，有agent自动发现功能，插件式架构支持用户自定义数据采集脚本。
- 配置管理方便：能通过Web界面进行监控和告警配置，操作方便，上手简单。
劣势：
- 性能瓶颈：机器量或者业务量大了后，关系型数据库的写入一定是瓶颈，官方给出的单机上限是5000台，个人感觉达不到，尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库，不过成熟度还不高。
- 应用层监控支持有限：如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能），zabbix没有提供对应的sdk，通过插件式的脚本也能曲线实现此功能，个人感觉zabbix就不是做这个事的。
- 数据模型不强大：不支持tag，因此没法按多维度进行聚合统计和告警配置，使用起来不灵活。
- 方便二次开发难度大：Zabbix采用的是C语言，二次开发往往需要熟悉它的数据表结构，基于它提供的API更多只能做展示层的定制。
Open-Falcon
Open-falcon 是小米2015年开源的企业级监控工具，采用Go和Python语言开发。小米初期也使用的Zabbix进行监控，但是机器量和业务量上来后，Zabbix就有些力不从心了。因此，后来自主研发了Open-Falcon，在架构设计上吸取了Zabbix的经验，同时很好地解决了Zabbix的诸多痛点。这是一款灵活、高性能且易扩展的新一代监控方案，目前小米、美团、滴滴等超过200家公司在使用它。
优势：
- 自动采集能力：Falcon-agent 能自动采集服务器的200多个基础指标（比如CPU、内存等），无需在server上做任何配置，这一点可以秒杀Zabbix.
- 强大的存储能力：底层采用RRDTool，并且通过一致性hash进行数据分片，构建了一个分布式的时序数据存储系统，可扩展性强。
- 灵活的数据模型：借鉴OpenTSDB，数据模型中引入了tag，这样能支持多维度的聚合统计以及告警规则设置，大大提高了使用效率。
- 插件统一管理：Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理，可通过HeartBeat Server分发给agent，减轻了使用者自主维护脚本的成本。
- 个性化监控支持：基于Proxy-gateway，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求，集成方便。
劣势：
- 整体发展一般：社区活跃度不算高，同时版本更新慢，有些大厂是基于它的稳定版本直接做二次开发的，关于以后的前景其实有点担忧。
- UI不够友好：对于业务线的研发来说，可能只想便捷地完成告警配置和业务监控，但是它把机器分组、策略模板、模板继承等概念全部暴露在UI上，感觉在围绕这几个概念设计UI，理解有点费劲。
- 安装比较复杂：个人的亲身感受，由于它是从小米内部衍生出来的，虽然去掉了对小米内部系统的依赖，但是组件还是比较多，如果对整个架构不熟悉，安装很难一蹴而就。
Prometheus
Prometheus（普罗米修斯）是2015年正式发布的开源监控系统，采用Go语言开发。它有Google与k8s的强力支持，开源社区异常火爆。
Prometheus 的未来前景被相当看好，号称下一代监控，它和Open-Falcon最大不同在于：数据采集是基于Pull模式的，而不是Push模式，并且架构非常简单。
优势：
- 轻量管理：架构简单，不依赖外部存储，单个服务器节点可直接工作，二进制文件启动即可，属于轻量级的Server，便于迁移和维护。
- 较强的处理能力：监控数据直接存储在Prometheus Server本地的时序数据库中，单个实例可以处理数百万的metrics。
- 灵活的数据模型：同Open-Falcon，引入了tag，属于多维数据模型，聚合统计更方便。
- 强大的查询语句：PromQL允许在同一个查询语句中，对多个metrics进行加法、连接和取分位值等操作。
- 很好地支持云环境：能自动发现容器，同时k8s和etcd等项目都提供了对Prometheus的原生支持，是目前容器监控最流行的方案。
劣势：
- 功能不够完善：Prometheus从一开始的架构设计就是要做到简单，不提供集群化方案，长期的持久化存储和用户管理，而这些是企业变大后所必须的特性，目前要做到这些只能在Prometheus之上进行扩展。
- 网络规划变复杂：由于Prometheus采用的是Pull模型拉取数据，意味着所有被监控的endpoint必须是可达的，需要合理规划网络的安全配置。
总结
面对监控系统的选型问题，需要先明确清楚监控需求：要监控的对象有哪些？机器数量和监控指标有多少？需要具备什么样的告警功能？
- 从系统成熟度上看，Zabbix属于老牌的监控系统，资料多，功能全面且稳定，如果机器数量在几百台以内，不用太担心性能问题。
- Zabbix在服务器监控方面占绝对优势，可以满足90%以上的监控场景，但是应用层的监控似乎并不擅长，比如要监控线程池的状态、某个内部接口的执行时间等，这种通常都要做侵入式埋点。相反，新一代的监控系统Open-Falcon和Prometheus在这一点做得很好。
- Open-Falcon的核心优势在于数据分片功能，能支撑更多的机器和监控项。
- Prometheus则是容器监控方面的标配，有Google和k8s加持。
- 随着机器数据增加和个性化需求增多（比如希望统一监控平台、打通公司的CMDB和组织架构关系），往往需要二次开发或者通过监控系统提供的API做集成，从这点来看，Open-Falcon或者Prometheus更合适
- Zabbix、Open-Falcon和Prometheus都支持和Grafana做快速集成，想要美观且强大的可视化体验，可以和Grafana进行组合。
Zabbix简介
Zabbix是一个监控软件，其可以监控各种网络参数，支持灵活的告警机制，可以使得运维人员快速定位故障、解决问题。
Zabbix支持分布式功能，支持主动和被动两种数据收集模式，支持复杂架构下的监控解决方案，也支持web页面，为主机监控提供了良好直观的展现。
Zabbix的监控对象
zabbix支持监控各种系统平台，包括Linux和Windows等主流操作系统，也可以借助SNMP或者是SSH协议监控路由交换设备。zabbix如果部署在服务器上，可以监控其CPU、内存、网络性能等硬件参数，也可以监控具体的服务或者应用程序、服务运行情况及性能。
硬件监控
Zabbix IPMI Interface ，通过IPMI接口进行监控，我们可以通过标准的IPMI硬件接口，监控被监控对象的物理特征，比如电压、温度、风扇状态、电源状态等。
系统监控
Zabbix Agent Interface ，通过专用的代理程序进行监控，与常见的master/agent模型类似，如果被监控对象支持对应的agent，推荐首选这种方式。
Java监控
Zabbix JMX Interface ，通过JMX进行监控，JMX（java management extensions，即java管理扩展），监控JVM虚拟机时，使用这种方法是非常不错的选择。
网络设备监控
Zabbix SNMP Interface ，通过SNMP协议与被监控对象进行通信，SNMP协议的全称为simple network management protocol，被译为简单网络管理协议，通常来说，我们无法在路由器、交换机这种硬件上安装agent，但是这些硬件都支持SNMP协议。
应用服务监控
Zabbix Agent UserParameter
MySQL数据库监控
percona-monitoring-plulgins
URL监控
Zabbix Web 监控
Zabbix的构成
zabbix主要由以下5个组件构成：
Server
zabbix server是zabbix的核心组件，server内部存储了所有的配置信息、统计信息和操作信息。zabbix agent会向zabbix server报告可用性、完整性及其他统计信息。
web页面
web页面也是zabbix的一部分，通常和zabbix server位于一台物理设备上，但是在特殊情况下也可以分开配置。web页面主要提供了直观的监控信息，以方便运维人员监控管理。
数据库
zabbix数据库内存储了配置信息、统计信息等zabbix的相关内容。
proxy
zabbix proxy可以根据具体生产环境进行采用或者放弃。如果使用了zabbix proxy，则其会替代zabbix server采集数据信息，可以很好的分担zabbix server的负载。zabbix proxy通常运用与架构过大、zabbix server负载过重，或者是企业设备跨机房、跨网段、zabbix server无法与zabbix agent直接通信的场景。
Agent
zabbix agent通常部署在被监控目标上，用于主动监控本地资源和应用程序，并将监控的数据发送给zabbix server。
Zabbix的框架
在实际的工作环境中，根据网络环境和监控的规模不同，zabbix一共有三种框架，分别是server_client架构、master_node_client架构和server_proxy_client架构。
server_client架构
zabbix最简单的架构，监控设备和被监控设备之间直接相连，zabbix_server 和 zabbix_client 之间直接进行数据交互。
zabbix_proxy_client架构
proxy是连接 server 和 client 之间的桥梁，其本身不存放数据，只是将zabbix_agent端发来的数据暂存，然后再提交给server。这种架构一般用于跨机房、跨网络的中型网络架构。
在server_proxy_client架构中，server设备的宕机会导致整个系统瘫痪而无法正常工作。
master_node_client架构
master_node_client架构是zabbix最复杂的架构。一般用于跨机房、跨网络、监控设备较多的大型网络架构。与server_proxy_client架构相比，master_node_client架构的主要区别在于node与proxy上.
在master_node_client架构中，每个node可以理解为一个小的server端，在自己的配置文件和数据库，node下游可以直接连接client，也可以再次经过proxy代理后连接client。
在master_node_client架构中，master设备宕机不会影响node节点的正常工作。
Zabbix的进程
Zabbix在进行监控时，zabbix客户端要安装在被监控设备上，负责定期收集数据，并将其发送给zabbix服务端；Zabbix服务端要安装在监控设备上，其将zabbix客户端发送的数据存储的数据库中，zabbix web根据数据在前端进行展示和绘图。
在默认的情况下，zabbix有6个工作进程；分别是 zabbix_agentd，zabbix_get，zabbix_proxy，zabbix_sender，zabbix_server 和 zabbix_gateway。
其中，zabbix_java_gateway是可选进程。这6个进程的作用如下：
zabbix_agentd
zabbix-agentd为zabbix客户端守护进程 ，主要负责收集客户端监控项数据。
zabbix_server
zabbix_server为zabbix服务端守护进程，主要负责收集zabbix客户端数据。（端口为10051）
zabbix_proxy
zabbix_proxy是zabbix的代理程序，其功能类似于server，作用上类似于一个中转站，最终会把收集的数据再次提交给zabbix_server。
zabbix_get
zabbix_get作为zabbix工具，通常运行在zabbix_server或者zabbix_proxy上，用于远程获取客户端信息，通常用于排错。
zabbix_sender
zabbix_sender也是zabbix的一个工具，通常运行在zabbix的客户端，用于耗时比较长的检查，其作用是主动发送数据。
zabbix_java_gateway
zabbix_java_gateway是zabbix2.0以后引入的新功能，可以用于JAVA方面的设备；但是只能主动获取数据，而不能被动获取数据。
Zabbix常用术语
zabbix的学习需要掌握一些zabbix的常用术语，zabbix常用术语列举如下：
主机（host）：要监控的设备，可以由IP或者是主机名（必须可解析）指定。
主机组（host group）：主机的逻辑容器，包含主机和模板，主机组通常在给用户或者是用户组指派监控权限时使用。
监控项（item）：一个特定监控指标的相关数据，比如内存的大小、CPU的使用率，甚至是服务的运行状态等等。监控项数据来源于被监控对象，并且每个监控项都由一个key来标识。
触发器（trigger）：一个表达式，用于评估监控项的值是否在合理的范围内。当接收的值超出触发器的规定时，就被认为是故障，如果超出后再次符合，就被认为是正常。
事件（event）：触发器触发的一个特定事件，或者是zabbix定义的一个自动上线注册主机的事件。
动作（action）：指根据配置，zabbix对于触发器触发的特定事件进行处理的具体措施，如执行某个脚本，或者是向管理员邮箱发送邮件等等。
报警升级（escalation）：发送警报或者是执行远程命令的自定义方案。
媒介（media）：发送通知（告警）的手段，如微信、邮件、钉钉等等。
通知（notification）：通过指定的媒介，向用户发送的有关事件的信息。
远程命令（remote command）：指运维人员提前写好的命令，可以让被监控主机在触发事件后执行。
模板（template）：用于快速定义被监控主机的预设条目集合，通常包括了监控项、触发器、应用等，模板可以直接链接至某个主机。
应用（application）：一组监控项的集合。
web场景（web scennario）：用于检测web站点可用性的一个或多个HTTP请求。
前端（frontend）：zabbix的web接口。
这些术语，后文中直接使用而不过多赘述，在企业技术交流中也会经常使用。