Prometheus k8s下面的Node Exporter详解

Node Exporter DaemonSetDaemonSet使用toleration（容忍）确保pod在所有节点上运行，可能也包含主节点。它非常适合监控或日志代理等项目。让我们看一下DaemonSet的元素。可以在GitHub上找到Node Exporter的完整配置。Node Exporter DaemonSet toleration：首先，可以看到我们给DaemonSet指定了一个名称no

富士康质检员张全蛋

3240人浏览 · 2021-02-05 10:46:22

富士康质检员张全蛋 · 2021-02-05 10:46:22 发布

部署 Node Exporter

[root@master prometheus]# cat node-export.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitor
  labels:
    name: node-exporter
spec:
  selector:
    matchLabels:
     name: node-exporter
  template:
    metadata:
      labels:
        name: node-exporter
    spec:
      tolerations:
      - effect: NoSchedule
        operator: Exists
      hostPID: true
      hostIPC: true
      hostNetwork: true
      containers:
      - name: node-exporter
        image: prom/node-exporter:v0.16.0
        ports:
        - containerPort: 9100
        securityContext:
          privileged: true
        args:
        - --path.procfs
        - /host/proc
        - --path.sysfs
        - /host/sys
        - --collector.filesystem.ignored-mount-points
        - --collector.systemd
        - --collector.systemd.unit-whitelist=(docker|sshd|kubelet).service
        - '"^/(sys|proc|dev|host|etc)($|/)"'
        volumeMounts:
        - name: dev
          mountPath: /host/dev
        - name: proc
          mountPath: /host/proc
        - name: sys
          mountPath: /host/sys
        - name: rootfs
          mountPath: /rootfs
      volumes:
        - name: proc
          hostPath:
            path: /proc
        - name: dev
          hostPath:
            path: /dev
        - name: sys
          hostPath:
            path: /sys
        - name: rootfs
          hostPath:
            path: /

[root@master prometheus]# kubectl get pod -n ops
NAME                        READY   STATUS      RESTARTS   AGE
node-exporter-d4jbc         1/1     Running     0          13m
node-exporter-n4rh8         1/1     Running     0          13m
node-exporter-z29mg         1/1     Running     0          13m

Node Exporter DaemonSet

DaemonSet使用toleration（容忍）确保pod在所有节点上运行，可能也包含主节点。它非常适合监控或日志代理等项目。让我们看一下DaemonSet的元素。

可以在 GitHub 上找到 Node Exporter 的完整配置。Node Exporter DaemonSet toleration：

首先， 可以看到我们给DaemonSet指定了一个名称node-exporter，并且使用toleration来确保pod也会被调度到Kubernetes主节点，而不仅是工作节点。

这里就可以看到刚刚警告中提到的情况。我们以用户 0 或 root 运行 pod （这允许访问 systemd ）， 并且还启用了hostNetwork、hostPID和hostIPC，以指定实例的网络、进程和IPC命名空间在容器中可用。 这些都是潜在的安全风险，你必须考虑是否可以承担此风险。如果这种风险是不可接受的，那么将Node Exporter放到实例的镜像中可能是一种更好的方法。让我们来看看pod 中的容器。

Node Exporter DaemonSet容器

这里，我们使用DockerHub中的Node Exporter镜像prom/node_exporter，并获取最新版本。我们还为实例上的目录/run/systemd/private挂载了一个卷，这允许Node Exporter访问systemd并在实例上收集systemd管理服务的服务状态。

我们还为 node_exporter 二进制文件指定了一些参数：启用 systemd 收集器，并指定要监控的特定服务的正则表达式，而不是主机上的所有服务。

我们还指定了希望暴露指标的端口 9100 ，它也是默认端口。

为了帮助 Node Exporter pod 保持健康并提高它们的正常运行时间，我们还在 Node Exporter 容器中添加了liveness 和 readiness 探针，其中 liveness探针检测容器内应用程序的状态。Node Exporter 的 liveness 和 readiness 探针

我们也会在监控的应用程序中看到这些探针。它们通过减少可能的监控误报来帮助管理应用程序的运行状况，例如服务在启动时没有达到就绪要求而触发警报。这些检查还可以重新启动有问题的容器，可能会帮助在触发警报之前修复问题。

