【翻译】普罗米修斯权威指南第三部分

作者：尼纳德-德赛 10月25日, 2021年

原文为InfraCloud博客上的客座文章，作者为InfraCloud的Ninad Desai

在上一篇文章中，我们介绍了监控基础知识，包括Prometheus、指标、其最常见的使用情况，以及如何使用PromQL查询Prometheus数据。如果你刚刚开始使用Prometheus，我强烈建议你阅读 "Prometheus权威指南 "系列的前两部分。在这篇博文中，我们将重点介绍如何使用Prometheus Operator和Helm在Kubernetes集群上以简单的方式安装和管理Prometheus。让我们开始吧!

什么是操作员？

在直接进入使用普罗米修斯操作员安装普罗米修斯之前，让我们先了解一下理解普罗米修斯操作员所需的一些关键概念。

自定义资源定义（CRD）资源是定义你自己的资源种类的一种方式，如部署、StatefulSet等。CRD定义了自定义种类的结构和验证。

自定义资源（CR）是通过遵循自定义资源定义（CRD）的结构而创建的资源。

自定义控制器确保我们的Kubernetes集群或应用程序总是将其当前状态与我们期望的状态相匹配。

因此，运营商是我们在集群中部署的一组Kubernetes自定义控制器。这些控制器监听它们所拥有的自定义资源（那些我们使用CRD创建的资源）的变化，并执行某些操作，如创建、修改、删除Kubernetes资源。

你可以在自定义资源文档页面上相关内容。

Kubernetes操作员有哪些用例？

Kubernetes操作员可以。

为在Kubernetes上部署有状态的服务（如任何数据库）提供一个很好的方法
处理你的应用程序代码的升级
根据性能指标对资源进行横向扩展
按需备份和恢复你的应用程序状态或数据库
在Kubernetes上部署任何监控、存储、保险库解决方案

什么是普罗米修斯运营商？

简单地说，Prometheus Operator是一种完全自动化的部署方式（就像其他标准的Kubernetes部署对象一样）Prometheus服务器、Alertmanager和所有相关的秘密、configmap等；这将有助于建立Prometheus监控生态系统并在短短几分钟内实例化Kubernetes集群监控。

一旦部署，Prometheus Operator提供了以下功能。

自动化。为您的Kubernetes命名空间、特定的应用程序或团队轻松启动普罗米修斯实例。

服务发现。使用熟悉的Kubernetes标签查询自动发现要监控的目标；无需学习Prometheus特定的配置语言。

轻松配置。从Kubernetes资源中管理Prometheus的基本资源配置，如版本、持久性、保留策略和副本。

安装Prometheus栈的方法

在Kubernetes中设置Prometheus监控栈有三种不同的方式。

1.自己创建一切

如果你对Prometheus组件和它的每一个先决条件完全熟悉，那么你可以考虑到Prometheus、Alertmanager和Grafana等每个组件的相互依赖性，按正确的顺序为Prometheus栈使用的所有Secrets和ConfigMaps手动部署YAML规范文件。

这种方法可能相当耗时，需要花费大量精力来部署和管理Prometheus生态系统。此外，它还需要建立一个强大的文档，以便在任何其他环境中复制它。

2.使用普罗米修斯操作员

我们已经从概念上看到了普罗米修斯操作者可以通过单手管理所有普罗米修斯组件的生命周期来减轻我们的生活。

我们可以在这里找到普罗米修斯操作员，我们可以用它来在你的Kubernetes集群内部署普罗米修斯。

3.使用Helm图表来部署操作员

这种方法是最有效和更好的选择，我们可以使用由普罗米修斯社区维护的Helm图表来部署普罗米修斯操作员。因此，简而言之，Helm会在创建Prometheus、Alertmanager和其他自定义资源的同时进行Prometheus Operator的初始安装。然后普罗米修斯操作员将管理这些自定义资源的整个生命周期。只需执行以下步骤，就可以非常简单明了地进行安装。

helm repo add prometheus-community https://prometheus-community.github.io/helm-chartshelm repo updatehelm install prometheus prometheus-community/kube-prometheus-stack

这个kube-prometheus-stack图安装了以下组件。

普罗米修斯运营商
Prometheus和Alertmanager（创建Prometheus、Alertmanager和相关CR）
Grafana
node-exporter，以及其他几个导出器

