监控系统-知识梳理（基本是转帖）

写在最前面

这篇的内容是从公众号ImportNew上看到的，原网址：https://mp.weixin.qq.com/s/WtDkVpmPmlp54y5glkeLlw
我又整理一遍放在这里是为了让自己看完有个记性。欢迎讨论，推荐关注原网址的作者大佬。
思维导图工具：xmind
----正文分割线-----
使用方法：找到导图里的相应内容，作为指导思想或者checklist，检查和构建自己项目的监控系统。
先放个全文结构

监控系统-知识梳理

首先要明确

• 监控系统的目标是什么？

• 监控能发挥什么作用？

监控系统的作用

实时采集监控数据

• 维度

  • 硬件
  • 操作系统
  • 中间件
  • 应用程序

实时反馈监控状态

• 通过对采集的数据进行多维度统计和可视化展示，能实时体现监控对象的状态是正常还是异常

预知故障和告警

• 能够提前预知故障风险，并及时发出告警信息

辅助定位故障

• 提供故障发生时的各项指标数据，辅助故障分析和定位

辅助性能调优

• 为性能调优提供数据支持，比如慢SQL，接口响应时间等

辅助容量规划

• 为服务器、中间件以及应用集群的容量规划提供数据支撑

辅助自动化运维

• 为自动扩容或者根据配置的SLA进行服务降级等只能运维提供数据支撑。

使用监控系统的正确姿势

一个好的监控要有这些特点

• 有监控
• 监控及时
• 监控的信息有助于快速定位问题

如何使用监控

1 了解监控对象的工作原理

要做到对监控对象有基本的了解，清楚它的工作原理。比如想对JVM监控，必须清楚JVM的堆内存结构和垃圾回收机制

2 确定监控对象的指标

清楚使用哪些指标来刻画监控对象的状态。比如对某个接口监控，可以采用请求量、耗时、超时量、异常量等指标来衡量。

3 定义合理的报警阈值和等级

达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，定义不合理的阈值会降低运维效率或者使监控系统失效。

4 建立完善的故障处理流程

收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。

常用监控对象和指标

硬件监控

• 电源状态
• cpu状态
• 机器温度
• 风扇状态
• 物理硬盘
• raid状态
• 内存状态
• 网卡状态

服务器基础监控

• cpu：单个cpu以及整体cpu使用情况
• 内存：已用内存、可用内存
• 磁盘：磁盘使用率、磁盘读写的吞吐量
• 网络：出口流量、入口流量、TCP连接状态

数据库监控

• 数据库连接数
• QPS/TPS
• 并行处理的绘画数
• 缓存命中率
• 主从延时
• 锁状态
• 慢查询

中间件监控

• Nginx

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

• Tomcat

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

• 缓存

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

• 消息队列

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

应用监控

• HTTP接口

  • url存活
  • 请求量
  • 耗时
  • 异常量

• RPC接口

  • 请求量
  • 耗时
  • 超时量
  • 拒绝量

• JVM

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

• 线程池

  • 活跃线程数

  • 任务队列大小

  • 任务执行耗时

  • 拒绝任务数

    拒绝任务数是什么概念？

• 连接池

  • 总连接数
  • 活跃连接数

• 日志监控

  • 访问日志
  • 错误日志

• 业务指标

  • 视业务来定，如PV，订单量等

基本流程

1 数据采集

• 日志埋点采集，使用插件进行上报和解析

  • logstash
  • filebeat

• JMX标准接口输出监控指标

• 被监控对象提供的REST API去进行数据采集，如hadoop、ES

• 系统命令行

• 统一的SDK进行侵入式埋点和上报

2 数据传输

• 将采集的数据以TCP、UDP或者http协议的形式上报监控系统

  • 主动push
  • 被动pull

3 数据存储

• RDBMS：MYSQL，Oracle
• 时序数据库：RRDTool、OpentTSDB、InfluxDB
• hbase

