使用Prometheus进行Kubernetes监控-最终指南（第1部分）

Prometheus监控正在迅速成为使用的Docker和Kubernetes监控工具之一。 本指南说明了如何使用Prometheus实施Kubernetes监视。 将介绍如何部署Prometheus服务器，指标导出器，设置kube-state指标，提取，抓取和收集指标，使用Alertmanager配置警报以及使用Grafana配置仪表板。 我们将介绍如何手动执行此操作，以及如何利用Prometheus operators自动部署/安装方法。

为什么使用Prometheus进行Kubernetes监控
因为两项技术的转变，因此我们需要一个新的监视框架：

DevOps文化：在DevOps出现之前，监视由主机，网络和服务组成。现在，开发人员需要能够轻松地将与应用程序和业务相关的指标集成为基础结构的有机组成部分的能力，因为他们更多地参与了CI / CD，并且可以自己进行很多操作调试。监控需要民主化，使其更易于访问，并覆盖堆栈的其他层。
容器和Kubernetes：基于容器的基础设施正在从根本上改变我们进行日志记录，调试，高可用性的方式……并且监视也不例外。现在，拥有大量的软件实体，服务，虚拟网络地址，突然出现或消失的公开指标。传统的监视工具并非能解决此问题。

为什么普罗米修斯是集装箱环境的正确工具

多维数据模型：该模型基于键值对，类似于Kubernetes本身如何使用标签组织基础架构元数据。它支持Prometheus查询语言，可提供灵活而准确的时间序列数据。
可访问的格式和协议：公开普罗米修斯度量标准是一项非常简单的任务。指标是人类可读的，格式不言自明，并使用标准HTTP传输方式发布。可以使用Web浏览器检查指标是否正确公开：

服务发现：Prometheus服务器负责定期抓取目标，以使应用程序和服务无需担心会发出数据（拉动指标，而不是推动指标）。 这些Prometheus服务器有几种自动发现抓取目标的方法，其中一些可以配置为过滤和匹配容器元数据，使其非常适合临时Kubernetes工作负载。
模块化且高度可用的组件：度量收集，警报，图形可视化等由不同的可组合服务执行。 所有这些服务都旨在支持冗余和分片。

Prometheus与其他Kubernetes监控工具的比较
Prometheus在2016年发布了1.0版，因此这是一项相当新的技术。 普罗米修斯（Prometheus）首次出现时，就有许多经过实践检验的监视工具。 Prometheus与其他资深监控项目相比如何？

键值与点分隔的尺寸：StatsD / Graphite等几种引擎使用显式的点分隔格式来表示尺寸，从而有效地为每个标签生成新的指标：

当尝试公开高维数据（每个度量标准包含许多不同的标签）时，此方法可能变得很麻烦。灵活的基于查询的聚合也变得更加困难。

假设有10台服务器，并且想按错误代码分组。使用键值，可以简单地按{http_code =“ 500”}将统一指标分组。使用点分隔的维度，将需要使用表达式进行汇总的大量独立指标。

事件记录与指标记录：InfluxDB / Kapacitor与Prometheus堆栈更相似。他们使用基于标签的维度和相同的数据压缩算法。但是，由于Influx具有纳秒级的时间分辨率和合并不同事件日志的能力，因此更适合事件日志记录。 Prometheus更适合于指标收集，并具有更强大的查询语言来检查它们。

黑盒与白盒监控：如前所述，Nagios / Icinga / Sensu之类的工具适用于主机/网络/服务监控，传统的sysadmin任务。例如，Nagios是基于主机的。如果想获取有关微服务状态的内部详细信息（又称白盒监控），则Prometheus是更合适的工具。

使用Prometheus进行微服务和Kubernetes监控的挑战
监视Kubernetes集群存在独特的独特挑战，需要部署一个可靠的监视/警报/图形架构来解决。

监视容器：可见性
容器是轻量级的，大多数情况下都是不变的黑匣子，这可能会带来监视方面的挑战……Kubernetes API和kube-state-metrics（本机使用prometheus度量标准）通过暴露Kubernetes内部数据（例如所需/正在运行的副本数）来解决了部分问题。在部署中，无法调度的节点等

Prometheus非常适合微服务，因为只需要公开指标端口即可，因此无需增加太多复杂性或运行其他服务。通常，服务本身已经提供了HTTP接口，而开发人员只需要添加其他路径（如/ metrics）即可。

在某些情况下，该服务尚未准备好提供Prometheus指标，因此无法修改代码以支持该指标。在这种情况下，需要部署与服务捆绑在一起的Prometheus导出器，通常将其作为同一pod的sidecar容器。

动态监控：不断变化的基础架构
如前所述，对于传统的，更加静态的监视系统而言，可以随时启动或停止报告的临时实体是一个问题。

普罗米修斯有几种自动发现机制来解决这一问题。与本指南最相关的是：

Consul：用于服务发现和配置的工具。 Consul是分布式的，高度可用的，并且具有极高的可伸缩性。

