十二、可观测性——监控与日志

背景

在 Kubernetes 中，监控和日志属于生态的一部分，它并不是核心组件，因此大部分的能力依赖上层的云厂商的适配。Kubernetes 定义了介入的接口标准和规范，任何符合接口标准的组件都可以快速集成。

日志：排查问题的重要途径。 监控：及时暴露问题，防止进一步恶化。

监控

监控类型

在 K8s 中可以分成四个不同的类型：

1. 资源监控 CPU、内存、网络这种资源类的一个指标。相关监控系统有：zabbix、telegraph
2. 性能监控 APM(Application Performance Management)，通常是通过一些 Hook 的机制在虚拟机层、字节码执行层通过隐式调用，或者是在应用层显示注入，获取更深层次的一个监控指标，一般是用来应用的调优和诊断的。例如Zend Engine，通过一些常见的 Hook 机制，拿到类似像 jvm 里面的 GC 的次数，各种内存代的一个分布以及网络连接数的一些指标。
3. 安全监控 越权管理、安全漏洞扫描等.
4. 事件监控 k8s中状态转换时产生的 normal、warning 事件。

Kubernetes 的监控演进

1.10 以前的 K8s 版本，大家会使用 Heapster 这样的组件来去进行监控的采集。

img

• 每个 pod 包含一个 cadvisor 负责数据采集
• Heapster 会定期去每一个节点拉取数据，在自己的内存里面进行聚合，然后再暴露相应的 service，供上层的消费者进行使用
• K8s 中比较常见的消费者，dashboard，或者是 HPA-Controller，通过调用 service 获取相应的监控数据，来实现相应的弹性伸缩，以及监控数据的一个展示。

存在的问题

1. Heapster 在做监控数据接口的标准化，无法定制化开发
2. Heapster 里面为了保证数据的离线能力，提供了很多的 sink（把数据采集下来，并且把这个数据离线走），包含了类似像 influxdb、sls、钉钉等等一系列 sink。但是没人维护，存在bug无人修复的情况。

基于这两点原因，K8s 把 Heapster 进行了 break 掉，然后做了一个精简版的监控采集组件，叫做 metrics-server。

Heapster 和 metrics-server 的架构对比

img

• source：采集数据
• processor：数据转换以及数据聚合
• sink：数据离线

img

• API Registration：把数据接口注册到 K8s 的 API server 之上，客户不再需要通过 API 层去访问 metrics-server，而是通过 API server 访问 API 注册层，再到 metrics-server
• 真正的数据消费方可能感知到的并不是一个 metrics-server，而是说感知到的是实现了这样一个 API 的具体的实现，而这个实现是 metrics-server。 达到解耦的目的，依赖于抽象不依赖于具体，桥接模式的思想

Kubernetes 的监控接口标准

在 K8s 里面针对于监控，有三种不同的接口标准。它将监控的数据消费能力进行了标准化和解耦。

1. Resource Metrice 对应的接口是 metrics.k8s.io，主要的实现就是 metrics-server，它提供的是资源的监控，比较常见的是节点级别、pod 级别、namespace 级别、class 级别。
2. Custom Metrics 对应的 API 是 custom.metrics.k8s.io，主要的实现是 Prometheus。它提供的是资源监控和自定义监控，资源监控和上面的资源监控其实是有覆盖关系的，而这个自定义监控指的是：比如应用上面想暴露一个类似像在线人数，或者说调用后面的这个数据库的MySQL 的慢查询。通过标准的 Prometheus 的 client，暴露出相应的 metrics，然后再被 Prometheus 进行采集。
3. External Metrics 对应的 API 是 external.metrics.k8s.io，主要的实现是各个云厂商的 provider，通过这个 provider 可以获取云资源的监控指标。例如接入层 SLB 的 connection 数目，消息队列中消息的数目。

Promethues - 开源社区的监控“标准”

• Prometheus 是 CNCF 云原生社区的一个毕业项目。越来越多的开源项目都以 Prometheus 作为监控标准，例如 Spark、Tensorflow、Flink 这些项目，都有标准的 Prometheus 的采集接口。
• 常见的一些数据库、中间件，都有相应的 Prometheus 采集客户端。例如 ETCD、zookeeper、MySQL 或者说 PostgreSQL，都有相应的 Prometheus 的接口，如果没有的，社区里面也可能有相应的 exporter 进行接口的一个实现。

采集方式

1. pull 普罗米修斯定时去采集数据，实现简单，但是采集周期内被采集方挂了，会造成数据丢失
2. push 被采集方将数据 push 到 pushgetway，再由普罗米修斯去定时采集。 普罗米修斯的压力分担到各个 pushgetway
3. Prometheus on Prometheus 可以通过另一个 Prometheus 来去同步数据到这个 Prometheus。

介绍

• 普罗米修斯支持服务发现
• 在报警方面，Prometheus 提供了一个外置组件叫 Alentmanager，它可以将相应的报警信息通过邮件或者短信的方式进行数据的一个告警。
• 在数据消费上面，可以通过上层的 API clients，可以通过 web UI，可以通过 Grafana 进行数据的展现和数据的消费。
• K8s 里面使用 Prometheus，推荐使用 Prometheus Operator 的方式来去进行部署和运维。

日志

日志的场景

主机内核的日志

• 主机内核的日志，比如说网栈的异常，类似像我们的 iptables mark，它可以看到有 controller table 这样的一些 message；
• 驱动异常，比较常见的是一些网络驱动异常， GPU 的一些场景，驱动异常可能是比较常见的一些错误
• 文件系统异常，在早期 docker 还不是很成熟的场景之下，overlayfs 或者是 AUFS，实际上是会经常出现问题的
• 影响节点的一些异常，比如说内核里面的一些 kernel panic，或者是一些 OOM

Runtime 的日志

比较常见的是 Docker 的一些日志，排查类似像删除一些 Pod Hang 这一系列的问题。

核心组件的日志

etcd、API server、kube-scheduler、controller-manger、kubelet等组件的日志。网络中间件 Ingress 的日志可以观测到接入层的流量

应用的日志

日志的采集

img

1. 宿主机文件，通过 volume，把日志文件写到了宿主机之上。通过宿主机的日志轮转的策略进行日志的轮转，然后再通过 agent 进行采集；
2. 容器内有日志文件，比较常见的一个方式是通过一个 Sidecar 的 streaming 的 container，转写到 stdout，通过 stdout 写到相应的 log-file，然后再通过本地的一个日志轮转，然后以及外部的一个 agent 采集；
3. 直接写到 stdout，这种比较常见的一个策略是直接用 agent 去采集到远端，或者通过类似像一些 sls 的标准 API 采集到远端。

比较推荐的是使用 Fluentd 的一个采集方案，Fluentd 是在每一个节点上面都会起相应的 agent，然后这个 agent 会把数据汇集到一个 Fluentd 的一个 server，这个 server 里面可以将数据离线到相应的类似像 elasticsearch，然后再通过 kibana 做展现；或者是离线到 influxdb，然后通过 Grafana 做展现。

其他

• 容器 & 服务: k8s的扩容与自动扩容
• --dry-run=client 参数来预览而不真正提交
• kubectl create xxx --dry-run=client -o yaml生成指定资源的编排文件
• 使用 Apache util2 的ab命令对服务进行压测 ab -n 20000 -c 1000 "http://jd.com/" 其中参数-n：请求数；-c：并发数