尽管第一方出口商很好地涵盖了基础知识，但 Prometheus 生态系统提供了各种各样的第三方出口商，涵盖了所有其他方面。在本章中，我们将介绍一些可用的最有用的导出器——来自操作系统（OS）指标和Internet 控制消息协议 (ICMP) 探索从日志中生成指标，或如何从短期进程（例如批处理作业）中收集信息。

简而言之，本章将涵盖以下主题：

• Test environments for this chapter
• Operating system exporter
• Container exporter
• From logs to metrics
• Blackbox monitoring
• Pushing metrics
• More exporters

在本章中，我们将使用两种测试环境：一种基于模拟传统静态基础架构的虚拟机（VM），另一种基于 Kubernetes 用于现代工作流程。以下主题将指导您完成它们的自动设置过程，但会掩盖每个导出器的详细信息 - 这些将在各自的部分中进行深入解释。

此方法将抽象所有部署和配置细节，允许您使用几个命令拥有一个完全配置的测试环境。您仍然可以连接到每个来宾实例并修改示例配置。

要启动一个新的测试环境，请进入本章路径，相对于存储库根目录：

cd ./chapter06/

确保没有其他测试环境正在运行并启动本章的环境：

vagrant global-status
vagrant up

您可以使用以下方法验证测试环境的成功部署：

vagrant status

这将输出以下内容：

Current machine states:

prometheus                running (virtualbox)
target01                  running (virtualbox)

This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.

最终结果将是如下图所示的环境：

要连接到 target01 实例，只需运行以下命令：

vagrant ssh target01

要连接到 Prometheus 实例，请使用以下代码片段：

vagrant ssh prometheus

完成此环境后，进入本章路径，相对于存储库根目录，如下所示：

cd ./chapter06/

并执行以下指令：

vagrant destroy -f

要启动 Kubernetes 测试环境，我们首先必须确保没有运行 minikube 的实例，如下所示：

minikube status
minikube delete

使用以下规范启动一个新的 minikube 实例：

minikube start \
  --cpus=2 \
  --memory=3072 \
  --kubernetes-version="v1.14.0" \
  --vm-driver=virtualbox

上一条命令完成后，应该可以使用新的 Kubernetes 环境。

对于我们的 Kubernetes 测试环境，我们将基于 第 5 章，运行 Prometheus 服务器，并在我们的工作流程中使用 Prometheus Operator。由于我们已经介绍了 Prometheus Operator 设置，因此我们将部署所有必需的组件，而无需逐一介绍。

步入以下章节编号：

cd ./chapter06/

部署 Prometheus Operator 并验证成功部署如下：

kubectl apply -f ./provision/kubernetes/operator/bootstrap/

kubectl rollout status deployment/prometheus-operator -n monitoring

使用 Prometheus Operator 部署 Prometheus 并确保部署成功，如下所示：

kubectl apply -f ./provision/kubernetes/operator/deploy/

kubectl rollout status statefulset/prometheus-k8s -n monitoring

如以下代码所示添加 ServiceMonitors，它将配置 Prometheus 作业：

kubectl apply -f ./provision/kubernetes/operator/monitor/

kubectl get servicemonitors --all-namespaces

片刻之后，您应该可以使用并准备好 Prometheus；以下指令将提供其 Web 界面：

minikube service prometheus-service -n monitoring

您可以使用以下指令为 Prometheus 验证 Kubernetes StatefulSet，这将打开 Kubernetes 仪表板：

minikube dashboard

以下屏幕截图说明了 Prometheus StatefulSet 的正确部署：

在监控基础架构时，最常见的起点是操作系统级别。 CPU、内存和存储设备等资源的指标以及内核操作计数器和统计数据为评估系统性能特征提供了宝贵的洞察力。为了让 Prometheus 服务器收集这些类型的指标，目标主机上需要一个操作系统级别的导出器，以便在 HTTP 端点中公开它们。 Prometheus 项目提供了这样一个支持类 Unix 系统的导出器，称为 Node Exporter，社区还为 Microsoft Windows 系统维护了一个等效的导出器，称为 WMI 导出器。

节点导出器是最著名的 Prometheus 导出器，这是有充分理由的。它为操作系统的不同区域提供了 40 多个收集器，以及一种公开 cron 作业的本地指标和有关主机的静态信息的方法。与 Prometheus 生态系统的其他部分一样，Node Exporter 具有合理的默认配置和一些智能来识别可以收集的内容，因此无需太多调整即可运行它是完全合理的。

尽管此导出器设计为以非特权用户身份运行，但它确实需要访问内核和进程统计信息，这些在容器内运行时通常不可用。这并不是说它不能在容器中工作——每个 Prometheus 组件都可以在容器中运行——但它需要额外的配置才能工作。因此，建议尽可能将 Node Exporter 作为系统守护程序直接在主机上运行。

Node Exporter 收集器可能会根据正在运行的系统收集不同的指标，因为操作系统内核在它们公开内部状态的方式以及它们提供哪些细节方面会有所不同。例如，node_exporter 在 macOS 上公开的指标将与 Linux 上的指标有很大不同。这意味着，即使 Node Exporter 支持 Linux、Darwin (macOS)、FreeBSD、OpenBSD、NetBSD、DragonFly BSD 和 Solaris，Node Exporter 中的每个收集器都会有自己的兼容性矩阵，Linux 是支持最多的内核。

