咱们这个系列是讲解 Kubernetes 监控，Kubernetes 自身也是要跑在机器上的，那机器的监控自然也是整个体系的一环。机器层面的监控分为两部分，带内网络和带外网络，通过带内网络做监控主要是在OS里部署 agent 的方式，获取 OS 的 CPU、内存、磁盘、IO、网络、进程等相关监控指标。带外监控，主要是走带外管理卡，通过 IPMI、SNMP 协议，获取硬件健康状况。

带内监控

带内监控的 agent 有很多，大家可能会面临选型问题，这里我对常见 agent 做一个基本介绍。

Agents

Telegraf

Telegraf 来自 InfluxData，InfluxData 就是做 InfluxDB 那家公司，Telegraf 是 MIT 协议，非常开放，有非常多贡献者，社区繁荣。Telegraf 重点关注的是指标数据采集，不处理日志和链路数据，Telegraf 可以和 InfluxDB 丝滑集成，但是和 Prometheus 的集成就略微没有那么顺畅了。为啥呢？

  1. Telegraf 会采集很多字符串类型的数据，而 Prometheus 生态的时序库，是无法存储字符串类型的数据的。当然，作为 Telegraf 老炮也可以解决，把这类指标 Drop 掉即可。
  2. Telegraf 有些指标的标签是非稳态结构，比如一个 HTTP 目标的探测监控，能连通的时候，指标中会打上一个标签 result=success，连不通的时候，标签就变成了 result=failed，这就很麻烦了，因为这俩数据标签变化，Prometheus 类型的时序库会当做两个时间线(Series)，对告警非常不友好。当然，有一些办法可以解决，比如在 Telegraf 上通过配置 Drop 掉这种标签，或者在 PromQL 这层，通过一些聚合函数实现，但是这个成本就高了，最好是采集器默认就处理了这种情况。

Grafana-Agent

Grafana 做可视化那是鼎鼎有名，近期，Grafana 也做了一个 Agent，目标是 All-in-one，不止处理指标数据，也能收集日志和链路数据。

Grafana-Agent 作为后来者，是如何快速集成各类采集能力的呢？Grafana-Agent 写了个框架，方便导入各类 Exporter，把各个 Exporter 当做 Lib 使用，常见的 Node-Exporter、Kafka-Exporter、Elasticsearch-Exporter、Mysqld-Exporter 等，都已经完成了集成。这样我们就不用到处去找各类 Exporter 了，只使用Grafana-Agent这一个二进制就可以搞定众多采集能力。

Grafana-Agent 这种集成 Exporter 的方式，完全兼容 Exporter 的指标体系，比如 Node-Exporter。如果我们的场景不方便使用PULL的方式来抓取数据，就可以换成Grafana-Agent采用PUSH的方式推送监控数据，完全兼容Node-Exporter的指标。当然，Exporter种类繁多，Grafana-Agent不可能全部集成，对于默认没有集成进去的Exporter，Grafana-Agent也支持PULL的方式去抓取其他Exporter的数据，然后再通过Remote Write的方式，将采集到的数据转发给服务端。

Datadog-Agent

Datadog 市值几百亿美金，做了十几年了，鼎鼎有名的 SaaS 公司，主要服务欧美市场，Datadog 也开源了自己的 Agent，不过 Datadog 的 Agent 采集了数据之后，是通过一个私有协议传输给服务端，所以开源社区用 Datadog-Agent 的较少。

我们做夜莺监控的时候，适配了 Datadog-Agent 的传输协议，也就是说，你可以使用 Datadog-Agent 做为采集器，采集到监控数据之后传输给夜莺。

Datadog-Agent 老版本主要是采用 Python 编写，新版本慢慢换成了 Go，不过还有很多代码仍然是 Python 的，内置了一个 Python 解析器，包比较大，不过个人认为，相比他的强大的采集能力，包大一点没啥大不了的。大家可以试用一下。如果使用 Datadog-Agent 采集数据，要把监控数据推给夜莺的服务端模块，地址例子：http://N9E-SERVER/datadog

Node-Exporter

这个大家比较熟悉了，专注在机器层面的指标监控，并且只专注机器层面的指标监控，因为是 Prometheus 生态的组件，使用 Prometheus 的用户初次入行，大概率会采用这个采集器。如果可以接受PULL模式并且只是处理机器监控，Node-Exporter 是完全够用的。

Categraf

Categraf 是 Flashcat 开源的一款监控采集器，开源协议是MIT，非常开放。

你可能会想，已经有这么多采集器了，为何还要再造一个轮子呢？我们的定位是类似 Grafana-Agent，支持 metrics、logs、traces 的采集，未来也会支持 events 的采集，对于同类监控目标的多个实例的场景，又希望做出 Telegraf 的体验，同时对于所有的采集插件，不但会提供采集能力，也会提供监控大盘、告警规则，让社区开箱即用。

Categraf 偏重 Prometheus 生态，标签是稳态结构，只采集数值型时序数据，通过 Remote Write 方式推数据给后端存储，所有支持 Remote Write 协议的时序库都可以对接，比如 Prometheus、VictoriaMetrics、M3DB、Thanos 等等。

对于习惯使用 Prometheus 的用户，Categraf 也支持直接读取 prometheus.yml 中的 scrape 规则，对接各类服务发现机制，实现上就是把 Prometheus agent mode 的代码引入进来了。

带外监控

带外监控走的是带外网络，协议走的是IPMI和SNMP协议。

IPMI可用于监控硬件的物理参数，如系统温度、风扇速度、电源电压等。可以有效地利用IPMI监控硬件温度、功耗、启动/关闭服务器和系统以及进行日志记录。IPMI的一个主要亮点是，它的功能独立于服务器的CPU和操作系统。IPMI可用于管理各种远程位置的服务器，而不管安装的操作系统是什么，因为固件直接在服务器主板上运行。

BMC也可以开启SNMP的支持，通过SNMP Trap做硬件监控，是一个挺好的思路，不过目前没有看到很好的产品，可能一些老牌的国外的监控产品可以做，因为那些产品都偏老套且收费昂贵，我也没有研究。等后面我研究一下，再给大家分享。不过现在大都在上公有云，传统的SNMP Trap的监控，已经是一个存量需求了，不懂也不用太过焦虑，哈哈。

总结

这个博客主要是介绍了机器层面的监控，OS内部的agent以及带外手段，带外监控在公有云市场环境下是不需要的，大家可以重点关注OS内的监控。

关于作者

本文作者秦晓辉，快猫星云合伙人，文章内容是快猫技术团队共同沉淀的结晶，作者做了编辑整理，我们会持续输出监控、稳定性保障相关的技术文章，文章可转载，转载请注明出处，尊重技术人员的成果。