问题描述
正在构建一个基于 Zabbix 的应用程序监控系统，但他在定义需要监控的内容方面遇到了困难。他目前已经提出了以下几个常规的监控类别：
– 硬件数据：CPU、内存、交换空间等。
– 中间件数据：MySQL 实例、Tomcat 实例、JVM 等的性能/健康状态。
– 逻辑或应用程序数据：系统的当前状态/健康状况，例如活跃用户数量、页面请求等。
– KPI 数据：用于业务的数据，例如用户注册情况。
– 仪表板：对系统的快速概览（例如微服务是否正在运行）。
用户想知道是否还有其他基本的监控类别，或者是否有其他的监控类别系统可供使用。
解决方案
监控系统的目标是确保系统功能正常、预测可能的问题并在需要时通知适当的人员。对于监控，我们通常关注以下几个关键方面：
四个黄金信号
Google SRE 的经验之谈提到了 “四个黄金信号”，建议至少收集以下指标：
1. 延迟（Latency）：请求处理的时间，包括成功请求和失败请求的延迟。要区分成功请求和失败请求的延迟。需要注意，慢速的错误比快速的错误更糟糕，因此应跟踪错误的延迟，并不仅仅是过滤错误。
2. 流量（Traffic）：系统的需求量，通常以每秒的请求量表示。对于 Web 服务，可以考虑 HTTP 请求的数量，也可以根据请求的性质进行细分（静态内容和动态内容等）。
3. 错误（Errors）：失败的请求率，包括显式失败（例如 HTTP 500）和隐式失败（例如 HTTP 200 但内容错误），或按策略定义的失败（例如 “如果承诺一秒的响应时间，超过一秒的请求视为错误”）。要监控所有失败模式，可能需要使用内部协议来跟踪部分失败模式。
4. 饱和度（Saturation）：系统资源使用情况，特别是受限资源的使用情况。在复杂系统中，可以使用更高级的负载测量来补充。要考虑资源的饱和度目标。饱和度的增加通常是饱和的一个前兆，通过测量某个小窗口（例如一分钟）内的第99百分位响应时间，可以很早地发现饱和的迹象。
确保监控这四个黄金信号，以及在信号异常时向相关人员发送警告，将能够基本满足监控的需求。
基本资源监控
除了四个黄金信号，还应关注以下基本资源的监控：
– CPU：总体 CPU 使用率以及每核的使用率。
– 存储：剩余空间、剩余 inode、吞吐量、备份等。
– 内存：可用内存、交换空间、缓冲区、缓存等。
– 网络：延迟、吞吐量、抖动等。
这些基本资源是系统各个层次的动力来源，你需要在每个层次监控这些资源。具体的监控指标可以根据你的环境和架构进行调整，但确保覆盖这些基本资源是首要目标。
服务层级监控
根据你的系统架构，将监控扩展到服务层级。这可能涉及到多层次的监控，包括但不限于：
– 整体服务可用性：至少一个实例健康并能够立即响应请求的时间百分比。
– 终端用户可用性：用户感知产品可用性的时间百分比。某些核心服务的中断可能会影响用户体验，但一些不太常用的服务可能不会影响用户。
– 服务响应时间的百分之95分位数。
– 消息队列：队列长度、队列净增长、每个队列的消费者数量。
– 完成每个队列的平均时间（不仅是在队列中的时间，而是从排队到完成的时间）。
– 每个服务的错误率。
– 每个服务的工作单元成本。
这些监控指标将更加全面地覆盖你的服务层级，帮助你检测和解决可能的问题。
其他关注点
你还可以关注其他的监控点，例如部署的交付时间，以及一些可能导致问题的指标。对于一些业务相关的数据（如用户注册数量），建议考虑将其作为业务报告的一部分，而不是直接作为监控项。
总之，监控是一个根据实际需求和架构进行调整的过程，确保涵盖基本资源，关注四个黄金信号，并根据业务需求和服务层级添加其他的监控点。通过综合利用这些监控指标，你将能够及时发现问题、预测问题，并保持系统的稳定性和性能。
参考资源
如果你对微服务架构感兴趣，还可以观看以下视频，了解关于微