按照设计，此导出器仅生成有关进程的聚合指标（例如正在运行的数量等），而不是每个进程的单个指标。在 Prometheus 模型中，每个相关过程都需要公开自己的指标，或者有一个配套的导出器来为它完成这项工作。这就是为什么在大多数情况下不建议在没有明确白名单的情况下运行通用流程导出器的原因之一。

Prometheus 生态系统中的出口商通常从给定流程中收集一组特定的指标。 Node Exporter 与大多数其他导出器不同，因为机器级指标跨越了广泛的子系统，因此它被设计为提供单独的收集器，可以根据检测需求打开和关闭.启用默认关闭的收集器可以通过 --collector. 标志集来完成；启用的收集器可以通过使用 --no-collector. 标志变体来禁用。

从默认启​​用的所有收集器中，由于其有用性以及需要配置以使其正常工作，因此需要从中挑选出一个。 textfile 收集器通过查看具有 .prom 扩展名且包含 Prometheus 展示格式的度量的文件的目录来启用自定义度量的展示。 --collector.textfile.directory 标志默认为空，因此需要设置为收集器执行其工作的目录路径。预计仅通过此方法导出特定于实例的指标，例如：

• Local cron jobs can report their exit status through a metric (finish timestamp is not useful to record, as the metrics file modification timestamp is already exported as a metric)
• Informational metrics (that only exist for the labels they provide), such as VM flavor, size, or assigned role
• How many package upgrades are pending, if a restart is required
• Anything else not covered by the built-in collectors

本章的静态基础设施测试环境应该已经启动并通过自动配置运行了 node_exporter。不过，我们可以通过连接到例如 target01 VM 来检查它，如下所示：

cd ./chapter06/
vagrant ssh target01

然后检查提供的 systemd 单元文件的配置，如下所示：

vagrant@target01:~$ systemctl cat node-exporter

在这个片段中，我们可以看到设置了 textfile 收集器目录，以便可以导出自定义指标：

...
ExecStart=/usr/bin/node_exporter --collector.textfile.directory=/var/lib/node_exporter
...

让我们尝试创建一个自定义指标。为此，我们只需将指标写入 textfile 收集器目录中的文件，扩展名为 .prom，如下所示：

vagrant@target01:~$ echo test_metric 1 | sudo tee /var/lib/node_exporter/test.prom

然后我们可以请求 /metrics 端点并搜索我们的测试指标，如下所示：

vagrant@target01:~$ curl -qs 0:9100/metrics | grep test_metric

输出应该类似于以下内容：

# HELP test_metric Metric read from /var/lib/node_exporter/test.prom
# TYPE test_metric untyped
test_metric 1

此导出器会生成大量指标，具体取决于启用的收集器。 node_exporter 提供的一些更有趣的指标如下：

• node_cpu_seconds_total, which provides the number of seconds cumulatively used per core for all the available CPU modes, is very useful for understanding the CPU utilization
• node_memory_MemTotal_bytes and node_memory_MemAvailable_bytes, which allow calculating the ratio of memory available
• node_filesystem_size_bytes and node_filesystem_avail_bytes, which enable the calculation of filesystem utilization
• node_textfile_scrape_error, which tells you if the textfile collector couldn't parse any of the metrics files in the textfile directory (when this collector is enabled)

在不断追求工作负载隔离和资源优化的过程中，我们见证了使用虚拟机管理程序从物理机到虚拟机的转变。使用虚拟化意味着一定程度的资源使用效率低下，因为无论是否使用它们，都需要将存储、CPU 和内存分配给每个正在运行的 VM。在这方面已经做了很多工作来缓解这种低效率，但最终，充分利用系统资源仍然是一个难题。

随着 Linux 上操作系统级虚拟化的兴起（即容器的使用），思维方式发生了变化。我们不再需要每个工作负载的完整操作系统副本，而是只需要适当隔离的进程来完成所需的工作。为了实现这一点，并专门针对 Linux 容器，提供了一组负责隔离硬件资源（命名为 cgroup 或控制组）和内核资源（命名空间）的内核特性。 cgroups管理的资源如下：

• CPU
• Memory
• Disk I/O
• Network

这些内核功能允许用户对给定工作负载可用的资源进行精细控制，从而优化资源使用。 Cgroups 指标对于任何现代监控系统都是无价的。

Container Advisor (cAdvisor) 是 Google 开发的一个项目，用于收集、聚合、分析和公开来自运行容器的数据。可用数据几乎涵盖了您可能需要的任何内容，从内存限制到 GPU 指标，所有可用数据均按容器和/或主机隔离。

cAdvisor 不绑定到 Docker 容器，但它通常作为一个容器进行部署。数据是从容器守护进程和 Linux cgroups 收集的，使容器的发现变得透明且完全自动化。它还会在达到这些限制时公开进程限制和限制事件，这是需要密切关注的重要信息，以最大限度地利用基础设施资源而不会对工作负载产生负面影响。

除了以 Prometheus 格式公开指标外，cAdvisor 还附带一个有用的 Web 界面，允许即时可视化主机及其容器的状态。

将 cAdvisor 作为容器启动时，一些主机路径需要在只读模式下可用。例如，这将允许收集内核、进程和容器数据。

有很多运行时标志，因此我们将在下表中列出一些与我们的测试用例最相关的标志：

尽管历史上 cAdvisor 代码嵌入在 Kubelet 二进制文件中，但目前计划在那里弃用。因此，我们将启动 cAdvisor 作为 DaemonSet 来验证这个示例并公开它的配置，同时也启用它的 web 界面，作为 Kubernetes 服务，以供探索。

