无监控，不运维

　　监控系统俗称“第三只眼“，正所谓【无监控，不运维】，监控系统的地位不言而喻。没有了监控，不管什么基础运维、业务运维都是“瞎子”。

监控系统的作用：

监控问题：有没有做监控？监控是否及时？监控信息是否有助于快速定位问题？

如何使用监控系统：

了解监控对象的工作原理：要做到对监控对象有基本的了解，清楚它的工作原理。比如想对JVM进行监控，你必须清楚JVM的堆内存结构和垃圾回收机制。
确定监控对象的指标：清楚使用哪些指标来刻画监控对象的状态？比如想对某个接口进行监控，可以采用请求量、耗时、超时量、异常量等指标来衡量。
定义合理的报警阈值和等级：达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用。
建立完善的故障处理流程：收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。

监控对象

　　硬件监控

　　包括：电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态

　　服务器基础监控

　　CPU：单个CPU以及整体的使用情况

　　内存：已用内存、可用内存

　　磁盘：磁盘使用率、磁盘读写的吞吐量

　　网络：出口流量、入口流量、TCP连接状态

　　数据库监控

　　包括：数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询

　　中间件监控

　　Nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率

　　Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时

　　缓存：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率

　　消息队列：连接数、队列数、生产速率、消费速率、消息堆积量

　　应用监控

　　HTTP接口：URL存活、请求量、耗时、异常量

　　RPC接口：请求量、耗时、超时量、拒绝量

　　JVM ：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数

　　线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数

　　连接池：总连接数、活跃连接数

　　日志监控：访问日志、错误日志

　　业务指标：视业务来定，比如PV、订单量等

监控的基本流程：

数据采集：采集的方式有很多种，包括日志埋点进行采集（通过Logstash、Filebeat等进行上报和解析），JMX标准接口输出监控指标，被监控对象提供REST API进行数据采集（如Hadoop、ES），系统命令行，统一的SDK进行侵入式的埋点和上报等。
数据传输：将采集的数据以TCP、UDP或者HTTP协议的形式上报给监控系统，有主动Push模式，也有被动Pull模式。
数据存储：有使用MySQL、Oracle等RDBMS存储的，也有使用时序数据库RRDTool、OpentTSDB、InfluxDB存储的，还有使用HBase存储的。
数据展示：数据指标的图形化展示。
监控告警：灵活的告警设置，以及支持邮件、短信、IM等多种通知通道。

主流监控优劣势

　　Zabbix 的优势：

　　产品成熟：由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景。

　　采集方式丰富：支持Agent、SNMP、JMX、SSH等多种采集方式，以及主动和被动的数据传输方式。

　　较强的扩展性：支持Proxy分布式监控，有agent自动发现功能，插件式架构支持用户自定义数据采集脚本。

　　配置管理方便：能通过Web界面进行监控和告警配置，操作方便，上手简单。

　　Zabbix 的劣势：

　　性能瓶颈：机器量或者业务量大了后，关系型数据库的写入一定是瓶颈，官方给出的单机上限是5000台，个人感觉达不到，尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库，不过成熟度还不高。

　　应用层监控支持有限：如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能），zabbix没有提供对应的sdk，通过插件式的脚本也能曲线实现此功能，个人感觉zabbix就不是做这个事的。

　　数据模型不强大：不支持tag，因此没法按多维度进行聚合统计和告警配置，使用起来不灵活。

　　方便二次开发难度大：Zabbix采用的是C语言，二次开发往往需要熟悉它的数据表结构，基于它提供的API更多只能做展示层的定制。

　　好吧，我目前就只用过zabbix，，，，，，

注：本文主要用於個人學習與知识總結，如有錯誤期待各位大佬的指導！