要部署真正的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设计为水平缩放，实例可以与其对等方进行通信，从而提供最少的配置。我们将从一些基本概念开始，下一部分包含一个可以直接在集群中运行的实际例子。

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

groups:- name: etcd  rules:  - alert: NoLeader    expr: etcd_server_has_leader{job="kube-etcd"} == 0    for: 1m    labels:      severity: critical      k8s-component: etcd    annotations:      description: etcd member {{ $labels.instance }} has no leader      summary: etcd member has no leader

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

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

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

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

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

alerting:  alertmanagers:  - scheme: http    static_configs:    - targets:       - "alertmanager-service:9093"

从Prometheus服务器的角度来看，此配置只是一个静态名称，但是Kubernetes服务可以在后台执行不同的HA / LoadBalancing转发。AlertManager本身是一款复杂的软件，涵盖了以下基础知识：AlertManager根据标签和来源将不同的警报分组
这种分组和层次构成了“路由树”。决定要采取哪些动作的决策树。
例如，我们可以配置路由树，以便将每个带有标签k8s-cluster-component的警报发送到“ cluster-admin”邮件地址。
使用禁止规则，如果另一个警报正在触发，则可以禁止一个警报或一组警报。例如，如果集群关闭且完全无法访问，则没有必要通知集群所包含的各个微服务的状态。
警报可以转发到“接收者”，即电子邮件，PagerDuty，webhook等通知网关。
一个简单的AlertManager配置示例：

global:  resolve_timeout: 5mroute:  group_by: ['alertname']  group_wait: 10s  group_interval: 10s  repeat_interval: 1h  receiver: 'test'receivers:  - name: 'test'    webhook_configs:    - url: 'https://webhook.site/8ce276c4-40b5-4531-b4cf-5490d6ed83ae'

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

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

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

git clone git@github.com:mateobur/prometheus-monitoring-guide.gitcd prometheus-monitoring-guide/alertmanager-example/kubectl create cm prometheus-example-cm --from-file prometheus.ymlkubectl create cm prometheus-rules-general --from-file generalrules.yaml

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

kubectl create cm alertmanager-config --from-file alertmanager.ymlkubectl create -f prometheus-example.yamlkubectl create -f alertmanager-deployment.yaml

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

kubectl get podsNAME                                       READY     STATUS    RESTARTS   AGEalertmanager-deployment-78944d4bfc-rk2sg   1/1       Running   0          27sprometheus-deployment-784594c89f-fjbd6     1/1       Running   0          32sprometheus-deployment-784594c89f-gpvzf     1/1       Running   0          32s

此配置包括“ DeadManSwitch”，这是一个始终会触发的警报，旨在测试所有微服务Prometheus-> AlertManager-> Notification通道是否按预期工作：检查webhook URL，以JSON格式查找通知：

Grafana，使用Prometheus进行Kubernetes监控–仪表板
Grafana项目是的分析和监视平台。它不属于Prometheus，但已成为创建完整Prometheus解决方案的最受欢迎的附加组件之一。我们将使用Helm Kubernetes软件包管理器进行此部署，这将使我们能够使用一组可重复的ConfigMap配置Grafana，从而避免了任何手动的后配置：

helm install --name mygrafana stable/grafana --set sidecar.datasources.enabled=true --set sidecar.dashboards.enabled=true --set sidecar.datasources.label=grafana_datasource --set sidecar.dashboards.label=grafana_dashboard

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

kubectl get secret --namespace default mygrafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

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

kubectl port-forward mygrafana-859c68577f-4h6zp 3000:3000

如果要查看界面，请使用浏览器访问http：// localhost：3000

为了使Grafana有用，需要两种配置：

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

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

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

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

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

url: http://prometheus-example-service:9090

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

短暂(临时)工作程序的普罗米修斯指标– Push Gateway

并非每个程序都是连续运行的服务，可以期望在任何随机时间都将其废弃。每个IT部署都有大量一次性或计划任务，用于备份，清理，维护，测试等。我们可能想从这些任务中收集一些指标，但是Prometheus的目标/抓取模型肯定不会在这里起作用。

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

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

kubectl create -f prometheus-monitoring-guide/pushgateway/

转发Pushgateway Pod的服务端口：

kubectl port-forward pushgateway-deployment-66478477fb-gmsld 9091:9091

转发Pushgateway Pod的服务端口：

kubectl port-forward pushgateway-deployment-66478477fb-gmsld 9091:9091

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

echo "some_metric 3.14" | curl --data-binary @- http://localhost:9091/metrics/job/some_job

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

curl localhost:9091/metrics | grep some_metric# TYPE some_metric untypedsome_metric{instance="",job="some_job"} 3.14

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

Prometheus持久指标存储
Prometheus服务器默认将度量标准存储在本地文件夹中15天。还请记住，默认的本地Pod存储为临时存储，这意味着如果出于任何原因更换了Pod，则所有指标都将消失。任何准备就绪的生产部署都需要配置一个持久性存储接口，该接口将能够维护历史指标数据并在Pod重新启动后继续存在。同样，Kubernetes已经提供了可以实现此功能的抽象：PersistentVolume但是，正如我们刚刚讨论的那样，PersistentVolume只是数据量的抽象，因此需要一个提供实际量的硬件/软件堆栈。

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

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

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

kubectl delete -f prometheus-monitoring-guide/alertmanager-example/prometheus-example.yamlkubectl create -f prometheus-monitoring-guide/storage/prometheus-example.yaml

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

kubectl get pvNAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                                                   STORAGECLASS   REASON    AGEpvc-b5a4aaa1-9584-11e8-97c9-42010a800278   50Gi       RWO            Delete           Bound     default/prometheus-metrics-db-prometheus-deployment-0   standard                 4hpvc-f4ee61e4-9584-11e8-97c9-42010a800278   50Gi       RWO            Delete           Bound     default/prometheus-metrics-db-prometheus-deployment-1   standard                 4h

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

API对象类型：

kind: StatefulSet

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

volumeClaimTemplates:  - metadata:      name: prometheus-metrics-db    spec:      accessModes:      - ReadWriteOnce      resources:        requests:          storage: 50Gi

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

containers:      - args:        - --storage.tsdb.path=/data        - --storage.tsdb.retention=400d

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

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

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

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

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