确保您移动到正确的存储库路径，如下所示：

cd ./chapter06/provision/kubernetes/

接下来，我们必须创建一个 DaemonSet，因为我们希望 cAdvisor 在每个节点上运行：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cadvisor
  namespace: monitoring
...

请注意所有允许从 Docker 守护程序和各种 Linux 资源收集数据的卷安装，如下所示：

...
    spec:
     containers:
      - name: cadvisor
        volumeMounts:
        - {name: rootfs, mountPath: /rootfs, readOnly: true}
        - {name: var-run, mountPath: /var/run, readOnly: true}
        - {name: sys, mountPath: /sys, readOnly: true}
        - {name: docker, mountPath: /var/lib/docker, readOnly: true}
        - {name: disk, mountPath: /dev/disk, readOnly: true}
...

使用以下指令应用之前的清单：

kubectl apply -f ./cadvisor/cadvisor-daemonset.yaml

我们可以使用以下命令跟踪部署状态：

kubectl rollout status daemonset/cadvisor -n monitoring

部署完成后，就该添加新服务了。注意将在 ServiceMonitor 中使用的端口名称。这是我们将使用的清单：

apiVersion: v1
kind: Service
metadata:
  labels:
    p8s-app: cadvisor
  name: cadvisor-service
  namespace: monitoring
spec:
  selector:
    p8s-app: cadvisor
  type: NodePort
  ports:
  - {name: http, protocol: TCP, port: 8080, targetPort: http}

可以使用以下方式应用清单：

kubectl apply -f ./cadvisor/cadvisor-service.yaml

我们现在可以使用以下指令连接到 cAdvisor Web 界面：

minikube service cadvisor-service -n monitoring

这将打开一个浏览器窗口，其界面类似于下图：

是时候将 cAdvisor 导出器添加为 Prometheus 的新目标了。为此，我们将使用下一个 ServiceMonitor 清单，如下所示：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    p8s-app: cadvisor
  name: cadvisor-metrics
  namespace: monitoring
spec:
  endpoints:
  - interval: 30s
    port: http
  selector:
    matchLabels:
      p8s-app: cadvisor

可以使用以下方式应用以前的清单：

kubectl apply -f ./cadvisor/cadvisor-servicemonitor.yaml

片刻之后，您可以在 Prometheus Web 界面中检查新添加的目标，使用以下指令打开其 Web 界面：

minikube service prometheus-service -n monitoring

下图说明了显示 cAdvisor 目标的 Prometheus /targets 端点：

有了这个，我们现在有了容器级别的指标。请注意，cAdvisor 每个容器会导出大量样本，这可以轻松地将导出的指标膨胀到每次抓取的数千个样本，这可能会导致抓取 Prometheus 上与基数相关的问题。

从 cAdvisor 导出的数千个指标中，这些指标通常对于留意问题很有用：

• container_last_seen, which keeps track of the timestamp the container was last seen as running
• container_cpu_usage_seconds_total, which gives you a counter of the number of CPU seconds per core each container has used
• container_memory_usage_bytes and container_memory_working_set_bytes, which keep track of container memory usage (including cache and buffers) and just container active memory, respectively
• container_network_receive_bytes_total and container_network_transmit_bytes_total, which let you know how much traffic in the container receiving and transmitting, respectively

在 Kubernetes 上运行时，cAdvisor 不会让您深入了解集群的运行方式——来自 Kubernetes 本身的应用程序级指标。为此，我们需要另一个导出器：kube-state-metrics。

kube-state-metrics 不导出容器级数据，因为这不是它的功能。它在更高级别上运行，公开 Kubernetes 状态，提供有关 API 内部对象（如 pod、服务或部署）的指标。使用此导出器时当前可用的对象度量组如下：

• CronJob metrics
• DaemonSet metrics
• Deployment metrics
• Job metrics
• LimitRange metrics
• Node metrics
• PersistentVolume metrics
• PersistentVolumeClaim metrics
• Pod metrics
• Pod Disruption Budget metrics
• ReplicaSet metrics
• ReplicationController metrics
• Resource quota metrics
• Service metrics
• StatefulSet metrics
• Namespace metrics
• Horizontal Pod Autoscaler metrics
• Endpoint metrics
• Secret metrics
• ConfigMap metrics

kube-state-metrics 暴露了两个端点：一个提供 API 对象指标，另一个提供导出器本身的内部指标。

在配置 kube-state-metrics 时，除了所有必需的 RBAC 权限外，还需要注意几个运行时标志。我们将在下表中提供与我们的测试用例更相关的概述：

我们将在之前启动的 Kubernetes 测试环境的基础上进行构建。要开始部署，请确保您移动到相对于存储库根目录的正确存储库路径，如下所示：

cd ./chapter06/provision/kubernetes/

由于需要访问 Kubernetes API，因此此部署的基于角色的访问控制 (RBAC) 配置非常广泛，其中包括 Role、RoleBinding、ClusterRole 、一个 ClusterRoleBinding 和一个 ServiceAccount。此清单位于 ./kube-state-metrics/kube-state-metrics-rbac.yaml。

应使用以下命令应用它：

kubectl apply -f ./kube-state-metrics/kube-state-metrics-rbac.yaml

我们将只使用一个实例为 kube-state-metrics 创建部署，因为在这种情况下，不需要集群或特殊部署要求：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-state-metrics
  namespace: monitoring 
