监控的对象和指标都有哪些

640.png

①硬件监控

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

②服务器基础监控

包括：

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

③数据库监控

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

④中间件监控

包括：

  • Nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX 错误率。
  • Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC 次数和耗时。
  • 缓存：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率。
  • 消息队列：连接数、队列数、生产速率、消费速率、消息堆积量。

⑤应用监控

包括：

  • HTTP 接口：URL 存活、请求量、耗时、异常量。
  • RPC 接口：请求量、耗时、超时量、拒绝量。
  • JVM：GC 次数、GC 耗时、各个内存区域的大小、当前线程数、死锁线程数。
  • 线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数。
  • 连接池：总连接数、活跃连接数。
  • 日志监控：访问日志、错误日志。
  • 业务指标：视业务来定，比如 PV、订单量等。

监控系统的基本流程

监控选型 - 图2

主流监控系统介绍

Zabbix、Prometheus

Zabbix

架构设计

监控选型 - 图3

Zabbix 架构图如上：

  • Zabbix Server：核心组件，C 语言编写，负责接收 Agent、Proxy 发送的监控数据，也支持 JMX、SNMP 等多种协议直接采集数据。同时，它还负责数据的汇总存储以及告警触发等。
  • Zabbix Proxy：可选组件，对于被监控机器较多的情况下，可使用 Proxy 进行分布式监控，它能代理 Server 收集部分监控数据，以减轻 Server 的压力。
  • Zabbix Agentd：部署在被监控主机上，用于采集本机的数据并发送给 Proxy 或者 Server，它的插件机制支持用户自定义数据采集脚本。
    Agent 可在 Server 端手动配置，也可以通过自动发现机制被识别。数据收集方式同时支持主动 Push 和被动 Pull 两种模式。
  • Database：用于存储配置信息以及采集到的数据，支持 MySQL、Oracle 等关系型数据库。同时，最新版本的 Zabbix 已经开始支持时序数据库，不过成熟度还不高。
  • Web Server：Zabbix 的 GUI 组件，PHP 编写，提供监控数据的展现和告警配置。

Zabbix 的优势：

  • 产品成熟：由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景。
  • 采集方式丰富：支持 Agent、SNMP、JMX、SSH 等多种采集方式，以及主动和被动的数据传输方式。
  • 较强的扩展性：支持 Proxy 分布式监控，有 Agent 自动发现功能，插件式架构支持用户自定义数据采集脚本。
  • 配置管理方便：能通过 Web 界面进行监控和告警配置，操作方便，上手简单。

Zabbix 的劣势：

  • 性能瓶颈：机器量或者业务量大了后，关系型数据库的写入一定是瓶颈，官方给出的单机上限是 5000 台，个人感觉达不到，尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库，不过成熟度还不高。
  • 应用层监控支持有限：如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能），Zabbix 没有提供对应的 SDK，通过插件式的脚本也能曲线实现此功能，个人感觉 Zabbix 就不是做这个事的。
  • 数据模型不强大：不支持 Tag，因此没法按多维度进行聚合统计和告警配置，使用起来不灵活。
  • 方便二次开发难度大：Zabbix 采用的是 C 语言，二次开发往往需要熟悉它的数据表结构，基于它提供的 API 更多只能做展示层的定制。

Prometheus （号称下一代监控系统）

架构设计

监控选型 - 图4

Prometheus 架构图如上：

  • Prometheus Server：核心组件，用于收集、存储监控数据。它同时支持静态配置和通过 Service Discovery 动态发现来管理监控目标，并从监控目标中获取数据。
    此外，Prometheus Server 也是一个时序数据库，它将监控数据保存在本地磁盘中，并对外提供自定义的 PromQL 语言实现对数据的查询和分析。
  • Exporter：用来采集数据，作用类似于 Agent，区别在于 Prometheus 是基于 Pull 方式拉取采集数据的。
    因此，Exporter 通过 HTTP 服务的形式将监控数据按照标准格式暴露给 Prometheus Server，社区中已经有大量现成的 Exporter 可以直接使用，用户也可以使用各种语言的 client library 自定义实现。
  • Push gateway：主要用于瞬时任务的场景，防止 Prometheus Server 来 Pull 数据之前此类 Short-lived jobs 就已经执行完毕了，因此 Job 可以采用 Push 的方式将监控数据主动汇报给 Push gateway 缓存起来进行中转。
  • Alert Manager：当告警产生时，Prometheus Server 将告警信息推送给 Alert Manager，由它发送告警信息给接收方。
  • Web UI：Prometheus 内置了一个简单的 Web 控制台，可以查询配置信息和指标等，而实际应用中我们通常会将 Prometheus 作为 Grafana 的数据源，创建仪表盘以及查看指标。

Prometheus 的优势：

  • 轻量管理：架构简单，不依赖外部存储，单个服务器节点可直接工作，二进制文件启动即可，属于轻量级的 Server，便于迁移和维护。
  • 较强的处理能力：监控数据直接存储在 Prometheus Server 本地的时序数据库中，单个实例可以处理数百万的 Metrics。
  • 灵活的数据模型：同 Open-Falcon，引入了 Tag，属于多维数据模型，聚合统计更方便。
  • 强大的查询语句：PromQL 允许在同一个查询语句中，对多个 Metrics 进行加法、连接和取分位值等操作。
  • 很好地支持云环境：能自动发现容器，同时 K8s 和 Etcd 等项目都提供了对 Prometheus 的原生支持，是目前容器监控最流行的方案。
  • 告警方式：邮件+企业微信

Prometheus 的劣势：

  • 功能不够完善：Prometheus 从一开始的架构设计就是要做到简单，不提供长期的持久化存储和用户管理，而这些是企业变大后所必须的特性，目前要做到这些只能在 Prometheus 之上进行扩展。
  • 网络规划变复杂：由于 Prometheus 采用的是 Pull 模型拉取数据，意味着所有被监控的 Endpoint 必须是可达的，需要合理规划网络的安全配置。

总结

  • prometheus 优点
    1. 一款新型的监控开源软件，越来越成熟
    2. 对接容器、微服务和与k8s原生云应用比zabbix有优势
    3. 基于目前我们需求，对硬件cpu/内存/网络等监控可以满足
    4. 使用时序数据库性能优秀
    5. zabbix更合适物理机，prometheus 更合适云应用
    6. 社区潮流，新系统一般都用prometheus
  • prometheus 缺点
    1. 社区成熟度、文档不如zabbix，硬件服务器监控方面不如老牌zabbix强大
    2. 配置稍微复杂，入手难度高，但后期使用成本低
  • zabbix优点：
    1. 老牌监控工具，社区活跃度高，基本问题都能解决
    2. 功能强大，服务器监控方面绝对优势，可以针对某个指标正则表达式操作
    3. 配置可以直接图形化界面操作。
    4. 监控选型 - 图5
  • zabbix缺点：
    1. 使用MySQL等关系型数据库，性能稍微差
    2. 不支持k8s等容器应用
    3. 性能有上限
    4. 扩展性不如prometheus