readiness 探针可确认应用程序正常运行。这意味着，在将容器标记为可用并发送流量之前，HTTPGET可以连接到端口9100上的/metrics路径。其余设置控制探针的行为，在检查准备就绪之前，它将等待10秒（initialDelaySecond），然后，它会每隔2秒（periodSeconds）检查一次。如果探针在10秒（timeoutSeconds）后超时超过5次（failureThreshold），则容器将被标记为Unready。

Node Exporter服务

我们还需要创建一个服务来暴露Node Exporter，以便进行指标抓取。

Node Exporter 服务

服务相对来说比较简单。我们添加了一个注解prometheus.io/scrape:'true'作为服务的元数据，它将告诉Prometheus应该抓取这个服务。后面我们将看到它是如何在Prometheus作业中抓取NodeExporter的。

我们还将端口 9100 作为 ClusterIP 暴露，这意味着它仅用于内部集群网络。由于 Prometheus 位于本地Kubernetes 集群，能够在内部抓取 Node Exporter ，因此无须对外暴露。

可以在 GitHub 上找到完整的 Node Exporter 服务配置。

https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/ 。

部署Node Exporter

让我们使用kubectl命令在Kubernetes集群上创建DaemonSet和服务。我们将在monitoring命名空间内创建它们。

部署 Node Exporter DaemonSet 和服务

如果你不想继续指定-n monitoring 命名空间，则可以将其指定为默认值

现在查看我们的 pod 是否正在运行。

检查Node Exporter窗格

可以看到总共有 9 个 pod ，集群中每个实例 1 个： 3 个主节点和 6 个工作节点。我们还可以看到Prometheus服务和 Alertmanager 的 pod ，分别是 prometheus-core 和 alertmanager 。

我们可以通过捕捉日志来检查 Node Exporter pod 是否正常运行。

Node Exporter pod日志

可以看到我们的Node Exporter守护进程正在运行，也可以确认服务已经就绪。

检查Node Exporter服务

这里，可以看到 node-exporter 服务是 ClusterIP 类型的，并且暴露 9100 端口给内部 Kubernetes 集群，随时可以被抓取。然而，我们还没有开始抓取，因为还没有添加Prometheus 作业。

Node Exporter作业

在Prometheus配置中，我们现在想添加一个作业来抓取Node Exporter端点。通过定义一项抓取Kubernetes暴露的所有服务端点的作业，这将会一举多得。我们还会控制Prometheus仅抓取具有特定注解prometheus.io/scrape（设置为'true'）的端点。然后，我们使用内置的Kubernetes服务发现来查找端点，并将它们作为Prometheus的潜在目标返回。

所有这些工作都是基于 Prometheus 自带的 Kubernetes 作业案例。现在让我们来看看这个作业内容。

 - job_name: kubernetes-service-endpoints
      kubernetes_sd_configs:
      - role: endpoints  # 从Service列表中的Endpoint发现Pod为目标
      relabel_configs:
      # Service没配置注解prometheus.io/scrape的不采集
      - action: keep
        regex: true
        source_labels:
        - __meta_kubernetes_service_annotation_prometheus_io_scrape
      # 重命名采集目标协议
      - action: replace
        regex: (https?)
        source_labels:
        - __meta_kubernetes_service_annotation_prometheus_io_scheme
        target_label: __scheme__
      # 重命名采集目标指标URL路径
      - action: replace
        regex: (.+)
        source_labels:
        - __meta_kubernetes_service_annotation_prometheus_io_path
        target_label: __metrics_path__
      # 重命名采集目标地址
      - action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        source_labels:
        - __address__
        - __meta_kubernetes_service_annotation_prometheus_io_port
        target_label: __address__
      # 将K8s标签(.*)作为新标签名，原有值不变
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      # 生成命名空间标签
      - action: replace
        source_labels:
        - __meta_kubernetes_namespace
        target_label: kubernetes_namespace
      # 生成Service名称标签
      - action: replace
        source_labels:
        - __meta_kubernetes_service_name
        target_label: kubernetes_name

Kubernetes服务端点作业