spec:
  selector:
    matchLabels:
      k8s-app: kube-state-metrics
  replicas: 1
...

此部署将运行 kube-state-metrics 导出器的实例，以及 addon-resizer 以动态扩展导出器：

...
  template:
    spec:
      serviceAccountName: kube-state-metrics
      containers:
      - name: kube-state-metrics
...
      - name: addon-resizer
...

这可以使用以下指令应用：

kubectl apply -f ./kube-state-metrics/kube-state-metrics-deployment.yaml

我们可以使用以下命令跟踪部署状态：

kubectl rollout status deployment/kube-state-metrics -n monitoring

成功部署后，我们将为这个导出器创建一个服务，这次有两个端口：一个用于 Kubernetes API 对象指标，另一个用于导出器的内部指标本身：

apiVersion: v1
kind: Service
metadata:
  name: kube-state-metrics
  namespace: monitoring
  labels:
    k8s-app: kube-state-metrics
  annotations:
    prometheus.io/scrape: 'true'
spec:
  type: NodePort
  ports:
  - {name: http-metrics, port: 8080, targetPort: http-metrics, protocol: TCP}
  - {name: telemetry, port: 8081, targetPort: telemetry, protocol: TCP}
  selector:
    k8s-app: kube-state-metrics

之前的清单可以应用如下：

kubectl apply -f ./kube-state-metrics/kube-state-metrics-service.yaml

服务到位后，我们可以使用以下命令验证两个指标端点：

minikube service kube-state-metrics -n monitoring

这将打开两个不同的浏览器选项卡，一个用于每个指标端点：

最后，是时候配置 Prometheus 以使用 ServiceMonitor 清单来抓取两个端点，如下所示：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    k8s-app: kube-state-metrics
  name: kube-state-metrics
  namespace: monitoring
spec:
  endpoints:
  - interval: 30s
    port: http-metrics
  - interval: 30s
    port: telemetry
  selector:
    matchLabels:
      k8s-app: kube-state-metrics

现在可以使用以下命令应用它：

kubectl apply -f ./kube-state-metrics/kube-state-metrics-servicemonitor.yaml

我们现在可以验证 Prometheus 中抓取目标的正确配置，使用以下指令打开其 Web 界面：

minikube service prometheus-service -n monitoring

来自 kube-state-metrics 的一些有趣的指标可以用来监控你的 Kubernetes 集群：

• kube_pod_container_status_restarts_total, which can tell you if a given pod is restarting on a loop;
• kube_pod_status_phase, which can be used to alert on pods that are in a non-ready state for a long time;
• Comparing kube_<object>_status_observed_generation with kube_<object>_metadata_generation can give you a sense when a given object has failed but hasn't been rolled back

在一个完美的世界里，所有的应用程序和服务都会被正确地检测，我们只需要收集指标来获得可见性。外部导出器是一种权宜之计，可以简化我们的工作，但并非每个服务都通过简洁的 API 公开其内部状态。较旧的守护程序软件，例如 Postfix 或 ntpd，利用日志记录来传递其内部工作。对于这些情况，我们有两个选择：要么自己检测服务（这对于闭源软件来说是不可能的），要么依靠日志来收集我们需要的指标。下一个主题将介绍从日志中提取指标的可用选项。

由 Google 开发的 mtail 是一个非常轻量级的日志处理器，能够运行具有模式匹配逻辑的程序，允许从所述日志中提取指标。它支持多种导出格式，例如 Prometheus、StatsD、Graphite 等。

除了 /metrics 端点之外，mtail 服务的 / 端点还公开了有价值的调试信息。此端点在 http://192.168.42.11:9197 的静态基础设施测试环境中可用：

要配置 mtail，我们需要一个具有模式匹配逻辑的程序。让我们看一下官方存储库中提供的一个非常简单的示例：

# simple line counter
counter line_count
/$/ {
  line_count++
}

该程序定义了 counter 类型的 line_count 度量，一个与行尾匹配的 RE2 兼容表达式 /$/，最后， { } 之间的动作，在这种情况下，增加 line_count 计数器。

要运行这个程序，我们只需要使用命令行标志启动 mtail 以将其指向我们的程序和我们想要监控的日志。以下是我们测试用例的一些最有用的标志：

在我们的静态基础设施测试环境中，我们可以通过连接到 target01 实例来验证 mtail 的配置，如下所示：

cd ./chapter06/

vagrant ssh target01

然后检查提供的 systemd 单元文件的配置，如以下命令所示：

vagrant@target01:~$ systemctl cat mtail-exporter

在本例中，mtail 正在计算 syslog 文件的行数，因此它需要具有访问系统日志的适当权限，因此，我们运行 mtail 守护程序与 Group=adm 来完成这项工作。我们可以在单元文件的以下片段中看到 mtail 服务所需的所有参数，包括行数程序的路径：

...
Group=adm
ExecStart=/usr/bin/mtail -address 0.0.0.0 -port 9197 -progs /etc/mtail_exporter/line_count.mtail -logs /var/log/syslog
...

在 Prometheus 实例上，我们添加了以下作业：

  - job_name: 'mtail'
    scrape_interval: 15s
    scrape_timeout: 5s
    static_configs:
      - targets: ['target01:9197']

使用 Prometheus 表达式浏览器（可在 http://192.168.42.10:9090 获得），我们不仅可以通过 up 指标验证抓取是否成功，而且我们的指标也可用：

