bob电竞频道Grafana Labs在GKE中有8个以上的集群，运行270个不同大小的节点，以及所有托管的指标和托管的日志Grafana云这些产品运行在16核、64兆字节的机器上。在最近的所有系统启动!会议在柏林，用户体验总监David Kaltschmidt就Grafana实验室如何监控这些集群和服务器进行了演讲，并分享了一些最佳实践。bob电竞频道
这个基础设施监控包括普罗米修斯为指标,洛基对于日志，和Jaeger对于分布式跟踪，以及监控混合．
报警
在Grbob电竞频道afana实验室，“我们制作仪表板软件，但我们不想整天盯着仪表板看，”Kaltschmidt说。“所以我们试图通过警报来进行监控，使用我们生成的时间序列，并编写警报，只在事情发生时才通知我们。”
这要求团队确保任何接收到页面的人都有有意义的仪表盘和良好的程序。这是通过普罗米修斯使用节点出口国，这是一个运行在主机上的服务，用于收集由*NIX内核公开的硬件和操作系统指标。它是用Go编写的，带有可插拔的度量收集器。
由于有这么多的收集器模块，Kaltschmidt说他寻求了GitLab的建议本Kochie他给他看了这张图:
卡尔茨施密特说:“本在日常工作中一直在使用这些工具，但对他来说，更大的任务始终是我们如何以某种时间序列的形式获得这些工具提供的信息。”“幸运的是，它与节点导出器提供的功能有一些重叠，对我们来说这成为了一个挑战:我们如何将节点导出器指标映射到Linux系统中我们需要覆盖的部分?”
结果图形将节点导出器导出的度量映射到Linux系统的各个部分。(图形上的术语是模块名称;度量标准命名为node_，后跟模块名。)
指标使用
CPU利用率
这是用于监视基础设施的度量的一个经典示例。Kaltschmidt说:“时间序列node_cpu_seconds_total提供了在CPU支持的各种模式下，在壁钟时间中花费CPU的秒数。”“所以你有系统、用户、空闲、客户等各种不同的模式。在这里，我们利用这个指标来绘制利用率图，其中100%在空闲模式下没有任何运行，而在非空闲模式下，100%的CPU被进程使用。”
CPU饱和
用于饱和度的类似指标是平均负载，但它“并不理想，因为它不仅受CPU限制，因为它现在还跟踪许多不间断的任务代码路径，这不一定能反映CPU的资源限制程度，”Kaltschmidt说。此外，“我们必须总是通过CPU核数来标准化它，以达到0到100%的饱和范围。”
因此，该团队希望使用node_pressure(压力失态指示器)，这是从CPU角度监控系统需求的新方法。“我们不再只是跟踪等待处理器的线程数量，”他说，“而是实际上跟踪等待时间，因此我们将更好地了解资源的竞争情况。”注意:此指标仅适用于较新的内核。
内存指标
内存利用率是通过从1减去空闲的部分来衡量的，从而得到已使用的空间。对于饱和度，Grafana Labob电竞频道bs使用了另一个代理指标:每秒交换的页面数。
磁盘利用率
磁盘利用率通过每秒IO时间跟踪。Kaltschmidt说:“我们有很多指标可以映射到iostat提供给你的东西。“这两者有很大的重叠，而且有很好的文章作者:Brian Brazil了解iostat提供的哪些不同字段可以用度量来表示。”
为了解决对磁盘被填满的恐惧，“你可以使用普罗米修斯查询设置警报，当你的磁盘处于将被填满的轨道时触发警报，”Kaltschmidt说。例如，当可用磁盘空间小于40%时，如果可用磁盘空间在未来24小时内趋向于零，则下面幻灯片中的警报将触发，这是基于过去6小时内磁盘空间的填充情况。缺点是条件必须在一小时内为真;为了解决磁盘可能在不到一小时内就被填满的情况，您需要将此规则与跟踪更快速的磁盘填充速度的其他警报规则结合起来，并将这些警报路由到分页服务。
类中定义了许多此类警报节点混合，这是一个基于jsonnet的警报、记录规则和仪表板库。“即使您在组织中不使用Jsonnet，我认为查看这里的警报规则仍然是有益的，”Kaltschmidt说。“你可以把它们复制出来，如果你认为它们可以改进，你也可以在相同的回购上打开一个GitHub问题，然后其他人就可以从你的建议中受益。”
网络指标
bob电竞频道Grafana Labs使用一些网络度量查询，可以使用负y轴绘制图形，以便方便地比较传入和传出流量。
最近，在GKE上运行的Grafanabob电竞频道 Labs的一些节点达到了连接轨道限制，无法建立任何新的连接。当时还没有针对这种情况编写警报，但Kaltschmidt演示了如何在《Grafana Explore》中快速编写conntrack警报。
(node_nf_conntrack_entries / node_nf_conntrack_entries_limit) > 0.5 > 1.5 * scalar(avg(node_nf_conntrack_entries / node_nf_conntrack_entries_limit)) > (scalar(avg(node_nf_conntrack_entries / node_nf_conntrack_entries_limit)) + 2 * scalar(stddev(node_nf_conntrack_entries / node_nf_conntrack_entries_limit)))专业技巧
Kaltschmidt提醒观众，在运行节点导出程序时，了解生成了多少个时间序列是很重要的。他说:“这取决于你自己，你想让哪些收集器不具有太多的时间序列。”“一些遗留收集器也会运行脚本或执行程序，这在时间序列量方面给系统增加了额外的负担。”
为了减少存储的时间序列的数量，他补充说，“你可以编写重新标记规则来删除其中的几个，但这可能有点太乏味了。”
一个专业的建议理查德·哈特曼是在每台机器上运行两个节点导出器，一个具有最小集，另一个具有完整的模块集。Kaltschmidt解释说:“定期采集的东西只是用最小集联系节点导出过程。”“如果他们需要进一步调查或查看一些东西，否则你必须登录到机器并查看prod文件系统，然后你可以只去第二个节点导出器，它具有完整的模块集，并查看那里暴露的指标。有人告诉我，那里可以省下很多钱。”
Bjorn RabensteinGrafana实验室bob电竞频道的另一位团队成员，他建议使用文本文件收集器．Kaltschmidt说:“这将从给定目录中的文件中添加小文本片段到被Prometheus抓取的导出度量文本中。”“例如，如果你有维护工作，比如运行备份或推出系统的新更新，你可以通过写这一小行来跟踪这些工作，其中包含关于上一轮是什么时候的信息，然后你可以创建一个警报，检查这个时间戳，并将其与现在的时间进行比较。如果你的备份在三天内还没有运行，你可能应该提醒一下。”
另一个用例是，如果您在裸机上运行大量应用程序软件，并且在您的整个车队中，您在某些机器上启用了某些功能，但在其他机器上不启用。Kaltschmidt说:“对你的车队中有多少部分启用了某种功能有一个总体的概述是很好的。”“像my_feature_enabled这样的指标设置为0或1可以帮助您跟踪这一点。”
Kaltschmidt还建议学习GitLab的基础设施监控仪表板该公司拥有公开．
如何整理一切
GitLab提供了一个很好的例子，说明了如何获得良好的总体舰队概述。他说:“他们在总体舰队概览方面做得非常好，例如在每行上有CPU利用率，在第二行上有平均负载，但他们按照应用程序层将这些数据分组。”左边是web worker，然后是API，然后是git worker。这就是你脑海中GitLab的工作方式。在这里你可以很容易地看到这些系统现在有多忙。例如，我认为这对容量规划非常有帮助。”
bob电竞频道Grafana实验室监控车队的内部解决方案是使用节点导出器混合，“因为这样我们就能以代码的形式直接看到仪表板，而且集群仪表板是集群中每个节点的聚合，”Kaltschmidt说。“然后我们有一个模板查询驱动的节点仪表板，它基本上只运行一个节点导出器构建查询，然后返回所有实例名。这就是我们发现服务或节点的方式。”
你是否使用了一些有趣的提醒规则?和我们一起分享吧!