它们也是预配置好的，可以一起工作，为你设置基本的集群监控，同时也很容易调整和添加你自己的定制功能。

上述命令的执行将是相当快的，再花几分钟时间就可以把所有的组件启动和运行。

你可以运行helm get manifest prometheus | kubectl get -f -命令来查看所有创建的对象，如下所示。

你将能够看到所有不同的资源，如部署，Prometheus堆栈的StatefulSets被创建，如上所示。

普罗米修斯如何找到所有要监控和搜刮的目标？

为了让Prometheus找出它需要监控的所有内容，我们需要传递一个YAML配置文件，通常称为prometheus.yaml；Prometheus可以参考该文件并开始相应的监控。要监控的每个目标端点都在prometheus.yaml的scrape_configs部分中定义。Prometheus release tar附带的一个典型的配置文件样本有以下内容。

# 我的全局配置
全局。scrape_interval: 15s# 设置刮擦间隔为每15秒。默认是每1分钟一次。evaluation_interval: 15s# 每15秒评估一次规则。默认是每1分钟一次。
 # scrape_timeout被设置为全局默认值(10s)。

# Alertmanager配置
alerting:alertmanagers:- static_configs:- 目标。- localhost:9093# 加载一次规则，并根据全局的'evaluation_interval'周期性地评估它们。
rule_files:- '/etc/prometheus/alert.rules'。# - "first_rules.yml"# - "second_rules.yml"# 一个搜刮配置，正好包含一个要搜刮的端点。
# 这里是普罗米修斯本身。
scrape_configs:# 工作名称将作为标签`job=<job_name>`添加到任何从该配置刮取的时间序列中。- job_name: 'Prometheus'.# metrics_path默认为'/metrics'。
  # scheme默认为'http'。
static_configs:- 目标。['localhost:9090']- job_name: 'node_exporter'.scrape_interval:5sstatic_configs:- 目标。['localhost:9100']

那么，让我们深入了解prometheus.yaml文件中的一些主要关键术语。

有两种方法可以指定Prometheus要搜刮的一组目标端点。

使用scrape_config
使用ServiceMonitors（Prometheus运营商专用）。

scrape_config与ServiceMonitor。什么时候使用一个而不是另一个？

scrape_config指定了一组目标和配置参数，描述了如何搜刮它们。在这种情况下，对于每个目标，需要定义一个刮削配置块，正如你在上面的样本prometheus.yaml文件中看到的那样。

ServiceMonitor让我们以一种更简单的Kubernetes原生方式在scrape_config中创建一个工作条目。在内部，Prometheus Operator将每个ServiceMonitor资源的配置转换为prometheus.yaml的scrape_config部分。由kube-prometheus-stack创建的Prometheus资源有一个选择器，它说，对所有标签为release: prometheus（配置）的ServiceMonitors采取行动。请看下面的图表，它是如何工作的。

图片来源。CoreOS

让我们以Prometheus服务本身为例，检查ServiceMonitor是否自动在Prometheus配置文件中创建scrape_config条目。

kubectl get services prometheus-prometheus-oper-prometheus -o wide -sow-labels
名称 类型 cluster-ip external-ip port(s) age selector labels
prometheus-prometheus-oper-prometheus ClusterIP 10.105.67.172 <none> 9090/TCP 12d app=prometheus,prometheus=prometheus-prometheus-oper-prometheus app=prometheus-operator-prometheus, release=prometheus, self-monitor=true

我们来看看Prometheus的服务是否有相应的ServiceMonitor。

kubectl get servicemonitors.monitor.coreos.com -l app=prometheus-operator-prometheus
名称 年龄
prometheus-prometheus-oper-prometheus 12d

这证实了Prometheus服务的ServiceMonitor本身是存在的。现在让我们试试这个ServiceMonitor "prometheus-prometheus-oper-prometheus "是否在Prometheus配置YAML文件中添加了一个作业。

要检查这一点，我们首先需要访问普罗米修斯操作员创建的普罗米修斯荚。

kubectl exec -it prometheus-prometheus-prometheus-oper-prometheus-0 -- /bin/sh
/prometheus $

一旦我们进入了pod，让我们找出Prometheus现在在pod内使用的配置文件名称。