来自 mtail 的一些有趣的指标可以用来关注这个出口商：

• mtail_log_watcher_error_count, which counts the number of errors received from fsnotify (kernel-based notification system for filesystem events)
• mtail_vm_line_processing_duration_milliseconds_bucket, a histogram which provides the line processing duration distribution in milliseconds per mtail program

与 mtail 类似，grok_exporter 解析非结构化日志数据并从中生成指标。但是，顾名思义，主要区别在于此导出器的特定领域语言是在 Logstash 模式语言 (Grok) 之后建模的，它可以重用您可能已经构建的模式。

此导出器需要 configuration 文件进行设置。配置中有五个主要部分，我们可以从部署在我们的静态基础设施测试环境中的导出器配置文件的以下片段中剖析这些部分。 global 部分设置配置格式版本。版本 2 目前是标准配置版本，所以我们在这里设置：

global:
    config_version: 2

输入部分定义要解析的日志的位置。如果readall设置为true，文件会在等待换行前被完全解析；正如我们所看到的，在我们的示例中我们没有这样做：

input:
    type: file
    path: /var/log/syslog
    readall: false

grok 部分加载用于解析的模式。这些配置在单独的位置，如下所示：

grok:
    patterns_dir: /etc/grok_exporter/patterns

metrics 部分是魔法发生的地方。它定义了从解析的日志中提取哪些指标。此导出器原生支持每种 Prometheus 指标类型。每个 type 的配置可能略有不同，因此您应该查看其文档。但是，我们将概述其中常见的配置：

• The match configuration defines the regular expression for data extraction; in our example, LOGLEVEL is a predefined pattern to match log levels.
• The labels configuration is able to use Go's templating syntax to output whatever was extracted from the match definition; in this case, we used level as our variable in the match pattern and so it is available as .level in the template:

metrics:
    - type: counter
      name: grok_loglevel_example_total
      help: Total log level events triggered.
      match: '.*\(echo %{LOGLEVEL:level}\)$' 
      labels:
          level: '{{.level}}'

最后，server 部分是定义导出器的绑定地址和端口的地方：

server:
    host: 0.0.0.0
    port: 9144

现在我们对配置文件中的内容有了更好的理解，是时候在我们的测试环境中尝试这个导出器了。

在我们的静态基础设施测试环境中，我们可以通过连接到 target01 实例来验证 grok_exporter 的配置，如下所示：

cd ./chapter06/

vagrant ssh target01

输出提供的 systemd 单元文件的配置如以下代码片段所示：

vagrant@target01:~$ systemctl cat grok-exporter

与 mtail 导出器一样，我们需要使用 Group=adm 运行 grok_exporter 以便它可以访问 syslog 无需以特权用户身份运行。我们可以在单元文件的以下代码段中看到 grok_exporter 服务所需的所有参数，包括前面提到的配置文件的路径：

...
Group=adm
ExecStart=/usr/bin/grok_exporter -config /etc/grok_exporter/config.yml
...

在 Prometheus 实例上，我们添加了以下作业：

  - job_name: 'grok'
    scrape_interval: 15s
    scrape_timeout: 5s
    static_configs:
      - targets: ['target01:9144']

使用 http://192.168.42.10:9090 上的 Prometheus 表达式浏览器，我们不仅可以验证抓取是否成功，还可以验证我们的指标是否可用：

来自 grok_exporter 的一些有趣的指标可以用来关注这个导出器：

• grok_exporter_line_buffer_peak_load, a summary which provides the number of lines that are read from the log file and waiting to be processed
• grok_exporter_line_processing_errors_total, which exposes the total number of processing errors for each defined metric

自省对于收集有关系统的数据非常宝贵，但有时我们需要从该系统用户的角度进行测量。在这种情况下，探测是模拟用户交互的好选择。由于从外部进行探测并且不了解系统的内部工作原理，因此这被归类为黑盒监控，如 第 1 章，监控基础。

blackbox_exporter 是 Prometheus 生态系统中所有当前可用的导出器中最奇特的之一。它的使用模式很巧妙，通常新手都会对此感到困惑。我们将深入研究这个出口商，希望尽可能简单地使用它。

blackbox_exporter 服务公开了两个主要端点：

• /metrics: Where its own metrics are exposed
• /probe: It is the query endpoint that enables blackbox probes, returning their results in Prometheus exposition format

除了前面的两个端点，服务的 / 还提供有价值的信息，包括执行的探测的日志。此端点在 http://192.168.42.11:9115 的静态基础设施测试环境中可用。

blackbox exporter 支持通过各种本机协议探测端点，例如 TCP、ICMP、DNS、HTTP（版本 1 和 2），以及大多数探测上的 TLS。此外，它还支持编写基于文本的协议，如 IRC、IMAP 或 SMTP，通过 TCP 连接并配置应发送的消息和预期的响应；即使是普通的 HTTP 也可以编写脚本，但是由于 HTTP 探测是一种常见的用例，它已经内置了。

话虽如此，此导出器并未涵盖所有黑盒式监控需求。对于这些情况，可能需要编写自己的导出器。例如，您不能使用 blackbox_exporter 端到端测试 Kafka 主题，因此您可能需要寻找能够向 Kafka 生成消息然后将其消费回来的导出器：

/probe 端点，当带有参数模块和目标的 HTTP GET 请求命中时，它针对定义的目标执行指定的 prober 模块，然后暴露结果作为普罗米修斯指标：

