本文为Kubernetes监控系列的第二篇文章。系列文件夹例如以下：
Kubernetes集群的监控报警策略最佳实践（本篇）
Kubernetes中的服务发现与故障排除（敬请期待）
Docker与Kubernetes在WayBlazer的使用案例（敬请期待）
监控是每一个优质基础设施的基础，是达到可靠性层次的基础。
监控有助于降低对突发事件的响应时间，实现对系统问题的检測、故障排除和调试。
在基础设施高度动态的云时代。监控也是容量规划的基础。
有效的警报是监控策略的基石。当你转向容器和Kubernetes编排环境，你的警报策略也须要演进。正是由于下面几个核心原因。当中很多我们在"怎样监视Kubernetes"中进行了讲述：
可见性：容器是一个黑盒。
传统工具仅仅能针对公共监控端点进行检查。假设想深入监控相关服务，则须要採取不一样的方法。
新的基础架构层：如今服务和主机之间有一个新的层：容器和容器编排服务。
这些是你须要监控的新内部服务，你的监控系统须要了解这些服务。
动态重调度：容器没有像之前那样的服务节点。所以传统的监控不能有效地工作。没有获取服务度量标准的静态端点，没有执行服务实例的静态数量（设想一个金丝雀公布或自己主动伸缩设置）。在某节点中一个进程被kill是正常的。由于它有非常大的机会被又一次调度到基础设施的其它节点。
元数据和标签：随着服务跨多个容器，为全部这些服务加入系统级别的监控以及服务特定的度量标准，再加上Kubernetes带来的全部新服务。怎样让全部这些信息对我们有所帮助？有时你希望看到分布在不同节点容器中的服务的网络请求度量，有时你希望看到特定节点中全部容器的同样度量。而不关心它们属于哪个服务。这就须要一个多维度量系统，须要从不同的角度来看待这些指标。假设通过Kubernetes中存在的不同标签自己主动标记度量标准，而且监控系统能够了解Kubernetes元数据，那么仅仅须要在每种情况下依照须要聚合和切割度量标准就能够实现多维度度量。
考虑到这些问题。让我们创建一组对Kubernetes环境至关重要的报警策略。
我们的Kubernetes报警策略教程将涵盖：
应用程序层度量标准的报警
Kubernetes上执行的服务的报警
Kubernetes基础设施的报警
在主机/节点层上的报警
最后我们还将通过检測系统调用问题来了解怎样通过报警加速故障排除。
下面演示样例是一个公共REST API端点监控警报，监控prod命令空间中的名为javaapp的deployment，在10分钟内假设延迟超过1秒则报警。
全部这些报警高度依赖于应用程序、工作负载模式等等，但真正的问题是怎样在全部服务中一致性地获取数据。
在理想环境中，除了核心监控工具之外。无需再购买综合监控服务就可以获得这一套关键指标。
这个类别中常常出现的一些指标和报警是：
服务对应时间
服务可用性
SLA合规性
每秒请求的成功/失败数
没错。假设想知道服务的全局执行和执行情况，就须要利用监视工具功能依据容器元数据将度量标准进行聚合和分段。
如第一篇文章所述。Kubernetes将容器标记为一个deployment或者通过一个service进行暴露，在定义报警时就须要考虑这些因素。比如针对生产环境的报警（可能通过命名空间进行定义）。
下面是Cassandra集群的演示样例：
假设我们在Kubernetes、AWS EC2或OpenStack中执行Cassandra。则衡量指标cassandra.compactions.pending存在每一个实例上，可是如今我们要查看在prod命名空间内的cassandra复制控制器中聚合的指标。这两个标签都来自Kubernetes，但我们也能够更改范围，包含来自AWS或其它云提供商的标签，比如可用区域。
这个类别中常常出现的一些指标和警报是：
HTTP请求数
数据库连接数、副本数
线程数、文件描写叙述符数、连接数
中间件特定指标：Python uwsgi worker数量。JVM堆大小等
另外，假设正在使用外部托管服务。则非常可能须要从这些提供程序导入度量标准。由于它们可能还有须要做出反应的事件。
由Kubernetes处理的服务
1.1 是否有足够的Pod/Container给每一个应用程序执行？
Kubernetes能够通过Deployments、Replica Sets和Replication Controllers来处理具有多个Pod的应用程序。它们之间差别比較小。能够使用它们来维护执行同样应用程序的多个实例。执行实例的数量能够动态地进行伸缩，甚至能够通过自己主动缩放来实现自己主动化。
执行容器数量可能发生变化的原因有多种：由于节点失败或资源不足将容器又一次调度到不同主机或者进行新版本号的滚动部署等。假设在延长的时间段内执行的副本数或实例的数量低于我们所需的副本数，则表示某些组件工作不正常（缺少足够的节点或资源、Kubernetes或Docker Engine故障、Docker镜像损坏等等）。
在Kubernetes部署服务中。跨多个服务进行例如以下报警策略对照是非常有必要的：
timeAvg(kubernetes.replicaSet.replicas.running) < timeAvg(kubernetes.replicaSet.replicas.desired)
正如之前所说，在又一次调度与迁移过程执行中的实例副本数少于预期是可接受的。所以对每一个容器须要关注配置项 .spec.minReadySeconds （表示容器从启动到可用状态的时间）。你可能也须要检查 .spec.strategy.rollingUpdate.maxUnavailable 配置项，它定义了在滚动部署期间有多少容器能够处于不可用状态。
下面是上述报警策略的一个演示样例，在 wordpress 命名空间中集群 kubernetes-dev 的一个deployment wordpress-wordpress。
1.2 是否有给定应用程序的不论什么Pod/Container？
与之前的警报相似。但具有更高的优先级（比如，这个应用程序是半夜获取页面的备选对象）。将提醒是否没有为给定应用程序执行容器。
下面演示样例，在同样的deployment中添加警报，但不同的是1分钟内执行Pod <1时触发：
1.3 重新启动循环中是否有不论什么Pod/Container？
在部署新版本号时。假设没有足够的可用资源，或者仅仅是某些需求或依赖关系不存在，容器或Pod终于可能会在循环中持续又一次启动。这样的情况称为“CrashLoopBackOff”。发生这样的情况时，Pod永远不会进入就绪状态，从而被视为不可用，而且不会处于执行状态，因此，这样的场景已被报警覆盖。虽然如此。笔者仍希望设置一个警报，以便在整个基础架构中捕捉到这样的行为。马上了解详细问题。这不是那种中断睡眠的报警，但会有不少实用的信息。
这是在整个基础架构中应用的一个演示样例，在过去的2分钟内检測到4次以上的又一次启动：
监控Kubernetes系统服务
除了确保Kubernetes能正常完毕其工作之外。我们还希望监測Kubernetes的内部健康状况。这将取决于Kubernetes集群安装的不同组件。由于这些可能会依据不同部署选择而改变，但有一些基本组件是同样的。
2.1 etcd是否正常执行？
etcd是Kubernetes的分布式服务发现、通信、命令通道。监控etcd能够像监控不论什么分布式键值数据库一样深入，但会使事情变得简单。
我们能够进一步去监控设置命令失败或者节点数，可是我们将会把它留给未来的etcd监控文章来描写叙述。
2.2 集群中有足够的节点吗？
节点故障在Kubernetes中不是问题。调度程序将在其它可用节点中生成容器。
可是，假设我们耗尽节点呢？或者已部署的应用程序的资源需求超过了现有节点？或者我们达到配额限制？
在这样的情况下发出警报并不easy，由于这取决于你想要在待机状态下有多少个节点，或者你想要在现有节点上推送多少超额配置。能够使用监控度量值kube_node_status_ready和kube_node_spec_unschedulable进行节点状态警报。
假设要进行容量级别报警，则必须将每一个已调度Pod请求的CPU和memory进行累加。然后检查是否会覆盖每一个节点，使用监控度量值kube_node_status_capacity_cpu_cores和kube_node_status_capacity_memory_bytes。
在主机/节点层上的报警
主要差别是如今警报的严重程度。
在此之前。系统服务宕机可能意味着你的应用程序停止执行而且要紧急处理事故（禁止有效的高可用性）。而对于Kubernetes来说当服务发生异常，服务能够在主机之间移动。主机警报不应该不受重视。
让我们看看我们应该考虑的几个方面：
1. 主机宕机
假设主机停机或无法訪问，我们希望收到通知。
我们将在整个基础架构中应用此单一警报。我们打算给它一个5分钟的等待时间。由于我们不想看到网络连接问题上的嘈杂警报。
你可能希望将其降低到1或2分钟，详细取决于你希望接收通知的速度。
2. 磁盘利用率
这是略微复杂一些的警报。我们在整个基础架构的全部文件系统中应用此警报。我们将范围设置为 everywhere，并针对每一个 fs.mountDir 设置单独的评估/警报。
下面是超过80％使用率的通用警报。但你可能须要不同的策略。如具有更高阈值（95％）或不同阈值的更高优先级警报（详细取决于文件系统）。
假设要为不同的服务或主机创建不同的阈值。仅仅需更改要应用特定阈值的范围。
3. 一些其它资源
此类别中的常见资源是有关负载、CPU使用率、内存和交换空间使用情况的警报。假设在一定的时间内这些数据中的不论什么一个显著提升，可能就须要警报提醒您。
我们须要在阈值、等待时间以及怎样判定噪声警报之间进行折中。
假设您想为这些资源设置指标。请參考下面指标：
负载：load.average.1m, load.average.5m 和 load.average.15m
CPU：cpu.used.percent
memory：memory.used.percent 或 memory.bytes.used
swap：memory.swap.used.percent 或 memory.swap.bytes.used
一些人同样使用这个类别监控他们部分基础架构所在云服务提供商的资源。
这可能是云提供商的一个事件，但希望Kubernetes正在处理这个问题，而且仅仅须要花费一些时间来应对负载。
可是假设一些更棘手的问题出如今我们面前。我们能够看到我们拥有的全部武器：提供者状态页面、日志（希望来自中心位置）、不论什么形式的APM或分布式追踪（假设开发者安装了代码或者外部综合监測）。然后，我们祈祷这一事件在这些地方留下了一些线索。以便我们能够追溯到问题出现的多种来源原因。
我们怎么能够在警报被解除时自己主动dump全部系统调用？系统调用是所发生事情的真实来源，并将包含我们能够获得的全部信息。通过系统调用有可能发现触发警报的根本问题所在。Sysdig Monitor同意在警报触发时自己主动開始捕获全部系统调用。
比如，能够配置CrashLoopBackOff场景：
仅仅有当你安装代码后。Sysdig Monitor代理才干从系统调用拦截中计算出来对应的指标。
考虑HTTP响应时间或SQL响应时间。Sysdig Monitor代理程序在套接字上捕获read()和write()系统调用。解码应用程序协议并计算转发到我们时间序列数据库中的指标。这样做的优点是能够在不触及开发者代码的情况下获得仪表盘数据和警报：
能够利用Kubernetes和云服务提供商的元数据信息来汇总和细分监控指标和警报将成为多层次有效监控的必要条件。我们已经看到怎样使用标签来更新我们已有的警报或创建Kubernetes上所需的新警报。
接下来，让我们看看在Kubernetes编排环境中的典型服务发现故障排除的挑战。
原文链接：https://sysdig.com/blog/alerting-kubernetes/
深入浅出Kubernetes及企业AI平台落地实践培训
4月20日正式上课，点击阅读原文链接就可以报名。