使用Prometheus进行Kubernetes监视:AlertManager,Grafana,PushGateway(第2部分)

要部署真正的Kubernetes和微服务监控解决方案,需要许多其他支持组件,包括规则和警报(AlertManager),图形可视化层(Grafana),长期指标存储以及与该软件不兼容的其他指标适配器 盒子外面。

在第二部分中,我们将简要介绍所有这些支持组件,前提是已经了解了上一章介绍的部署Prometheus监视服务器的基础知识。

Prometheus监控技术栈–体系结构概述
让我们从部署架构概述开始,将我们将在接下来的部分中讨论的所有组件放入其中。

1、在第1部分中介绍的Prometheus服务器是此部署的核心。 Prometheus服务器将警报推送到AlertManager组件,Alertmanager将使用不同的通知渠道或接收者进行分类,路由和通知。
2、我们将为Grafana配置Prometheus数据源,并通过其Web界面展示数据可视化和仪表板。
3、使用Kubernetes PersistentVolumes,我们将配置长期指标存储。
4、我们还将介绍临时维护任务及其相关指标。 Pushgateway将负责将其存储足够长的时间,以供Prometheus服务器收集。

AlertManager,Prometheus 监控报警Kubernetes
普罗米修斯警报分为两个部分:

使用Prometheus服务器中的PromQL配置实际警报条件。
AlertManager组件接收活动警报:
AlertManager根据它们的元数据(标签)对它们进行分类和分组,并可以选择使用接收者(Webhook,电子邮件,PagerDuty等)将其静音或通知它们。
AlertManager设计为水平缩放,实例可以与其对等方进行通信,从而提供最少的配置。
我们将从一些基本概念开始,下一部分包含一个可以直接在集群中运行的实际例子。

让我们回顾一下普罗米修斯警报规则的结构:

expr键是Prometheus表达式,将定期对其进行评估,如果为true,则将触发。
可以定义最短评估时间,以免在出现临时的自我修复故障时发出警报。
与Kubernetes上下文中的许多其他设计一样,选择的标签与分组,分类和层次结构非常相关。 稍后,AlertManager将根据这些标签来决定哪些警报具有更高的优先级,如何将警报分组在一起等。
现在,可以直接在Web界面上显示Prometheus服务器已成功加载的警报(状态->规则):

以及目前正在触发的警报(警告):

现在,有了一些警报条件,需要将警报转发到AlertManager。

与指标终结点一样,AlertManager服务也可以使用不同的方法自动检测:DNS发现,Consul等。

鉴于我们正在谈论在Kubernetes上下文中进行Prometheus监视,我们可以利用基本的Kubernetes抽象:服务。

从Prometheus服务器的角度来看,此配置只是一个静态名称,但是Kubernetes服务可以在后台执行不同的HA / LoadBalancing转发。

AlertManager本身是一款复杂的软件,涵盖了以下基础知识:

AlertManager根据标签和来源将不同的警报分组
这种分组和层次构成了“路由树”。决定要采取哪些动作的决策树。
例如,我们可以配置路由树,以便将每个带有标签k8s-cluster-component的警报发送到“ cluster-admin”邮件地址。
使用禁止规则,如果另一个警报正在触发,则可以禁止一个警报或一组警报。例如,如果集群关闭且完全无法访问,则没有必要通知集群所包含的各个微服务的状态。
警报可以转发到“接收者”,即电子邮件,PagerDuty,webhook等通知网关。
一个简单的AlertManager配置示例:

该路由树仅配置一个根节点。

在此示例中,我们使用通用JSON Webhook作为接收器,无需部署自己的服务器https://webhook.site将提供用于测试目的的临时端点(显然,特定URL代码示例会有所不同)。

使用AlertManager进行Prometheus监视,尝试一下!
只需要克隆存储库并以正确的顺序应用yaml文件:

现在,访问https://webhook.site/并替换在alertmanager.yml文件中获得的随机URL,URL:“your url here”参数,然后:

几秒钟后,所有pod都应处于“运行”状态:

此配置包括“ DeadManSwitch”,这是一个始终会触发的警报,旨在测试所有微服务Prometheus-> AlertManager-> Notification通道是否按预期工作:

检查webhook URL,以JSON格式查找通知:

Grafana,使用Prometheus进行Kubernetes监控–仪表板
Grafana项目是的分析和监视平台。 它不属于Prometheus,但已成为创建完整Prometheus解决方案的最受欢迎的附加组件之一。