Kubernetes：Kubernetes SD配置允许从Kubernetes的REST API检索抓取目标，并始终与集群状态保持同步。

Prometheus Operator：基于熟悉的Kubernetes标签查询自动生成监视目标配置。稍后，我们将重点介绍此部署选项。

监控基础架构的新层：Kubernetes组件
使用Kubernetes的概念（例如物理主机或服务端口）变得无关紧要。需要围绕不同的分组组织监视，例如微服务性能（不同的Pod散布在多个节点上），名称空间，部署版本等。

结合使用Prometheus的基于标签的数据模型和PromQL，可以轻松地适应这些新范围。

使用Prometheus进行Kubernetes监控：架构概述
稍后我们将详细介绍，该图涵盖了我们要在Kubernetes集群中部署的基本实体：

1 – Prometheus服务器需要尽可能多的目标自动发现。
有几种方法可以实现此目的：
Consul
Prometheus Kubernetes SD插件
Prometheus  Operator及其自定义资源定义
2 –除了应用程序指标，我们还希望Prometheus收集与Kubernetes服务，节点和业务流程状态相关的指标。
节点导出器，用于与主机相关的经典指标：cpu，mem，network等。
业务流程和集群级别指标的Kube状态指标：部署，pod指标，资源预留等。
来自内部组件的Kube系统指标：kubelet，etcd，dns，调度程序等。
3 – Prometheus可以配置规则以使用PromQL触发警报，alertmanager将负责管理警报通知，分组，禁止等。
4 – Alertmanager组件将接收方，网关配置为传递警报通知。
5 – Grafana可以从任意数量的Prometheus服务器以及显示面板和仪表板中获取指标。

如何安装Prometheus
有多种方法可以在主机或Kubernetes集群中安装Prometheus：

直接作为单个二进制文件在主机上运行，适合于学习，测试和开发目的，但不适用于容器化部署。
作为Docker容器，它依次具有多个编排选项：
原始Docker容器，Kubernetes部署/ StatefulSet，Helm Kubernetes软件包管理器，Kubernetes运算符等。
让我们从更多的手动部署到更自动化的部署：

单个二进制文件-> Docker容器-> Kubernetes部署-> Prometheus运算符（第3章）

可以在主机中直接下载并运行Prometheus二进制文件：

这可能对Prometheus Web界面（默认为端口9090）产生第一印象。

更好的选择是将Prometheus服务器部署在容器内：

请注意，我们可以轻松地将此Docker容器调整为适当的Kubernetes部署对象，该对象将从ConfigMap挂载配置，公开服务，部署多个副本等

然后可以应用以下示例yaml：

如果不想配置LoadBalancer /外部IP，则可以始终为服务指定NodePort类型。

几秒钟后，应该可以看到集群中正在运行的Prometheus Pod：

此时，可以执行一些配置调整，例如配置pod antiaffinity以强制Prometheus服务器Pod位于不同的节点中。我们将在本指南的第四章介绍性能和高可用性方面。

一个更高级的自动化选项是使用Prometheus Operator，本指南第三章对此进行了介绍。可以将其视为元部署：一种可以管理其他部署并根据高级服务规范配置和更新它们的部署。我们将开始手动配置Prometheus堆栈，在下一章中，我们将使用Operator使Prometheus部署易于移植，声明式和灵活。

如何使用Prometheus监视Kubernetes服务
服务通过HTTP（S）公开了Prometheus度量标准，与其他类似的监视解决方案相比，此方法有几个优点：

无需安装服务代理，只需公开一个Web端口即可。 Prometheus服务器会定期抓取（拉出），因此不必担心推送指标或配置远程端点。
一些微服务已经使用HTTP来实现其常规功能，可以重用该内部Web服务器，而只需添加/ metrics之类的文件夹。
指标格式本身是人类可读的并且易于掌握。如果是微服务代码的维护者，则可以开始发布指标，而无需太多的复杂性或学习。
一些服务旨在从根本上公开Prometheus指标（Kubernetes kubelet，Traefik Web代理，Istio微服务网格等）。其他一些服务不是本地集成的，但是可以使用导出程序轻松进行调整。导出器是一项服务，它收集服务统计信息并将其“转换”为准备好要删除的Prometheus指标。本章中有两个示例。

让我们从最好的情况开始：正在部署的微服务已经提供了Prometheus endpoint。

Traefik是一个反向代理，旨在与微服务和容器紧密集成。 Traefik的一个常见用例是用作Ingress控制器或Entrypoint，即Internet和群集中特定微服务之间的桥梁。

我们可以使用多个选项来安装Traefik，以及特定于Kubernetes的安装指南。如果只想简单地部署带有Prometheus支持的Traefik并快速运行，请使用以下代码段：

Traefik运行后，可以显示服务IP：

可以使用curl来检查是否已公开Prometheus指标：

现在，需要将新目标添加到prometheus.yml conf文件中。

请注意到Prometheus会自动抓取自己：

让我们添加另一个静态端点：

