Prometheus监控主机和容器

监控主机和容器

首先，我们将在每台主机上安装exporter，然后配置节点和Docker指标让Prometheus来抓取。 接下来，我们将介绍一些基本主机资源监控，包括：

• CPU
• 内存
• 磁盘
• 可用性 为了确定要监控的内容，我们将回顾USE监控方法，以帮助确定正确的监控指标。我们还将介绍如何使用Prometheus来检测服务状态以及主机可用性。 然后，我们利用收集的指标来构建一些聚合指标并保存为记录规则。 最后，我们会简要介绍Grafana，并对收集的数据进行基本的可视化。

上述内容都是部署监控工具的标准任务，为深入理解Prometheus提供了坚实的基础。这些基本数据让我们能够识别主机的性能问题，它们为应用程序问题的故障诊断提供足够的数据补充。

监控节点

Prometheus使用exporter工具来暴露主机和应用程序上的指标，目前有很多可用于各种目的的exporter。现在我们将专注于一个特定的exporter：Node Exporter。它是用Go语言编写的，提供了一个可用于收集各种主机指标数据（包括CPU、内存和磁盘）的库。它还有一个textfile收集器，允许你导出静态指标，我们很快就会看到这对发送有关节点的信息很有帮助，此外它还可以从批处理作业导出指标。

首先选择其中一台Linux主机，然后下载并安装Node Exporter。

安装Node Exporter

你可以通过tar包来安装Node Exporter，在部分操作系统上也可以通过软件包进行安装。可以从Prometheus官网下载Node Exporter的tar包。

下载并解压缩Node Exporter，然后将二进制文件移动到环境变量path包含的路径中。

配置Node Exporter

标签

标签提供了时间序列的维度。它们可以定义目标，并为时间序列提供上下文。但最重要的是，结合指标名称，它们构成了时间序列的标识，如果它们改变了，那么时间序列的标识也会跟着改变。

更改或添加标签会创建新的时间序列。这意味着应该明智地使用标签并尽可能保持不变。如果不遵守这一规定，则可能产生新的时间序列，从而创建出一个动态的数据环境，使监控的数据源难以跟踪。想象一下，你有一个时间序列，用于跟踪服务的状态。你为该时间系列配置了一个警报，该警报依赖于指标的标签来评判。如果更改或添加标签，那么警报将变为无效。这同样适用于历史时间序列数据：更改或添加标签，我们会丢失先前时间序列的跟踪，破坏已有的图像和表达式，并可能导致混乱。

如果不再写入新数据，那么历史时间序列会发生什么？对于先前存在数据的时间序列，如果抓取不再返回数据，则该系列将被标记为陈旧。这同样适用于任何被删除的目标：所有时间序列都将标记为陈旧。图像中不会显示陈旧的数据。

标签分类

那么，何时应该添加标签以及应该添加哪些标签呢？好吧，就像所有优秀的监控架构那样，这值得构建一个分类法。与大多数监控分类法一样，在分层更加广泛时标签可能表现最好。一个设定分类标准的好办法是利用拓扑标签和模式标签。

拓扑标签（topological label）通过其物理或逻辑组成来切割服务组件，例如我们在上面看到的datacenter标签。每个指标都天然带有两个拓扑标签：job和instance。标签job是根据抓取配置中的作业名称设置的。我们倾向于使用job来描述正在监控的事物的类型。在之前的Node Exporter作业中，我们将其命名为node。这会为每个Node Exporter指标打上job标签node。instance标签可以标识目标，它通常是目标的IP地址和端口，并且来自__address__标签。

模式标签（schematic label）是url、error_code或user之类的东西，它们允许你将拓扑中同一级别的时间序列匹配在一起，例如创建数据间的比率。

重新标记

既然我们已经精心设计了标签，为什么还需要重新标记（relabel）呢？用一个词来回答就是：控制。在一个集中的复杂监控环境中，有时你无法控制监控的所有资源以及所有暴露的监控数据。通过重新标记，你可以控制、管理并标准化环境中的指标。一些最常见的用例是：

• 删除不必要的指标。
• 从指标中删除敏感或不需要的标签。
• 添加、编辑或修改指标的标签值或标签格式。 请记住，我们有两个阶段可以重新标记。 第一个阶段是对来自服务发现的目标进行重新标记，这对于将来自服务发现的元数据标签中的信息应用于指标上的标签来说非常有用。这是在作业内的relabel_configs块中完成的。 第二个阶段是在抓取之后且指标被保存于存储系统之前。这样，我们就可以确定哪些指标需要保存、哪些需要丢弃以及这些指标的样式。这是在我们作业内的metric_relabel_configs块中完成的。