我们称这个作业为kubernetes-service-endpoints，指定服务发现使用kubernetes_sd_discovery机制——这是内置的服务发现机制，专门用于监控Kubernetes。它向Kubernetes API查询符合特定搜索条件的目标。

由于Prometheus 服务器在 Kubernetes 内部运行，因此我们能够以最少的配置自动获取与特定角色匹配的Kubernetes 目标。节点、 pod 、服务和入口都有不同的角色，由参数 role 指定，我们要求服务发现返回所有Kubernetes 端点。 endpoints 角色返回服务的所有已列出端点的目标，每个端点地址的每个端口都是一个目标。如果端点也是由pod 提供，就像 Node Exporter 服务那样，那么任何其他容器端口也会作为目标被发现。在示例中，我们只暴露了9100 端口。

服务发现还会填充各种元数据，可以使用元数据重新标记并标识每个端点。首先我们看看重新标记规则的作用并进一步探索元数据。

第一条规则检查我们在 Node Exporter 服务中设置的注解 prometheus.io/scrape:'true' 。在服务发现过程中，prometheus.io/scrape 注解会被转换为 prometheus_io_scrape ，以创建一个有效的标签名称，这是因为在Prometheus 指标标签中点和斜杠不是合法字符。由于这是 Kubernetes 服务的注解，因此 Prometheus服务进程还会在标签中添加 __meta_kubernetes_service_annotation_ 前缀。

我们的作业只保留具有元数据标签的目标，即__meta_kubernetes_service_annotation_（设置为true）。所有其他目标都会被丢弃，这使得你只抓取所需的端点。

接下来的三个规则检查是否存在其他注解： prometheus.io/scheme 、 prometheus.io/path 和prometheus.io/port。如果这些标签存在，那么它将使用这些注解的内容作为要抓取的 scheme 、 path 和port。这使我们能够从服务端点精确控制要抓取的内容，进而使作业变得更加灵活。

我们的下一个规则使用 labelmap 操作将服务上的标签映射到同名的 Prometheus 标签。在示例中，这会将__meta_kubernetes_service_label_app 元数据标签映射为一个简单的 app 标签。下一个规则将__meta_kubernetes_namespace标签复制到 kubernetes_namespace ，将 __meta_kubernetes_service_name 元数据标签复制到kubernetes_name 。

我们现在将作业添加到用于 Prometheus 服务器配置的 ConfigMap 中，然后替换现有的配置。

通常我们必须删除Prometheus pod，以便重新创建并加载新配置。稍后我们将在Prometheus表达式浏览器上看到一些新的目标

Kubernetes 端点目标

可以看到我们列出了 13 个目标，其中 9 个是实例上的 Node Exporter 端点，第 10 个和第 11 个分别是Prometheus和 Alertmanager 。 Prometheus 和 Alertmanager 目标被自动发现，是因为它们的接口也作为服务暴露了出来

监控服务

这个作业非常有价值，因为我们只需要定义一次，未来所有Kubernetes服务端点都将被自动发现和监控。在作业加载后，我们还会看到node_时间序列开始出现在表达式浏览器中。

AtomGit 开源协作平台测评赛

瓜分20万奖金获得内推名额丰厚实物奖励易参与易上手

更多推荐

ADS1292R 使用过程心电图高精度ADC模块

文章目录1 Fundamentals ofPrecision ADC Noise Analysis 精密模数转换器噪声分析基础1 Fundamentals ofPrecision ADC Noise Analysis 精密模数转换器噪声分析基础https://www.ti.com.cn/cn/lit/wp/slyy192/slyy192.pdf?ts=1600659610730&ref_u

开放原子开发者工作坊

实现一个家庭安防与环境监测系统（一）

开放原子开发者工作坊

【cf】Codeforces Round #774 (Div. 2) 前4题

题目A. Square Counting 简单数学题目大意题解代码B. Quality vs Quantity 排序题目大意题解代码C. Factorials and Powers of Two 状态压缩dp+位运算题目大意题解代码D. Weight the Tree 树形dp+dfs题目大意题解代码E. Power Board 看起来像是数论？许多年没打cf了，偶尔打了一盘，恢复紫名了。A. S