5月28日，在RIT ++ 2018
音乐节的一部分举行的
RootConf 2018大会上，“日志记录和监视”部分发布了“监视和Kubernetes”报告。 它讲述了使用Prometheus进行监视设置的经验，这是Flant通过在生产中运行数十个Kubernetes项目而获得的。
按照传统，我们很高兴为您提供一个
带有报告的
视频 （大约一个小时，
比文章
内容丰富
得多 ），并以文本形式进行主要压缩。 走吧
什么是监控？
有许多监视系统：
似乎要安装并安装其中一个-就是这样，问题已经解决了。 但是实践表明事实并非如此。 这就是为什么：
- 车速表显示速度 。 如果我们使用速度计每分钟测量一次速度，那么我们根据这些数据计算出的平均速度将与里程表数据不一致。 如果在汽车方面很明显，那么当涉及到服务器的许多很多指标时，我们常常会忘记它。
我们测量的内容以及实际旅行的方式 - 更多测量 。 我们获得的指标越多，问题的诊断就越准确……但前提是这些指标是真正有用的指标，而不仅仅是您设法收集的所有内容。
- 警报 。 发送警报没有什么复杂的。 但是，有两个典型的问题：a）错误警报的发生频率很高，以至于我们停止对任何警报进行响应，b）警报是在为时已晚（一切都已经爆炸）时发出的。 并实现在监控中没有出现这些问题是真正的艺术！
监视是三层结构，每一层都是至关重要的：
- 首先，这是一个系统，可让您预防事故 ， 通知事故 （如果无法预防）并快速诊断问题。
- 为此需要什么？ 准确的数据 ， 有用的图表 （查看它们并了解问题出在哪里）， 相关警报 （在正确的时间到达并包含明确的信息）。
- 为了使所有这些正常工作，需要一个监视系统 。
正确设置真正有效的监控系统并非易事，即使没有Kubernetes，也需要采取周到的方法来实施。 但是他的出现会怎样？
Kubernetes监控细节
1号 更大更快
Kubernetes发生了很大变化，因为基础架构变得越来越大，越来越快。 如果是早期的话，在普通的铁服务器上，它们的数量非常有限，并且添加过程非常漫长（花费数天或数周），那么在虚拟机中，实体的数量显着增加，将它们投入战斗的时间减少到几秒钟。
使用Kubernetes，实体的数量增加了一个数量级，实体的添加是完全自动化的（配置管理是必要的，因为没有描述就无法创建新的pod），整个基础架构变得非常动态（例如，每次删除和释放pod）再次创建）。
这有什么变化？
- 原则上，我们不再关注单个吊舱或容器-现在，我们仅对对象组感兴趣。
- 服务发现成为严格的强制性要求 ，因为“速度”已经如此，从原则上讲，我们不能像以前购买新服务器时那样手动启动/删除新实体。
- 数据量正在显着增长 。 如果以前是从服务器或虚拟机（现在是从Pod）收集的度量标准，则其数量要大得多。
- 我将最有趣的更改称为“ 元数据流 ”，下面将向您详细介绍。
我将从这个比较开始：
- 当您将孩子送入幼儿园时，将会给他一个个人邮箱，该邮箱将分配给他下一年（或更长时间），并在上面标明他的名字。
- 当您来到游泳池时，您的储物柜未签名，而是发给您一个“会话”。
因此，
经典的监视系统认为它们是幼儿园 ，而不是游泳池：它们假定监视对象是永久或长期存在的，并相应地给它们提供了储物柜。 但是Kubernetes的现实情况有所不同：一个豆荚来到游泳池（即被创建），在其中游泳（直到新的部署）然后离开（被破坏）-所有这些都快速且定期地发生。 因此，监视系统必须了解其监视的对象寿命短，并且必须能够在正确的时间完全忘记它。
2号 存在平行现实
另一个重要点-随着Kubernetes的出现，我们同时具有两个“现实”：
- Kubernetes世界中存在命名空间，部署，pod，容器。 这是一个复杂的世界，但它是逻辑的，结构化的。
- “物理”世界，由每个节点上的许多（实际上是堆）容器组成。
Kubernetes“虚拟现实”（上）和节点的物理世界（下）中的一个容器在监控过程中，我们需要不断
将容器的物理世界与Kubernetes的实际情况进行比较 。 例如，当我们查看某个名称空间时，我们想知道其所有容器（或其炉膛之一的容器）的位置。 否则，警报将变得不直观且难以使用-因为对于我们而言，了解警报所报告的对象非常重要。
不同类型的警报-后者比其他警报更直观，更方便工作这里
的结论是：
- 监视系统必须使用Kubernetes内置原语。
- 现实不止一个：炉床通常不会发生问题，而是特定节点会发生问题，我们需要不断了解它们所处的“现实”状态。
- 通常，在一个集群中，有几种环境（除了生产环境），这意味着必须考虑到这一点（例如，晚上不接收有关开发人员问题的警报）。
因此，我们有三个必要条件才能完成所有工作：
- 我们非常了解什么是监视。
- 我们知道它的功能，哪些功能随Kubernetes一起出现。
- 我们采用普罗米修斯。
因此，要真正解决问题，还需要付出
很多努力！ 顺便问一句，为什么是普罗米修斯？
普罗米修斯
有两种方法可以回答有关选择普罗米修斯的问题：
- 查看通常用于监视Kubernetes的人员和对象。
- 考虑其技术优势。
首先，我使用了来自The New Stack（来自
Kubernetes生态系统状态书）的调查数据，根据该数据，普罗米修斯至少比其他解决方案（包括开源和SaaS）更受欢迎，而且如果您看的话，它具有五倍的统计优势。
现在，让我们看看Prometheus是如何工作的，以及其功能如何与Kubernetes相结合并解决相关挑战。
普罗米修斯的结构如何？
Prometheus用Go编写，并作为单个二进制文件分发，其中所有内容都是内置的。 其操作的基本算法如下：
- 收集器读取目标表 ，即 要监视的对象及其轮询频率的列表（默认为60秒）。
- 之后，收集器向您需要的每个Pod发送HTTP请求，并接收带有一组度量标准的响应-可以有一百，一千，一万……每个度量标准都有一个名称，值和标签 。
- 接收到的响应存储在TSDB数据库中，在该数据库中，将接收到的响应的时间戳和从中获取响应的对象的标签添加到接收到的度量标准数据中。
简要介绍TSDBTSDB-Go上的时间序列数据库（用于时间序列的数据库），它使您可以存储指定天数的数据，并且非常有效（在大小，内存和输入/输出方面）。 数据仅在本地存储，而没有集群和复制，这是一个加号（它简单且有保证地起作用）和一个减号（不存在存储的水平扩展），但是在Prometheus分片的情况下，联合会做得很好-稍后会详细介绍。
- 该方案中提供的Service Discovery是Prometheus内置的服务发现引擎，可让您“从盒子”（通过Kubernetes API）接收数据以创建目标表。
这张桌子是什么样的？ 对于每个条目，它存储用于获取指标，调用次数和标签频率的URL。
标签用于将Kubernetes的“世界”与实体并置。 例如，要使用Redis查找吊舱，我们需要具有值名称空间，服务（由于特定情况下的技术特性而用于部署而不是部署）和实际吊舱。 因此，这3个标签存储在Redis指标的目标表条目中。
该表中的这些条目是基于Prometheus
scrape_configs在其中描述了监视对象）形成的：在
scrape_configs部分
scrape_configs定义了
scrape_configs ，该
scrape_configs指示要通过哪些标签搜索要监视的对象，如何过滤它们以及要记录的标签。
Kubernetes收集什么数据？
- 首先，Kubernetes中的向导非常复杂-监视其工作状态（kube-apiserver，kube-controller-manager，kube-scheduler，kube-etcd3 ...）非常重要，而且它已绑定到群集节点。
- 其次，重要的是要知道Kubernetes内部正在发生什么。
- kubelet-该Kubernetes组件在集群的每个节点上运行（并连接到K8s向导）； cAdvisor内置于其中（所有度量标准均按容器划分），并且它还存储有关连接的持久卷的信息；
- kube-state-metrics-实际上，这是Kubernetes API的Prometheus Exporter（它使您可以获取有关存储在Kubernetes中的对象的信息 ：吊舱，服务，部署等；例如，如果没有它，我们将不会知道容器或炉膛状态）;
- node-exporter-提供有关节点本身的信息，Linux系统上的基本指标（cpu，diskstats，meminfo 等 ）。
- 接下来是Kubernetes组件 ，例如kube-dns，kube-prometheus-operator和kube-prometheus，ingress-nginx-controller等。
- 下一类要监视的对象实际上是Kubernetes中启动的软件 。 这些是典型的服务器服务，例如nginx，php-fpm，Redis，MongoDB，RabbitMQ ...我们自己完成，因此当我们向服务中添加某些标签时，它将自动开始收集必要的数据，从而在Grafana中创建当前的仪表板。
- 最后，其他所有类别均为custom 。 通过Prometheus工具，您只需在服务描述中添加一个
prometheus-custom-target标签即可自动执行任意指标（例如，订单数量）的收集。
图表
接收到的数据
（如上所述）用于发送警报和创建图表。 我们使用
Grafana绘制图形。 其中一个重要的“细节”是
PromQL ，它是与Grafana完美集成的Prometheus查询语言。
对于大多数任务来说
，它非常简单和方便
（但是，例如，在其中加入联接已经很不方便
，但是您仍然必须这样做） 。 PromQL使您能够解决所有必要的任务：快速选择必要的指标，比较值，对其进行算术运算，分组，按时间间隔工作等等。 例如：
另外，Prometheus具有一个
Evaluator ，使用相同的PromQL可以以指定的频率访问TSDB。 怎么会这样 示例：根据可用指标，在过去5分钟内Web服务器上出现500错误的情况下，开始发送警报。 除了请求中的标签外，Evaluator还为警报数据添加了其他标签（根据我们的配置），然后以JSON格式将其发送到另一个Prometheus组件
Alertmanager 。
Prometheus定期（每30秒一次）将警报发送到Alertmanager，后者将对它们进行重复数据删除（在收到第一个警报后，它将发送警报，而下一个警报将不再发送）。
注意 ：我们不在家中使用Alertmanager，而是将数据从Prometheus直接发送到我们的服务员可以使用的系统中，但是在一般方案中这并不重要。Kubernetes上的Prometheus：大图
现在，让我们看看整个Prometheus捆绑包如何在Kubernetes中工作：
- Kubernetes具有自己的Prometheus名称空间（在插图中有
kube-prometheus ） 。 - 此名称空间使用Prometheus安装托管Pod，该安装每30秒从群集中通过服务发现接收的所有目标收集指标。
- 它还装有Alertmanager的容器，该容器从Prometheus接收数据并发送警报（到邮件，Slack，PagerDuty，微信，第三方集成等 ） 。
- Prometheus面临着负载平衡器（Kubernetes中的常规服务），而Grafana通过它访问Prometheus。 为了确保容错能力，Prometheus在Prometheus安装中使用了多个Pod，每个Pod都会收集所有数据并将其存储在TSDB中。 通过平衡器，Grafana击中其中之一。
- 带有Prometheus的吊舱数量由StatefulSet设置控制-我们通常不超过两个吊舱，但是您可以增加此数量。 类似地，通过StatefulSet，还部署了Alertmanager，至少要有3个Pod才能实现容错（因为需要法定人数来制定发送警报的决策）。
这里缺少什么？
普罗米修斯联邦
每30（或60）秒收集一次数据时，存储数据的地方很快就会结束，甚至更糟的是，它需要大量的计算资源（从TSDB接收和处理如此大量的点时）。 但是，我们希望能够存储并且能够以
较大的时间间隔下载信息。 如何实现呢？
在禁用服务发现的通用方案中再添加
一个Prometheus安装 （我们称之为
longterm ）就足够了，在该方案中禁用了服务发现，并且在目标表中只有一条通往主Prometheus（
main ）的静态记录。
多亏了联邦，这才有可能 ：Prometheus允许您在单个查询中返回所有指标的最新值。 因此，第一次安装Prometheus仍然可以对Kubernetes集群中的所有目标进行访问（每60秒，例如30秒访问一次），第二次安装-每5分钟从第一次接收一次数据并对其进行存储以能够长时间观看数据（但没有深入的细节）。
第二个Prometheus安装不需要服务发现，目标表将由一行组成
普罗米修斯装置有两种类型：主（顶部）和长期最后一点是
将Grafana连接到Prometheus安装并以特殊方式创建仪表板，以便您可以在数据源（
主要或
长期 ）之间切换。 为此，使用模板引擎，用变量
$prometheus代替所有面板中的数据源。
图中还有什么重要的？
组织图表时要考虑的两个关键点是对Kubernetes原语的支持以及从整体画面（或较低的“视图”）快速
向下钻取到特定服务的能力，反之亦然。
已经提到了对原语（命名空间，pod等）的支持-从原则上讲，这是在Kubernetes现实环境中进行舒适工作的必要条件。 这是有关向下钻取的示例：
- 我们查看了三个项目（即三个名称空间）的资源消耗图-我们看到CPU的主要部分（或内存，网络等）位于项目A上。
- 我们看相同的图，但是已经针对项目A的服务：哪个消耗了最多的CPU？
- 我们转到所需服务的图表上：“应归咎于”哪个豆荚？
- 我们来看一下所需容器的图表：哪个容器要“怪”？ 这是期望的目标！
总结
- 为自己准确说明什么是监视。 （让“三层馅饼”提醒您……以及即使没有Kubernetes，要进行有效烘焙也不容易！）
- 请记住，Kubernetes添加了强制性的细节：目标分组，服务发现，大量数据，元数据流。 此外：
- 是的，其中有些是在普罗米修斯神奇地（“开箱即用”）解决的；
- 但是，还有另一个部分需要独立和周到地监视。
请记住，
内容比系统更重要 ，即 正确的图表和警报是主要的，而不是Prometheus（或任何其他类似软件）。
影片和幻灯片
表演视频（大约一个小时）：
报告介绍：
聚苯乙烯
我们博客上的其他报告：
您可能也对以下出版物感兴趣：