【.com快译】本文将重点介绍PrometheusOperator和HelmChart的使用方法，以及如何在Kubernetes集群上简单安装和管理Prometheus。首先，让我们了解一些与PrometheusOperator相关的基本概念。CRD（CustomResourceDefinition，自定义资源定义）的方法是让用户自定义Deployment、StatefulSet等资源类型的结构和有效性。其中，CR（CustomResource，定制资源）是根据CRD的结构创建的资源。CustomController（自定义控制器）可以确保Kubernetes集群或应用程序始终将其当前状态与我们期望的状态相匹配。因此，Operator可以理解为我们部署在集群中的一组Kubernetes自定义控制器。它会监听自定义资源中Kubernetes资源的创建、修改、删除等操作。您可以通过链接了解更多关于自定义资源的信息——https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/。KubernetesOperator的用例一般来说，KubernetesOperator可以实现：提供一种在Kubernetes上部署有状态服务（例如各种数据库）的方法处理应用程序代码升级横向扩展资源基于性能指标的按需备份和恢复应用程序的状态或数据库将监控、存储、归档（vault）等解决方案部署到Kubernetes。什么是普罗米修斯运算符？简而言之，类似于其他标准化的Kubernetes部署对象，PrometheusOperator可以部署Prometheusserver、Alertmanager，以及所有相关的keys和configmaps等。这种方法有助于在几分钟内建立一个Prometheus监控系统并实例化Kubernetes集群监控。部署完成后，PrometheusOperator将具有以下功能：自动化：方便地为Kubernetes命名空间、特定应用程序或团队启动Prometheus实例。服务发现：您可以使用熟悉的Kubernetes标签自动发现要监控的目标，而无需额外学习Prometheus的特定配置语言。轻松配置：可以管理Prometheus版本、持久化、保留策略、来自Kubernetes资源的副本等基础资源的配置。如何安装Prometheusstack在Kubernetes中设置Prometheus监控栈的方式有以下三种：1.自己创建一切如果你已经准备好Prometheus组件及其先决条件，可以参考它们的相互依赖关系，手动部署YAML规范Prometheus、Alertmanager、Grafana的所有键和ConfigMaps等每个组件的文件以正确的顺序排列。这种方法通常非常耗时，需要花费大量精力来部署和管理Prometheus生态系统。同时，它需要构建可以在其他环境中复制的强大文档。2.使用PrometheusOperator由于上面提到PrometheusOperator可以管理所有Prometheus组件的生命周期，我们可以参考链接--https://github.com/prometheus-operator/prometheus-operator，部署在Kubernetes集群相应的Prometheus。3、使用HelmChart部署Operator作为一种更好更高效的方式，我们可以使用Prometheus社区维护的HelmChart来部署PrometheusOperator。简而言之，Helm将执行PrometheuOperator的初始安装以及Prometheus、Alertmanager和其他自定义资源的创建。PrometheusOperator然后管理这些自定义资源的整个生命周期。安装步骤如下：Gohelmrepoaddprometheus-communityhttps://prometheus-community.github.io/helm-chartshelmrepoupdatehelminstallprometheusprometheus-community/kube-prometheus-stack这里的kube-Prometheus-stack安装了以下组件：PrometheusOperator创建Prometheus，Alertmanager，与相关的CRGrafana各种节点导出器一起，它们还预先配置为协同工作，并为您设置基本的集群监控，以便您可以轻松调整和添加各种自定义项。上面的命令非常快，只需要几分钟就可以启动并运行所有组件。可以使用“helmgetmanifestPrometheus|kubectlget-f–”命令查看所有创建的对象。如上图所示，您将能够看到所有不同的资源，例如Prometheus堆栈的Deployments和StatefulSets。Prometheus是如何找到所有监控项并抓取目标的？为了让Prometheus发现被监控的对象，我们需要传递一个YAML（名为prometheus.yaml的配置文件，让Prometheus可以引用并实现监控。每个被监控的目标端点都定义在prometheus.yaml中的scrape_configs部分。下面展示了Prometheusreleasetar中自带的典型配置文件的内容：Go#myglobalconfigglobal:scrape_interval:15s#Setthescrapeintervaltoevery15seconds.Defaultisevery1minute.evaluation_interval:15s#Evaluaterulesevery15seconds.Thedefaultisevery1minute.#scrape_timeoutissettotheglobaldefault(10s).#Alertmanagerconfigurationalerting:alertmanagers:-static_configs:-targets:-localhost:9093#Loadrulesonceandperiodicallyevaluatethemaccordingtotheglobal'evaluation_interval'.rule_files:-'/etc/prometheus/alert.rules'#-"first_rules.yml"#-"second_rules.yml"#Acrapeconfigurationcontainingexactlyoneendpointtoscrape:#Hereit'sse#Thejobnameisaddedasalabel`job=`toanytimeseries从这个配置中抓取。-job_name:'prometheus'#metrics_pathdefaultsto'/metrics'#schemedefaultsto'http'.static_configs:-targets:['localhost:9090']-job_name:'node_exporter'scrape_interval_config:5sstatic:-targets:['localhost:9100']接下来，让我们深入了解prometheus.yaml文件中的一些主要目标在关键术语中，我们可以通过以下两种方式为Prometheus指定一组目标端点：scrape_config描述了如何通过指定一组目标和配置参数来抓取它们。即在prometheus.yaml文件中，我们需要为每个target定义一个crawl配置块。ServiceMonitor让我们可以轻松地以Kubernetes原生的方式在scrape_config中创建一个作业条目。在内部，PrometheusOperator将每个ServiceMonitor资源的配置转换为prometheus.yaml的scrape_config部分。kube-prometheus-stack创建的Prometheus资源有一个选择器，可以对标签为release:prometheus的所有ServiceMonitor执行各种操作（见配置）。下图展示了它的工作原理：图片来源：CoreOS(https://www.openshift.com/blog)我们以Prometheus服务本身为例，看看ServiceMonitor是否自动在Prometheus配置文件中创建了一个scrape_config条目。Gokubectlgetservicesprometheus-prometheus-oper-prometheus-owide--show-labelsNAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGESELECTORLABELSprometheus-prometheus-oper-prometheusClusterIP10.105.67.1729090/TCP12dapp=prometheus,prometheus-oper-app=prometheus=普罗米修斯-operator-prometheus,release=prometheus,self-monitor=true根据上面的代码，我们接下来可以检查对应的ServiceMonitor是否准备好用于Prometheus服务。Gokubectlgetservicemonitors.monitoring.coreos.com-lapp=prometheus-operator-prometheusNAMEAGEprometheus-prometheus-oper-prometheus12d上面的代码证实了Prometheus服务本身ServiceMonitor的存在。接下来，让我们检查“prometheus-prometheus-oper-prometheus”是否在PrometheusconfigYAML文件中添加了一个作业。我们首先需要访问PrometheusOperator创建的Prometheuspod。Gokubectlexec-itprometheus-prometheus-prometheus-oper-prometheus-0--/bin/sh/prometheus$让我们通过下面的代码找出Pod中Prometheus使用的配置文件名。go/prometheus$psPIDUSERTIMECOMMAND110004h58/bin/prometheus...--config.file=/etc/prometheus/config_out/prometheus.env.yaml5910000:00/bin/sh从上面的代码，配置文件prometheus.env.yaml创建通过Operator可以被Prometheus服务器用来寻找目标端点进行监控和抓取。最后，让我们检查ServiceMonitor是否已将Prometheus服务本身的作业添加到此配置文件中：Go/Prometheus$cat/etc/Prometheus/config_out/Prometheus。环境。yaml|grep-i-A10“job_name:default/prometheus-prometheus-oper-prometheus/0”Go-job_name:default/prometheus-prometheus-oper-prometheus/0honor_labels:falsekubernetes_sd_configs:-role:endpointsnamespaces:names:-defaultmetrics_path:/metrics从上面的代码可以看出，ServiceMonitor会自动为基于Kubernetes的服务创建一个需要监控和抓取的作业。另外，我们也可以直接在PrometheusWebUI中的Status->Configuration下查看scrape_config方法。如下图所示：除了ServiceMonitor，我们还可以使用PodMonitor方式抓取KubernetesPod，PrometheusOperator处理自定义资源。PodMonitor可以声明式指定如何直接监控一组Pod。你肯定会问，既然有了ServiceMonitor，为什么还需要PodMonitor？主要是ServiceMonitor适用于Pod中已经有Service的场景。否则，您需要PodMonitor。一般情况下，Prometheus可以通过以下两种方式配置来定义要监控的目标端点。使用static_config机制如果要监控的Kubernetes服务/端点非常小且固定，那么可以使用prometheus.yaml文件中的static_config来定义这些静态端点。示例链接显示了如何将Prometheus配置为默认使用static_configs来监控自身。当然，这主要用于简单的用例，并且需要在添加和删除节点时手动更新prometheus.yml。在Kubernetes等动态环境中，新的应用服务实例往往会快速频繁地出现。使用service_discovery机制目前支持Prometheus的服务发现机制包括：DNS、Kubernetes、AWS、Consul等自定义类型。这些机制通常能够动态发现目标端点以进行监控和抓取。对于Kubernetes，可以使用KubernetesAPI来实现。示例链接显示了如何为Kubernetes配置Prometheus。其中，PrometheusOperator负责根据ServiceMonitor和PodMonitor资源完成上述配置。Prometheus规则您可以创建一个包含规则语句的YAML文件，并使用Prometheus配置中的rule_files字段将它们加载到Prometheus中。使用PrometheusOperator时，可以使用PrometheusRule源码的Helm创建相应的规则。目前，Prometheus可以定期配置和评估以下两类规则：记录规则记录规则允许您预先计算经常使用的PromQL表达式，并且需要比较多的步骤来获得表达式的结果。据此，下次运行相同的PromQL查询时，您可以直接从预先计算的PromQL结果中获取它。这比一遍又一遍地执行相同的查询要快得多。例如：Gogroups:-name:examplerules:-record:job:http_inprogress_requests:sumexpr:sumby(job)(http_inprogress_requests)警报规则警报规则允许您将有关已触发警报的通知发送到外部接收器。只要警报表达式的计算结果为True，就会发送警报。例如：Gogroups:-name:examplerules:-alert:HighRequestLatencyexpr:job:request_latency_seconds:mean5m{job="myjob"}>0.5for:10mlabels:severity:pageannotations:summary:Highrequestlatencyalertandvisualization图片来源：Prometheus简介（https://www.youtube.com/watch?v=9GMWvFcQjYI&t=314s)配置完告警规则后，我们需要添加告警摘要、控件，甚至通过Alertmanager“静音”收到的通知。如上图所示，Alertmanager定期从Prometheus服务器接收警报状态信息，以确保对定义的收件人（如电子邮件、PagerDuty等）进行分组、重复数据删除和通知传递。我们不必担心在Kubernetes集群中在哪里以及如何定义或设置Alertmanager。当我们借助HelmChart部署PrometheusOperator时，我们创建了一个Alertmanager作为StatefulSet。请参考以下代码：Gokubectlgetstatefulsets.appsNAMEREADYAGEalertmanager-prometheus-prometheus-oper-alertmanager1/18dAlertmanagerStatefulSet内部会使用一个配置文件--alertmanager.yaml。我们可以将其放入alertmanagerpod中。请查看以下命令：Go/bin/alertmanager--config.file=/etc/alertmanager/config/alertmanager.yamlalertmanager.yaml文件包含以下关键元素：路由：这是一个代码块，可用于定义将警报路由到下一个位置。接收器：接收器是网络钩子、电子邮件地址和可用于发送或通知警报的工具（如PagerDuty）。抑制规则：抑制规则部分可以在出于相同原因触发另一个警报时将其“静音”。例如，对于那些已经处于临界级别的应用服务，即使它们再次失败，它们的警告通知也会被静音。我们可以通过下面的例子查看Alertmanager的配置文件：:-url:'http://127.0.0.1:5001/'inhibit_rules:-source_match:severity:'critical'target_match:severity:'warning'equal:['alertname','dev','instance']使用Grafana指标可视化Grafana作为一种标准化工具，可以帮助您可视化所有借助Prometheus收集的指标。kube-Prometheus-stack的HelmChart已经为我们部署了Grafana。我们可以通过以下命令定位Grafana服务。GokubectlgetservicesNAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)prometheus-grafanaClusterIP10.104.143.14780/TCP通过下面的代码，我们可以将端口转发到这个服务上，在Grafanaweb界面上显示。gokubectlport-forwardsvc/prometheus-grafana3000:80Forwardingfrom127.0.0.1:3000->3000Forwardingfrom[::1]:3000->3000如下图，在浏览器中访问http://localhost:3000即可。输入默认用户名：admin和密码：prom-operator后，即可访问Grafanadashboard，如下图所示。点击Dashboard->Manage，可以看到kube-prometheus-stack提供的关于Kubernetes集群的所有dashboard：可以浏览到dashboard信息，如“Kubernetes/ComputeResources/Pod”：如上图的规范化仪表板是从kubernetes-mixin项目生成的。总结综上所述，我们讨论了什么是PrometheusOperator，如何借助PrometheusOperator和HelmChart轻松配置Prometheus，Prometheus如何通过监控发现资源，以及如何配置Prometheus的各种组件和运行机制。此外，我们探索了如何设置警报，以及如何将它们可视化。原标题：普罗米修斯权威指南：普罗米修斯算子作者：NinadDesai