我们将使用Helm Kubernetes软件包管理器进行此部署,这将使我们能够使用一组可重复的ConfigMap配置Grafana,从而避免了任何手动的后配置:

请注意控制台将输出的helm说明,尤其是有关如何检索管理员密码的说明:

我们可以将grafana服务端口直接转发到本地主机以访问该接口:

如果要查看界面,请使用浏览器访问http:// localhost:3000。

为了使Grafana有用,需要两种配置:

数据源,在我们的案例中是Prometheus服务器

仪表板以可视化选择的指标

方便可以(并且应该,如果可能的话)从配置文件中自动配置这两个文件:

创建kubectl -f prometheus-monitoring-guide / grafana / configmap“创建dashboard-k8s-capacity” configmap已创建“ sample-grafana-datasource”

再一次,我们使用服务抽象来指向仅一个URL的多个Prometheus服务器节点

然后,Grafana将为Prometheus收集的指标提供可视化和仪表板:

短暂工作程序的普罗米修斯指标– Push Gateway
并非每个程序都是连续运行的服务,可以期望在任何随机时间都将其废弃。 每个IT部署都有大量一次性或计划任务,用于备份,清理,维护,测试等。

我们可能想从这些任务中收集一些指标,但是Prometheus的目标/抓取模型肯定不会在这里起作用。

这就是Prometheus项目提供Pushgateway服务的原因:临时和批处理作业的推送接受器。 可以将指标推送到pushgateway,它将保留信息,以便以后可以将其抓取。

部署基本的功能推送网关非常简单:

转发Pushgateway Pod的服务端口:

并尝试使用curl发布一个指标,这基本上就是批处理工作:

现在,即使原始源不再运行,也可以正常刮取该指标:

只需要在Prometheus配置中将pushgateway添加为常规的抓取目标即可恢复这些其他指标。

Prometheus持久指标存储
Prometheus服务器默认将度量标准存储在本地文件夹中15天。还请记住,默认的本地Pod存储为临时存储,这意味着如果出于任何原因更换了Pod,则所有指标都将消失。

任何准备就绪的生产部署都需要配置一个持久性存储接口,该接口将能够维护历史指标数据并在Pod重新启动后继续存在。

同样,Kubernetes已经提供了可以实现此功能的抽象:PersistentVolume

但是,正如我们刚刚讨论的那样,PersistentVolume只是数据量的抽象,因此需要一个提供实际量的硬件/软件堆栈。

有几种方法可以实现此目的:

大型云提供商通常提供开箱即用的协调器,因此无需安装任何其他软件。
如果使用自己的主机,但还没有存储提供商,则可以使用开源和经CNCF批准的解决方案,例如Rook
如果想快速启动并运行,还可以使用Helm安装Rook。
诸如NetApp之类的几种商业存储解决方案还为Kubernetes持久卷提供了一个兼容性层。
如果打算使用有状态存储,则可以使用Kubernetes StatefulSets而不是部署。每个pod都将明确地绑定到单独的PersistentVolume,因此可以杀死并重新创建pod,它们将自动附加正确的卷。

可以尝试使用StatefulSets破坏部署并创建类似的服务:

每个pod都会创建自己的PersistentVolume:

我们之前使用的部署与该有状态集之间存在三个主要区别:

API对象类型:

VolumeClaim定义应为集合中的每个Pod创建的存储:

定义数据目录和保留期的Prometheus服务器参数:

平均而言,普罗米修斯每个样本仅使用大约1-2个字节。 因此,要计划Prometheus服务器的容量,可以使用以下粗略公式:

Prometheus服务器还可以定期将度量标准转发到远程端点,并且仅在本地存储最后一个未提交的读数块。 一些云级/多站点Prometheus解决方案(例如Cortex或Thanos解决方案)利用了此功能,我们将在本指南的最后一章中介绍它们。

总结
本指南的第1部分介绍了Prometheus服务的基础知识,它与Kubernetes Orchestrator的集成以及在典型的云规模部署中可以找到的各种微服务。 在第2部分中,围绕在警报Prometheus核心服务器上添加警报,仪表板和长期存储的讨论,我们将更接近可行的监视解决方案。

在下一章中,我们将说明如何使用Prometheus-operator的Kubernetes版本,该版本可以以更加自动化,可扩展和声明性的方式更快地部署完整堆栈。

原文:https://sysdig.com/blog/kubernetes-monitoring-with-prometheus-alertmanager-grafana-pushgateway-part-2/