如果服务位于其他名称空间中，则需要使用FQDN（即traefik.default.svc.cluster.local）

当然，这是最低配置，scrape配置支持多个参数。

仅举几例：

basic_auth和bearer_token：端点可能需要使用经典的登录/密码方案或请求标头中的承载令牌，通过HTTPS进行身份验证。
kubernetes_sd_configs或consul_sd_configs：不同的端点自动发现方法。
scrape_interval，scrap_limit，scrap_timeout：精度，弹性和系统负载之间的权衡取舍。
随着部署的Prometheus堆栈变得更加完整，我们将在下一章中使用其中一些。

修补ConfigMap和部署：

如果在Prometheus Web界面中访问/ targets URL，则应该看到Traefik端点UP：

使用主Web界面，我们可以找到一些traefik指标（由于在此示例中未配置任何Traefik前端或后端，因此很少使用traefik指标）并检索其值：

我们已经有一个关于Kubernetes的Prometheus工作示例！

如何使用Prometheus exporter监控Kubernetes服务使用Prometheus出口商监控应用
想在Kubernetes集群中部署的许多应用程序可能没有立即提供Prometheus指标。 在这种情况下，需要捆绑Prometheus导出器，这是一个附加的过程，该过程能够检索主服务的状态/日志/其他度量标准格式并将此信息公开为Prometheus度量标准。 换句话说，是Prometheus适配器。

可以使用以下命令部署包含Redis服务器和Prometheus sidecar容器的Pod：

如果显示redis pod，会发现其中有两个容器：

现在，只需要像上一节中一样更新Prometheus配置并重新加载即可：

要获取所有redis服务指标：

使用Prometheus和kube-state-metrics监视Kubernetes集群
除了监视集群中部署的服务之外，我们还希望监视Kubernetes集群本身。 集群监视要考虑的三个方面是：

Kubernetes主机（节点）–传统的系统管理员指标，例如cpu，负载，磁盘，内存等。
编排级别指标–部署状态，资源请求，调度和api服务器延迟等。
内部kube系统组件–调度程序，控制器管理器，dns服务等的详细服务指标。

监视Prometheus堆栈上的Kubernetes组件
Heapster：Heapster是监视和事件数据的整个集群范围的聚合器，在集群中作为Pod运行。

除了Kubelets / cAdvisor端点之外，还可以像kube-state-metrics一样将其他度量标准源附加到Heapster

Heapster现在已弃用，其替代物是metrics-server。

cAdvisor：cAdvisor是一个开源容器资源使用和性能分析代理。它是专门为容器而构建的，并且本身就支持Docker容器。在Kubernetes中，cAdvisor作为Kubelet二进制文件的一部分运行，任何检索节点本地和Docker指标的聚合器都将直接抓取Kubelet Prometheus端点。

Kube-state-metrics：kube-state-metrics是一项简单的服务，它侦听Kubernetes API服务器并生成有关对象状态（例如部署，节点和Pod）的度量。重要的是要注意kube-state-metrics只是一个指标终结点，其他实体需要抓取它并提供长期存储（即Prometheus服务器）。

Metrics-server：Metrics-server是资源使用情况数据的群集范围内的聚合器。它旨在作为默认的Heapster替代品。同样，指标服务器将仅显示最后的数据点，并且不负责长期存储。

Kube state度量标准专注于业务流程元数据：部署，窗格，副本状态等。
Metrics-server专注于实现资源指标API：CPU，文件描述符，内存，请求延迟等。
使用Prometheus监视Kubernetes节点
需要监视Kubernetes节点或主机，我们有很多工具可以监视Linux主机。在本指南中，我们将使用Prometheus node-exporter：

它由Prometheus项目本身托管
是下一章中使用Prometheus operator 时将自动部署的那个
可以作为DaemonSet部署，因此，如果在集群中添加或删除节点，它将自动扩展。
可以使用多种选项来部署此服务，例如，在此存储库中使用DamonSet：

或使用Helm / Tiller：

如果要使用Helm，请记住在继续之前为分till组件创建RBAC角色和服务帐户。

图表安装并运行后，可以显示需要抓取的服务：

一旦像上一节中一样添加了scrape配置，就可以开始收集和显示节点指标：

使用Prometheus监视kube-state-metrics
部署和监视kube-state-metrics也是一项非常简单的任务。 同样，可以像下面的示例一样直接部署或使用Helm图表。

创建一个指向kube-scheduler pod的服务：

现在将能够抓取端点：scheduler-service.kube-system.svc.cluster.local：10251

下一步是什么？
我们已经有一个具有6个目标端点的Prometheus部署：2个“最终用户”应用程序，3个Kubernetes集群端点和Prometheus本身。 此时，配置仍然简单稚，并且不是自动化的，但是我们拥有运行中的Prometheus基础架构。

下一章将介绍通常与Prometheus服务一起部署的其他组件。 我们将开始使用PromQL语言来汇总指标，触发警报并生成可视化仪表板。

原文：https://sysdig.com/blog/kubernetes-monitoring-prometheus/