例如，诸如 http://192.168.42.11:9115/probe?module=http_2xx&target=example.com 之类的请求将返回类似于以下片段的内容（一些指标被丢弃简单）：

# HELP probe_duration_seconds Returns how long the probe took to complete in seconds
# TYPE probe_duration_seconds gauge
probe_duration_seconds 0.454460181
# HELP probe_http_ssl Indicates if SSL was used for the final redirect
# TYPE probe_http_ssl gauge
probe_http_ssl 0
# HELP probe_http_status_code Response HTTP status code
# TYPE probe_http_status_code gauge
probe_http_status_code 200
# HELP probe_ip_protocol Specifies whether probe ip protocol is IP4 or IP6
# TYPE probe_ip_protocol gauge
probe_ip_protocol 4
# HELP probe_success Displays whether or not the probe was a success
# TYPE probe_success gauge
probe_success 1

使用 blackbox_exporter 时需要注意的一个问题是 up 指标不反映探测的状态，而只是 Prometheus 可以到达导出器。从前面的指标输出中可以看出，有一个 probe_success 指标表示探测器本身的状态。这意味着 up 指标通常看起来健康，但探测可能失败，这是造成混淆的常见原因。

黑盒探测的抓取作业配置是不寻常的，因为 prober 模块和目标列表，无论是静态的还是发现的，都需要作为 HTTP GET 参数传递给导出器。 kbd>/probe 端点。要完成这项工作，需要一点 relabel_configs 魔法，如 第 5 章，运行 Prometheus 服务器。

使用以下 Prometheus 配置片段作为示例，我们正在针对 Prometheus 实例设置 ICMP 探测，同时 blackbox_exporter 在 target01 上运行：

  - job_name: 'blackbox-icmp'
    metrics_path: /probe
    params:
      module: [icmp]
    static_configs:
      - targets:
       - prometheus.prom.inet
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: target01:9115

目标是用 blackbox_exporter 的地址替换目标的地址，确保内部 __param_target 保持目标的地址。关注 relabel_configs 的处理方式，会发生以下情况：

• The __address__ value (which contains the address of the target) is stored into __param_target.
• __param_target value is then stored into the instance label.
• The blackbox_exporter host is then applied to __address__.

这使 Prometheus 能够查询 blackbox_exporter（使用 __address__），将实例标签与目标定义保持一致，并传递参数模块和目标（使用内部 __param_target ) 到 /probe 端点，该端点返回指标数据。

在我们的静态基础设施测试环境中，我们可以通过连接到 target01 实例来验证 blackbox_exporter 的配置，如下所示：

cd ./chapter06/

vagrant ssh target01

然后检查提供的 systemd 单元文件的配置，如以下命令所示：

vagrant@target01:~$ systemctl cat blackbox-exporter

我们可以在单元文件的以下代码段中看到 blackbox_exporter 服务所需的所有参数，包括配置文件的路径：

...
ExecStart=/usr/bin/blackbox_exporter --config.file=/etc/blackbox_exporter/blackbox.yml
...

我们为示例定制的配置可以在以下代码段中找到：

modules:
  http_2xx:
    prober: http
    http:
      preferred_ip_protocol: ip4

  icmp:
    prober: icmp
    icmp:
      preferred_ip_protocol: ip4

在 Prometheus 实例上，我们添加了以下作业：

- job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets: [ 'http://example.com', 'https://example.com:443' ]
...
  - job_name: 'blackbox-icmp'
    metrics_path: /probe
    params:
      module: [icmp]
    static_configs:
      - targets:
         - prometheus
...

使用 http://192.168.42.10:9090/targets 上的 Prometheus Web 界面，我们可以验证抓取是否成功（与探测器的返回状态无关）：

如前所述，/targets 页面不会告诉您探测是否成功。这需要通过查询 probe_success 指标在表达式浏览器中进行验证：

可以从 blackbox_exporter 收集的一些有趣的指标（关于导出器本身和探针）是：

• blackbox_exporter_config_last_reload_successful, which exposes if the exporter's configuration file was reloaded successfully after a SIGHUP
• probe_http_status_code, which allows you to understand what HTTP status code is being returned when using the HTTP prober module
• probe_ssl_earliest_cert_expiry, which returns the timestamp for when the certificate chain from a SSL probe becomes invalid due to one of the certificates in the chain expiring

尽管关于 push 与 pull 的激烈辩论以及在 Prometheus 服务器设计中使用 pull 的深思熟虑的决定，但在某些合理的情况下 push 更合适。

其中一种情况是批处理作业，但是，要使该声明真正有意义，我们需要清楚地定义什么是批处理作业。在此范围内，服务级批处理作业是不依赖于特定实例的处理工作负载，不经常执行或按计划执行，因此并不总是运行。这种工作很难在检测后生成成功的抓取，正如前面在 中所讨论的第 5 章，运行 Prometheus 服务器，会导致指标过时，即使运行时间足够长以致偶尔会被抓取。

除了依赖推送指标之外，还有其他选择；例如，通过使用来自 node_exporter 的文本文件收集器，如前所述。然而，这个选项并非没有缺点。如果工作负载不是特定于特定实例的，那么您最终会得到多个时间序列以及文本文件收集器文件的清理逻辑，除非指标的生命周期与实例的生命周期相匹配，然后在实践。

作为最后的手段，你有 Pushgateway，我们将在下面介绍。