/prometheus $ pspid 用户 时间 命令
1 1000 4h58 /bin/prometheus ... --config.file=/etc/prometheus/config_out/prometheus.env.yaml
59 1000 0:00 /bin/sh

我们可以看到，名字为prometheus.env.yaml的配置文件是由操作员创建的，并被Prometheus服务器用来找出要监控和刮取的目标端点。最后，让我们试着找出Prometheus服务本身的工作是否被ServiceMonitor添加到这个配置文件中。

/prometheus $ cat /etc/prometheus/config_out/prometheus.env.yaml | grep -i -A 10 "job_name: default/prometheus-oper-prometheus/0"

- job_name: default/prometheus-prometheus-oper-prometheus/0honor_labels: falsekubernetes_sd_configs:- role: endpointsnamespaces:names:- 默认的metrics_path:/metrics

我们可以看到Prometheus服务的作业。因此，这表明ServiceMonitor会自动为基于Kubernetes的服务创建作业，以进行监测和刮削。

也有另一种方法可以直接在Prometheus Web UI中的Status->Configuration查看scrape_config，你可以看到如下。

除了ServiceMonitor之外，还有一种叫做PodMonitor的方式来刮取你的Kubernetes pods。这也是一个由Prometheus运营商处理的自定义资源。

什么是PodMonitor，什么时候需要它？

PodMonitor声明性地指定了如何直接监控一组pod。

PodMonitor与ServiceMonitor

人们一定想知道，当我们有了ServiceMonitor后，为什么还要有PodMonitor，因为它的工作和ServiceMonitor是一样的。

在我看来，如果你已经为你的pods提供了服务，那么ServiceMonitor是合适的。然而，如果在某种情况下，你没有这样的服务，那么PodMonitor就是正确的选择。

发现要搜刮的目标

要搜刮目标端点，首先Prometheus应该知道这些是什么，以及如何监控这些目标。因此，在Prometheus配置中主要有两种方式来定义要监控的目标端点。

使用static_config机制

如果你有一套非常小而固定的Kubernetes服务/端点需要监控，那么你可以在prometheus.yml文件中使用static_config定义这些静态端点。

看一下这个例子，它显示了我们如何配置Prometheus，使其默认使用static_configs来监控Prometheus本身。

这对于简单的用例来说是没问题的，但实际上，当机器被添加和删除时，必须手动保持你的prometheus.yml的更新，这将变得很烦人，特别是如果你在像Kubernetes这样的动态环境中，应用服务的新实例可能每分钟都被提出来。

使用service_discovery机制

有不同的Prometheus支持的服务发现机制，如DNS、Kubernetes、AWS、Consul、自定义机制等等。这些机制动态地发现要监测和刮取的目标端点。在Kubernetes的情况下，它使用Kubernetes API来发现要监控和刮取的目标端点列表。

看一下这个例子，它显示了我们如何为Kubernetes配置Prometheus。

普罗米修斯操作员负责根据ServiceMonitor和PodMonitor资源进行上述配置。

普罗米修斯的规则

普罗米修斯支持两种类型的规则，可以定期配置和评估。这些主要是。

记录规则
警报规则

您可以创建一个包含规则语句的YAML文件，并使用Prometheus配置中的rule_files字段将其加载到Prometheus。

当使用Prometheus Operator时，这些规则可以在PrometheusRule资源的帮助下创建。

记录规则

记录规则允许你预先计算PromQL表达式，这些表达式是经常使用的，内部需要相对较多的步骤来完成该表达式的结果。下次，当你运行相同的PromQL查询时，结果将从预先计算的PromQL结果中获取。这些比原来反复执行同一查询要快。

比如说

组。- 名称: 示例规则。- 记录：job:http_inprogress_requests:sumexpr: sum by (job) (http_inprogress_requests)

警报规则

警报规则允许你根据PromQL定义警报条件，并向外部接收器发送关于发射警报的通知。只要警报表达式在任何时间点的结果为True，就会发送警报。

比如说

组。
- 名称：示例规则。- 警报：HighRequestLatencyexpr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5为。10m标签。严重程度: page注释。摘要：请求延迟过高

警报和可视化

信用：普罗米修斯介绍