4 数据展示

• 数据指标的图形化展示

5 监控告警

• 灵活的告警设置，支持邮件短信im等多通知渠道

主流监控系统

老牌监控系统

• Zabbix

  • Zabbix架构图
    

    • Zabbix Server

      • 核心组件，C，

      • 功能

        • 负责接受Agent、Proxy发送的监控数据，支持JMX、SNMP等多种协议直接采集数据
        • 数据的汇总存储
        • 告警触发

    • Zabbix Proxy

      • 可选组件

      • 功能

        • 对于被监控机器较多的情况，可以被用来分布式监控，能代理Server收集部分监控数据，减轻Server的压力

    • Zabbix Agentd

      • 部署在被监控主机上

      • 功能

        • 用于采集本季的数据，并发送给Proxy或Server，支持用户自定义数据采集脚本。
        • 可以手动配置在Server端，也可以在自动发现机制中被识别。
        • 收集数据方式支持主动Push和被动Pull

    • Database

      • 用于存储配置信息和采集到的数据。
      • 支持Mysql、Oracle等关系行数据库，最新版开始支持时序数据库（成熟度不高）。

    • Web Server

      • Zabbix的GUI组建，PHP

      • 功能

        • 提供监控数据的战羡和报警配置

  • 优势

    • 产品成熟：文档丰富、采集插件丰富，功能强大
    • 采集方式丰富：支持Agent、SNMP、JMX、SSH等多种采集方式。主动被动数据传输方式。
    • 较强的拓展性：支持Proxy分布式监控，有agent自动发现功能，插件式架构支持用户自定义数据采集脚本。
    • 配置管理方便：web页面即可配置

  • 劣势

    • 性能瓶颈：关系型数据库写入是瓶颈，给出的单击上线是5000，还可能达不到。而时序数据库成熟度还不高
    • 应用层监控支持有限：没有对应sdk做侵入式买点和采集（比如监控线程池或者接口性能，但是可以通过插件曲线实现）
    • 数据模型不强大：不支持tag，没法按多维度进行聚合统计和告警配置，不灵活。
    • 二次开发难度大：Zabbix使用C，二次开发要熟悉它的数据表结构，而用它提供的API更多做的事展示层的定制。

• Nagios

• Cacti

• Ganglia

• Garafana

新一代监控系统

• Open-Falcon

  • Open-Falcon架构图
    

    • Falcon-agent

      • Go开发，部署在被监控的机器上

      • 功能

        • 负责数据采集，支持三种数据采集方式
        • 能自动采集单机200多个基础监控指标，无需做任何配置；
        • 支持用户自定义plugin获取监控数据
        • 用户可通过http接口自主push数据到本季的proxy-gatewat，再由gateway转发到server

    • Transfer

      • 功能

        • 数据分发组件，接收客户端发送的数据，分别发送给数据存储组件Graph和告警盘点组件Judge。 这两者均采用一致性hash做数据分片，以提高横向扩展能力。
        • 将数据分发到OpenTSDB，做历史归档

    • Graph

      • 数据存储组件
      • 底层使用RRDTool（时序数据库）做单个指标的存储，并通过缓存、分批写入磁盘等方式进行了优化。据说可以达到8w+/s的写入速率

    • Judge & Alarm

      • 告警组件
      • 对上报的数据实时计算，判断是否产生告警事件。Alarm组件对告警事件收敛处理后，将消息推送给各个消息通道。

    • API

      • 面向终端用户，收到查询请求后回去Graph中查询指标数据。汇总结果后同一返回给用户，屏蔽了存储集群的分批细节。

  • 优势

    • 自动采集能力
    • 强大的存储能力：分布式时序数据存储系统，可扩展性强
    • 灵活的数据模型：借鉴OpenTSDB，数据模型中引入tag，支持多维度的聚合统计和告警规则设置，提高了使用效率。
    • 插件统一管理：可以对用户自定义脚本做统一化管理，可通过HeartBeat Server 分发给agent，减轻使用者自主维护脚本的成本。
    • 个性化监控支持：基于Proxy-gateway，很容易通过自主买点实现应用曾的监控和其他个性化监控需求。集成方便。

  • 劣势

    • 整体发展一般：社区活跃度不高，前景堪忧
    • ui不够友好：对于业务线的研发来说，可能只想便捷的完成告警配置和监控，但是它把机器分组，策略模板，模板继承等概念都暴露在ui上，围绕这几个概念设计ui，理解有点费劲。
    • 安装复杂：组件多，安装比较难

