监控清单-我应该监控什么？

#1 楼

我喜欢这个视频：GOTO 2016•监控微服务•Tom Wilkie应用程序监视。基本上，主机监视会告诉您现在有致命的错误，但是应用程序监视应该能够通过检测更高的错误率来预测问题，或者请求所花费的时间更长，因此您可以在用户注意到它们之前解决问题。

（我不隶属于weaveworks或goto会议，我只是喜欢其中的内容，并认为有一些有趣的想法。请使用downvote按钮让我知道此答案不好:)）） />

#2 楼

我很惊讶没有人明确提到四个黄金信号作为答案，因此我将其添加。建议直接从Google关于监视分布式系统的SRE图书一章中删除，建议至少收集有关“四个黄金信号”的度量标准：
服务请求所花费的时间。区分成功请求的延迟和失败请求的延迟非常重要。例如，由于与数据库或其他关键后端的连接断开而触发的HTTP 500错误可能很快得到解决。但是，由于HTTP 500错误表示请求失败，因此将500s计入您的整体延迟可能会导致误导计算。另一方面，慢速错误甚至比快速错误更糟糕！因此，重要的是跟踪错误延迟，而不是仅过滤掉错误。

流量：
从高层次上衡量系统上有多少需求系统特定指标。对于网络服务，此衡量标准通常是每秒HTTP请求数，可能会因请求的性质（例如，静态内容与动态内容）而中断。对于音频流系统，此度量可能集中在网络I / O速率或并发会话上。对于键值存储系统，此度量可能是每秒的事务和取回。

错误：
显式（例如，HTTP 500），隐式（例如，HTTP 200成功响应，但错误的内容）失败的请求率，或者根据策略（例如“如果您承诺一秒钟响应时间，一秒钟内的任何请求都是错误”）。如果协议响应代码不足以表示所有故障情况，则可能需要使用辅助（内部）协议来跟踪部分故障模式。监视这些情况可能截然不同：在负载平衡器上捕获HTTP 500可以很好地捕获所有完全失败的请求，而只有端到端系统测试才能检测到您提供了错误的内容。 >
饱和度：
您的服务有多“充实”。衡量系统分数的指标，强调最受约束的资源（例如，在内存受限的系统中显示内存;在I / O受限的系统中显示I / O）。请注意，许多系统在达到100％利用率之前会降低性能，因此，必须达到利用率目标。在复杂的系统中，可以通过更高级别的负载测量来补充饱和度：您的服务能否正确处理两倍的流量，仅处理10％的流量或处理比当前接收的流量少的流量？对于非常简单的服务，这些服务没有会改变请求复杂性的参数（例如，“给我一个随机数”或“我需要一个全局唯一的单调整数”），而很少更改配置，那么来自负载测试的静态值可能已足够。但是，如前一段所述，大多数服务需要使用具有已知上限的间接信号，例如CPU利用率或网络带宽。延迟增加通常是饱和的主要指标。在一些小的窗口（例如一分钟）内测量您的第99个百分位响应时间，可以非常早地发出饱和信号。
最后，饱和度还与即将到来的饱和度有关，例如“看起来您的数据库将在4小时内填满硬盘。”一个信号有问题（或者在饱和的情况下几乎有问题），您的服务至少会受到监视的合理覆盖。

#3 楼

这在很大程度上取决于您的基础架构情况。如果您要进行自动缩放，则各个实例的运行状况几乎无关紧要。重要指标是总成本和每单位工作成本（例如，每个请求）。就我个人而言，如果可以避免的话，我不喜欢监视单个实例的状态-我尝试将重点更多地放在更广泛的服务级别和应用程序级别指标上：


每个服务的总体正常运行时间（至少一个实例运行状况良好并且能够立即响应新请求的时间的百分比）
最终用户总正常运行时间（用户认为产品可用的时间的百分比-如果有一些核心服务发生故障，这可能是面向用户的停机时间，但可能不是使用较少的服务或后台工作人员）
每个服务的响应时间第95个百分点/>每个队列的消费者计数
每个队列的平均完成时间（不仅是队列中的时间，而是消息从排队到完成工作的时间）
每个服务的错误率
每个服务的工作单位
对于每个服务器角色，平均CPU利用率与平均内存利用率之比是多少？这对于确定我们的伸缩性是否有帮助-如果CPU使用率为70％，而内存为20％，则我们为实例分配了过多的内存，反之亦然。
相同的峰值CPU /内存利用率
部署的交付时间

我列出的一些指标，例如随着时间的推移的用户注册，对我而言，不属于Zabbix这样的基础架构监视系统。有人看着Zabbing的注册减少了10％怎么办？没有。这是业务报告数据，应通过报告数据库将其暴露给任何需要的人，这些数据可能呈现在一个漂亮的仪表板中，因为尖顶的上司喜欢仪表板。

#4 楼

对于任何给定节点，都有4个基本资源，需要监视以下项目：


CPU



总
每核


存储


可用空间
可用的inodes
吞吐量
备份



内存


免费
交换
缓冲区


网络


延迟
吞吐量
抖动



这四个基本资源将为您的应用程序或服务的每一层提供支持你的申请。根据您的环境，此架构最多可分为5层，您将希望在每一层对其进行监视。可能如下所示：



这可能会根据环境的架构而改变。例如，如果您从NFS挂载中运行所有数据，则存储层将位于计算旁边而不是后面。如果您有工作站连接到的基于C ++的应用程序，则可能没有前端层。如果您的应用程序使用平面文件，则您可能没有数据库层。如果您不使用虚拟机或容器，而是使用本地存储，则可能没有计算和存储层。您将希望在每一层监视以上4种基本资源。

这表示您的供应商，软件和硬件可以提供的基本监视。在每一层覆盖这四个基本资源应该是您的首要目标。一旦达到100％的覆盖率，您就可以在应用程序中另外构建钩子以报告其他健康状况，但是从本质上来说，这些钩子通常是作为对故障的响应而构建的，因此您必须与内部开发人员一起构建这些类型

监视这4个基本资源应该可以捕获可能导致断电的80％问题，然后可以开始处理剩余的20％。