一旦配置了警报规则，我们希望向外部接收者发送警报。我们需要有人能够添加警报摘要，控制，有时甚至是静音接收器将收到的通知的数量。这就是Alertmanager出现的地方。

Alertmanager 洞察力

正如你在上图中看到的，Alertmanager定期从Prometheus服务器接收关于警报状态的信息，然后它确保分组、重复发送并向定义的接收器发送通知，如电子邮件、PagerDuty等。

但是在哪里以及如何在Kubernetes集群中定义或设置Alertmanager？好吧，我们不需要担心这个问题，因为我们之前在Helm图表的帮助下部署的Prometheus运营商，将Alertmanager创建为一个StatefulSet，你可以看到。

kubectl get statefulsets.app 名称 READY AGE
alertmanager-prometheus-prometheus-oper-alertmanager 1/1 8d

这个Alertmanager StatefulSet内部使用了一个名为alertmanager.yaml的配置文件，你可以看到以下内容（在alertmanager pod内）。

/bin/alertmanager --config.file=/etc/alertmanager/config/alertmanager.yaml

在这个alertmanager.yaml文件中（如下图所示），一些关键的东西如路由和接收器被定义。

这里。

路由。这是一个代码块，定义了警报将被进一步路由到哪里。

接收者。接收者是警报将被发送或最后通知的人。它可以是一个webhook或一个电子邮件地址，或像PagerDuty这样的工具。

inhibit_rules:抑制规则部分允许在另一个警报因相同原因被触发的情况下，让一组警报保持沉默。例如，通常情况下，如果任何应用服务发生故障，那么警告级别的通知将被沉默，因为该服务已经进入了关键模式。

你可以看一下Alertmanager的配置文件样本。

全局。resolve_timeout:5m路线。group_by:['alertname']group_wait: 10sgroup_interval: 10srepeat_interval: 1h接收器: 'web.hook'
receivers:
- 名称：'web.hook'webhook_configs:- url:'http://127.0.0.1:5001/'
inhibit_rules:- source_match:严重程度: 'criticaltarget_match:严重性: '警告等于: ['alertname', 'dev', 'instance']

用Grafana进行指标可视化

好了，现在所有的见解都够了，让我们直接访问Grafana，这是一个标准的工具，可以帮助你将你在Prometheus的帮助下收集的所有指标可视化。

我们的kube-prometheus-stack Helm图表已经为我们部署了Grafana。现在，为了访问Grafana仪表板，我们首先需要找到Grafana服务。

kubectl get services 名称 类型 cluster-ip external-ip port(s)       prometheus-grafana ClusterIP 10.104.143.147 <none> 80/TCP

让我们把端口转发到这个服务，这样我们就可以访问Grafana的Web界面了。

kubectl port-forward svc/prometheus-grafana 3000:80从 127.0.0.1:3000 转发 -> 3000
从 [::1]:3000 转发 -> 3000

然后在浏览器中访问<http://localhost:3000>。

如果你能看到下面的Grafana仪表盘，恭喜你！！。

输入默认的用户名：admin和密码：prom-operator，你可以在这个prometheus-operator Github repo中找到，以访问Grafana。

添加这些凭证后，你就可以登录到Grafana了，如下图。

点击Dashboard->Manage，你就可以看到kube-prometheus-stack提供的关于我们Kubernetes集群的所有dashboard。

你可以浏览这些仪表盘中的任何一个。例如，"Kubernetes/Compute Resources/Pod "仪表盘，如下图。

这些标准仪表盘基本上都是由kubernetes-mixin项目生成的。

总结

在结束这篇文章之前，让我们做一个简单的回顾。我们讨论了什么是普罗米修斯操作员，以及我们如何在普罗米修斯操作员和Helm图表的帮助下轻松配置普罗米修斯。我们还探讨了Prometheus如何发现要监控的资源，Prometheus需要配置哪些组件以及它们如何工作。此外，我们还研究了如何设置警报以及如何将其可视化。

我希望你觉得这篇文章内容丰富，引人入胜。如果想了解更多类似的文章，请订阅我们的每周通讯。我很想听听你对这篇文章的看法，所以请在Twitter或LinkedIn上展开对话：）。

参考资料和进一步阅读。

普罗米修斯官方文档
使用Helm和Prometheus Operator在Kubernetes上设置Prometheus监控
Prometheus-operator Github