• Prometheus

  • 概述：Go语言开发，支持k8s，开源，社区异常火爆，数据基于pull模式，而不是push模式。架构简单

  • prometheus架构图
    

    • Prometheus Server

      • 核心组件，用于收集、存储监控数据

      • 功能

        • 支持静态配置和通过Service Discovery动态发现来管理监控目标。并从监控目标中获取数据。
        • 同事是一个时许数据库，将监控数据保存在本地磁盘中，并对外提供自定义的PromQL语言实现对数据的查询和分析

    • Exporter

      • 用来采集数据，作用类似agent
      • 基于pull方式拉取数据。通过http服务将监控数据按照标准格式暴露给Prometheus Server，社区中由大量现成的，用户可以使用各种语言的client library自定义实现

    • Push gateway

      • 用于瞬时任务的场景，防止Prometheus Server来pull数据之前，这类短期任务就已经执行完毕了。因此这种任务可以采用push的方法主动汇报信息给push gateway缓存起来做中转。

    • Alert Manager

      • 发送报警

    • web控制台

      • 用来查询配置信息和指标等。一般这个系统配合grafana，作为数据源来使用。

  • 优势

    • 轻量管理：架构简单，不依赖外部存储，单个服务器节点可直接工作。便于迁移和维护。

    • 较强的处理能力：监控数据直接存储在Prometheus Server本地的时序数据库，单个实例可以处理数百万metrics

      metrics是什么？然后时序数据库是什么？

    • 灵活的数据类型，引入tag。属于多维度数据模型，聚合统计更方便。

    • 强大的查询语句：PromQL允许在同一个查询语句中，对多个mertics进行加法，连接和取分位值等操作。

    • 很好地支持云环境：自动服务发现。并且k8s和etcd等项目提供原生支持。

  • 劣势

    • 功能不够完善：不提供集群化方案，长期的持久化存储和用户管理。
    • 网络规划变复杂：要求所有被监控的endpoint必须可达，需要合理规划网络的安全配置。

选型建议

1 明确监控需求

• 要监控的对象有哪些？
• 机器数量和监控指标有哪些？
• 需要具备什么样的报警功能？

2 初期可以跨素介入开源监控方案，后续建设

3 系统成熟度上看，Zabbix属于老牌监控系统，资料多，功能全且稳定，机器数量在几百台以内，不用太担心性能问题。采用数据库分区，ssd硬盘，proxy架构，push采集模式都可以提高监控性能。

4 Zabbix在服务器监控方面有绝对优势，但是应用层监控并不擅长。比如线程池，内部接口的监控都要做侵入式埋点。相反，新一代的监控系统这里都做得很好。

5 如果没有Zabbix这种监控的技术积累，建议使用Open-Falcon或者Prometheus

6 Open-Falcon的核心优势在于数据分片功能，能支撑更多的机器和监控项。Prometheus则在容器监控方面有优势。

7 三者都支持和Grafana的快速集成

8 用合适的监控系统解决相应的问题即可，可以多套并存。

9 在企业中后期，随着机器数据增加和个性化需求增多，往往要二次开发或集成监控系统，这么看，新一代的两个更好。

10 如果非要自研，可以多研究下主流监控系统的架构方案，借鉴优势。