如前所述，这个导出器应该只用于非常特定的用例，我们应该注意一些常见的陷阱。一个可能的问题是缺乏高可用性，使其成为单点故障。这也会影响可扩展性，因为容纳更多指标/客户端的唯一方法是垂直扩展实例（添加更多资源）或分片（为不同的逻辑组提供不同的 Pushgateway 实例）。通过使用 Pushgateway，Prometheus 不会直接抓取应用程序实例，这会阻止将 up 指标作为健康监控的代理。此外，与来自 node_exporter 的文本文件收集器类似，指标需要通过其 API 从 Pushgateway 手动删除，否则它们将永远暴露给 Prometheus。

要推送指标，您需要使用以下 URL 路径定义向 Pushgateway 端点发送 HTTP POST 请求。这将在以下部署部分中演示：

http://<pushgateway_address>:<push_port>/metrics/job/<job_name>/[<label_name1>/<label_value1>]/[<label_nameN>/<label_valueN>]

此处， 将成为推送的指标的标签作业的值， / 对将成为附加标签/值对。请记住，在手动删除之前，或者在重新启动的情况下，当未配置持久性时，度量标准将可用。

由于 Pushgateway 是实例推送其指标的集中点，因此当 Prometheus 执行抓取时，标签实例将自动设置为其公开的每个指标的 Pushgateway 服务器地址/端口，并将标签作业设置为设置的任何名称在 Prometheus 抓取作业定义中。在标签冲突时，Prometheus 将原始标签分别重命名为 exported_instance 和 exported_job。为避免这种行为，honor_labels: true 应在抓取作业定义中使用，以保证占主导地位的标签是来自 Pushgateway 的标签。

我们的测试用例值得注意的运行时配置如下：

我们将在之前启动的 Kubernetes 测试环境的基础上进行构建。在这个特定场景中，我们将部署 Pushgateway 的一个实例，并将其添加为 Prometheus 中的目标。为了验证我们设置的正确性，我们将创建一个 Kubernetes CronJob 来模拟工作负载的批处理作业样式，并将其指标推送到 Pushgateway 服务以确保 Prometheus 收集我们的数据。

要开始部署，请确保您移动到相对于代码存储库根目录的正确存储库路径：

cd ./chapter06/provision/kubernetes/

要部署 Pushgateway 的实例，您可以使用以下清单。请记住，此服务不支持高可用性或集群：

apiVersion: apps/v1
kind: Deployment
metadata: {name: pushgateway, namespace: monitoring}
spec:
  selector:
    matchLabels: {p8s-app: pushgateway}
  replicas: 1
  template:
    metadata:
      labels: {p8s-app: pushgateway}
    spec:
      containers:
      - name: pushgateway
...

通过执行以下命令应用清单：

kubectl apply -f ./pushgateway/pushgateway-deployment.yaml

并使用以下命令进行部署：

kubectl rollout status deployment/pushgateway -n monitoring

成功部署后，是时候为我们的新实例提供 Service 了，使用以下清单：

apiVersion: v1
kind: Service
metadata:
  name: pushgateway-service
  namespace: monitoring
  labels:
    p8s-app: pushgateway
spec:
  type: NodePort
  ports:
  - {name: push-port, port: 9091, targetPort: push-port, protocol: TCP}
  selector:
    p8s-app: pushgateway

以下说明适用于之前的清单：

kubectl apply -f ./pushgateway/pushgateway-service.yaml 

您现在可以使用以下命令验证 Pushgateway 的 Web 界面：

minikube service pushgateway-service -n monitoring

这将打开一个新的浏览器选项卡，指向新创建的 Pushgateway 实例 Web 界面，如下图所示：

现在，我们需要指示 Prometheus 抓取 Pushgateway。这可以通过一个新的 ServiceMonitor 清单来完成，如下所示：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    p8s-app: pushgateway
  name: pushgateway
  namespace: monitoring
spec:
  endpoints:
  - interval: 30s
    port: push-port
    honorLabels: true
  selector:
    matchLabels:
      p8s-app: pushgateway

要应用此 ServiceMonitor，我们只需键入以下命令：

kubectl apply -f ./pushgateway/pushgateway-servicemonitor.yaml

现在我们已经有了监控基础设施，我们需要模拟一个批处理作业来验证我们的设置。

我们可以依赖以下清单，它使用手工制作的 curl 有效负载将带有多个标签的虚拟 batchjob_example 指标推送到 Pushgateway 服务端点：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: batchjob
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: batchjob
            image: kintoandar/curl:7.61.1
            args:
            - -c
            - 'echo "batchjob_example $(date +%s)" | curl -s --data-binary @- http://pushgateway-service.monitoring.svc.cluster.local:9091/metrics/job/batchjob/app/example/squad/yellow'
          restartPolicy: OnFailure

要应用之前的清单，请使用以下命令：

kubectl apply -f ./pushgateway/batchjob-cronjob.yaml

一分钟后，Pushgateway 的 Web 界面将类似于此屏幕截图：

我们现在可以使用 Prometheus 表达式浏览器来验证指标是从 Pushgateway 中抓取的：

由于 Pushgateway 的工作是代理来自其他来源的指标，它自己提供的指标非常少——只有标准的 Go 运行时指标、进程指标、HTTP 处理程序指标和构建信息。但是，需要注意一个应用程序指标，即 push_time_seconds。这将告诉您最后一次看到特定组（推送时 HTTP API 中使用的标签组合）。这可用于检测丢失或延迟的作业。

