共计 1613 个字符，预计需要花费 5 分钟才能阅读完成。
前言
监控是保障系统稳定性的重要组成部分，在 Kubernetes 开源生态中，资源类的监控工具与组件百花齐放。除了社区自己孵化的 metrics-server，还有从CNCF 毕业的 Prometheus 等等，开发者可选的方案有很多。但是，只有资源类的监控是远远不够的，因为资源监控存在如下两个主要的缺欠：
- 监控的实时性与准确性不足
大部分资源监控都是基于推或者拉的模式进行数据离线，因此通常数据是每隔一段时间采集一次，如果在时间间隔内出现一些毛刺或者异常，而在下一个采集点到达时恢复，大部分的采集系统会吞掉这个异常。而针对毛刺的场景，阶段的采集会自动削峰，从而造成准确性的降低。
- 监控的场景覆盖范围不足
部分监控场景是无法通过资源表述的，比如 Pod 的启动停止，是无法简单的用资源的利用率来计量的，因为当资源为 0 的时候，我们是不能区分这个状态产生的真实原因。
基于上述两个问题，Kubernetes 是怎么解决的呢？
事件监控 - 监控的新维度
Kubernetes 作为云原生的平台实现，从架构设计上将接口与实现做到了完整的解耦和插拔，以状态机为整体的设计原则，通过设定期望状态、执行状态转换、检查并补偿状态的方式将资源的生命周期进行接管。
状态之间的转换会产生相应的转换事件，在 Kubernetes 中，事件分为两种，一种是 Warning 事件，表示产生这个事件的状态转换是在非预期的状态之间产生的；另外一种是 Normal 事件，表示期望到达的状态，和目前达到的状态是一致的。我们用一个 Pod 的生命周期进行举例，当创建一个 Pod 的时候，首先 Pod 会进入 Pending 的状态，等待镜像的拉取，当镜像录取完毕并通过健康检查的时候，Pod 的状态就变为 Running。此时会生成 Normal 的事件。而如果在运行中，由于 OOM 或者其他原因造成 Pod 宕掉，进入 Failed 的状态，而这种状态是非预期的，那么此时会在 Kubernetes 中产生 Warning 的事件。那么针对这种场景而言，如果我们能够通过监控事件的产生就可以非常及时的查看到一些容易被资源监控忽略的问题。
一个标准的 Kubernetes 事件有如下几个重要的属性，通过这些属性可以更好地诊断和告警问题。
- Namespace：产生事件的对象所在的命名空间。
- Kind：绑定事件的对象的类型，例如：Node、Pod、Namespace、Componenet 等等。
- Timestamp：事件产生的时间等等。
- Reason：产生这个事件的原因。
- Message: 事件的具体描述。
- 其他信息
通过事件的机制，我们可以丰富 Kuernetes 在监控方面的维度和准确性，弥补其他监控方案的缺欠。
kube-eventer v1.0.0 的发布与开源
针对 Kubernetes 的事件监控场景，Kuernetes 社区在 Heapter 中提供了简单的事件离线能力，后来随着 Heapster 的废弃，相关的能力也一起被归档了。为了弥补事件监控场景的缺失，阿里云容器服务发布并开源了 kubernetes 事件离线工具kube-eventer。支持离线 kubernetes 事件到钉钉机器人、SLS 日志服务、Kafka 开源消息队列、InfluxDB 时序数据库等等。
在本次正式发布的 v1.0.0 的版本中，作了如下功能的增强。
- 钉钉插件支持 Namespace、Kind 的过滤
- 支持与 NPD 插件的集成与部署
- 优化 SLS 插件的数据离线性能
- 修复 InfluxDB 插件启动参数失效的问题
- 修复 Dockerfile 的安全漏洞
- 以及其他共 11 项功能修复
典型场景分析：
- 使用钉钉进行事件告警
- 使用 SLS 进行事件告警
- 结合 NPD 进行异常检测与事件告警, 此外使用容器服务的开发者可以直接用应用目录中的 Helm Chart 进行部署。
项目开源地址：https://github.com/AliyunContainerService/kube-eventer
本文作者：莫源
阅读原文
本文为云栖社区原创内容，未经允许不得转载。