Prometheus 社区已经为您可能需要的任何东西产生了大量的出口商。但是，有意选择在您的基础架构中部署新软件需要预先支付间接代价。这个价格转化为要编写的部署自动化代码、打包、要收集的指标和要创建的警报、日志记录配置、安全问题、升级以及我们有时认为理所当然的其他事情。在选择开源导出器或任何其他开源项目时，需要牢记一些指标。

我们应该验证项目背后的社区、贡献的总体健康状况、是否正在解决问题、是否及时管理拉取请求，以及维护者是否愿意与社区讨论和互动。从技术上讲，我们还应该检查特定项目是否正在使用官方 Prometheus 客户端库。话虽如此，我们将介绍一些值得注意的出口商。

Java 虚拟机 (JVM) 是 Kafka、ZooKeeper 和 Cassandra 等核心基础设施服务的热门选择。与许多其他服务一样，这些服务本身并不以 Prometheus 展示格式提供指标，并且检测此类应用程序绝非易事。在这些场景中，我们可以依靠 Java Management Extensions (JMX) 通过 Managed 暴露应用程序的的内部状态Beans（MBeans）。 JMX 导出器从公开的 MBean 中提取数字数据并将其转换为 Prometheus 指标，在 HTTP 端点上公开它们以供摄取。

导出器有以下两种形式：

• Java agent: In this mode, the exporter is loaded inside the local JVM where the target application is running and exposes a new HTTP endpoint.
• Standalone HTTP server: In this mode, a separate JVM instance is used to run the exporter that connects via JMX to the target JVM and exposes collected metrics on its own HTTP server.

文档强烈建议使用 Java 代理部署导出器，这是有充分理由的；与独立导出器相比，该代理生成更丰富的指标集，因为它可以访问被检测的完整 JVM。但是，两者都需要权衡取舍，以便为工作选择正确的工具。

尽管独立服务器无法访问 JVM 特定指标，例如垃圾收集器统计信息或进程内存/CPU 使用率，但当 Java 应用程序已经启用 JMX 并且是长时间运行的进程时，在静态基础架构上部署和管理可能会更容易不方便触摸。除此之外，导出器升级周期与应用程序生命周期脱钩，即使新版本不常见。

另一方面，Java 代理在 JVM 中提供了所有可用的指标，但需要在启动时加载到目标应用程序中。这对于定期部署的应用程序或当这些应用程序在容器中运行时可能更简单。

运行代理的另一个好处是目标 JVM 也负责提供自己的指标，因此来自抓取作业的 up 指标可以毫无歧义地表示进程状态。

这两个选项都需要一个配置文件，该文件可以将 MBean 中的指标列入白名单、黑名单和/或重新标记为 Prometheus 格式。一个重要的性能考虑是尽可能使用白名单。一些应用程序暴露了大量的 MBean（例如 Kafka 或 Cassandra），并且频繁的抓取确实会对性能产生重大影响。

HAProxy 是一种著名的负载平衡解决方案，在撰写本文时并未原生公开 Prometheus 指标。幸运的是，它有一个由 Prometheus 维护者制作的导出器，以确保可以收集其指标，即 haproxy_exporter。 HAProxy 使用 stats enable 配置通过可配置的 HTTP 端点以 逗号分隔值 (CSV) 格式本地公开其指标。 haproxy_exporter 作为一个单独的守护进程运行，能够连接到 HAProxy stats 端点，使用 CSV，并将其内容转换为 Prometheus 度量格式，并在被触发时以同步方式公开它刮。

当后端池中的应用程序未正确检测并因此不公开访问指标时，检测负载平衡器层可能非常有用。例如，可以为 HTTP 错误率或后端可用性创建仪表板和警报，而无需应用程序方面的任何开发工作。这并不是一个长期的解决方案，但可以帮助从遗留监控系统过渡到 Prometheus。

在本章中，我们有机会发现了一些最常用的 Prometheus 导出器。使用测试环境，我们能够与运行在 VM 上的操作系统级导出器和运行在 Kubernetes 上的特定于容器的导出器进行交互。我们发现有时我们需要依靠日志来获取指标，并通过当前的最佳选项来实现这一点。然后，我们在 blackbox_exporter 的帮助下探索了黑盒探测，并验证了其独特的工作流程。我们还尝试了推送指标，而不是使用 Prometheus 的标准拉取方法，同时明确为什么有时这种方法确实有意义。

所有这些导出器使您无需本地检测代码即可获得可见性，这有时比依赖社区驱动的导出器成本更高。

有了如此多的指标来源，现在是了解如何从数据中提取有用信息的时候了。在下一章中，我们将讨论 PromQL 以及如何最好地利用它。

1. How would you collect custom metrics with the Node Exporter?
2. What resources does cAdvisor consult to generate metrics?
3. kube-state-metrics expose numerous API objects. Is there a way to restrict that number?
4. How could you debug a blackbox_exporter probe?
5. If an application does not expose metrics, in Prometheus format or otherwise, what could an option to monitor it be?
6. What are the downsides of using Pushgateway?
7. If a particular batch job is host specific, is there any alternative to the use of Pushgateway?

• Prometheus exporters: https://prometheus.io/docs/instrumenting/exporters/
• Prometheus port allocations: https://github.com/prometheus/prometheus/wiki/Default-port-allocations
• Manpages cgroups: http://man7.org/linux/man-pages/man7/cgroups.7.html
• Manpages namespaces: http://man7.org/linux/man-pages/man7/namespaces.7.html
• Kubernetes resource usage monitoring: https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/