七桃资源网

七桃资源网

Prometheus配置文件_Kubernetes

qtfan 0 4 次浏览 技术文章
Prometheus 配置详解以及和其他监控工具的对比

1、Prometheus 配置详解

要想知道一个工具是如何运行的，那么了解其配置参数，对了解整个工具以及后续的瓶颈了解、优化是非常有帮助的。

官方文档说明: https://prometheus.io/docs/prometheus/latest/configuration/configuration/

Prometheus 配置分为两个部分，命令行传递的不可变配置，配置文件传递的可变配置。所谓不可变是指进程进行运行中是不可以动态更新。

Prometheus提供了两个可执行文件：prometheus 和 promtool，前者用于prometheus server的启停，后者为prometheus调试工具，常用于配置文件检查。

prometheus 常用参数：

  -h, --help                              显示帮助信息
      --version                           显示版本
      --config.file=&#;prometheus.yml&#;      指定配置文件
      --web.listen-address=&#;:&#; 指定监听的端口
      --web.max-connections=           最大连接数
      --web.enable-lifecycle              是否开启reload和shutdown的远程API
      --web.enable-admin-api              是否开启管理API
      --web.console.templates=&#;consoles&#;  控制台模板目录
      --web.console.libraries=&#;console_libraries&#;  控制台库文件目录
      --storage.tsdb.path=&#;data/&#;         数据存储路径
      --storage.tsdb.retention.time       数据保留时间，默认天
      --query.timeout=2m                  查询超时时间
      --query.max-concurrency=          最大并发查询数量
      --query.max-samples=        单次查询返回的最大样本数
      --log.level=info                    日志级别: [debug, info, warn, error]
      --log.format=logfmt                 日志输出格式：[logfmt, json]

promtool 常用参数：

check config <config-files>...  检查配置文件
check rules <rule-files>...     检查规则文件

、热加载

Prometheus改变参数可以通过命令行参数以及配置文件，其中命令行参数只要是修改系统参数，例如存储路径的指定或者挂载磁盘 Prometheus可以在运行时重新加载它的配置。 如果新配置格式不正确，则更改将不会应用。 通过向Prometheus进程发送SIGHUP或向/-/reload端点发送HTTP POST请求（启用--web.enable-lifecycle标志时）来触发配置reload。 这也将重新加载任何配置的规则文件。

prometheus通过--config.file命令行参数指定配置文件

 配置热加载：
 #1.  kill -HUP pid # 发送 SIGHUP 信号给prometheus进程
 #2.  curl -X POST http://IP/-/reload # 调用 /-/reload API，仅在启用 --web.enable-lifecycle 状态下

、通用类型

 1. <boolean>：true false
 2. <duration>：与正则表达式[]+(ms|[smhdwy])匹配的持续时间
 3. <labelname>：与正则表达式匹配的字符串[a-zA-Z_][a-zA-Z0-9_]*
 4. <labelvalue>：一个unicode字符串
 5. <filename>：当前工作目录中的有效路径
 6. <host>：一个有效的字符串，由一个主机名或IP后跟一个可选的端口号组成
 7. <path>：有效的URL路径
 8. <scheme>：可以取值为http或https的字符串
 9. <string>：一个常规字符串
 . <secret>：一个常用的密码字符串，例如密码
 . <tmpl_string>：在使用前被模板扩展的字符串

、配置文件格式

原始配置文件内容：

# my global config
global:
  # 默认情况下抓取目标的频率.
  [ scrape_interval: <duration> | default = 1m ]
  # 抓取超时时间.
  [ scrape_timeout: <duration> | default = 10s ]
  # 评估规则的频率.
  [ evaluation_interval: <duration> | default = 1m ]
  # 与外部系统通信时对时间序列或者告警信息添加的标签，如remote storage、alertmanager等
  external_labels:
    [ <labelname>: <labelvalue> ... ]
  # PromQL查询日志，reload操作会重新打开日志
  [ query_log_file: <string> ]
 
# 警报指定与Alertmanager相关的设置.
alerting:
  # 告警标签重写
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  # alertmanager 配置
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:
 
# 规则文件指定了一个globs列表. 
# 从所有匹配的文件中读取规则和警报. 
# 根据 global 的 &#;evaluation_interval&#;.
rule_files:
  # - &#;first_rules.yml&#;
  # - &#;second_rules.yml&#;
  # - &#;/etc/config/rules/*.yml&#; # 代表rules目录下的所有以.yml结尾的文件
 
# A scrape configuration containing exactly one endpoint to scrape:
# Here it&#;s Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=` to any timeseries scraped from this config.
  - job_name: &#;prometheus&#;
    # metrics_path defaults to &#;/metrics&#;
    # scheme defaults to &#;http&#;.
    static_configs:
    - targets: [&#;localhost:&#;]

# 与远程写入功能相关的设置.
remote_write:
  [ - <remote_write> ... ]

# 与远程读取功能相关的设置.
remote_read:
  [ - <remote_read> ... ]

global: 全局配置（如果有内部单独设定，会覆盖这个参数） alerting: 告警插件定义。这里会设定alertmanager这个报警插件。 rule_files: 告警规则。 按照设定参数进行扫描加载，用于自定义报警规则，其报警媒介和route路由由alertmanager插件实现。 scrape_configs:采集配置。配置数据源，包含分组job_name以及具体target。又分为静态配置和服务发现

、global 模块

global配置是一个全局的配置，如果没有对每一个job（scrape_configs下的job_name项）配置，就采用全局的配置。

 # my global config
 global:
  
 scrape_interval: 15s # 默认15s 全局每次数据收集的间隔
 evaluation_interval: 15s # 规则扫描时间间隔是秒，默认不填写是 1分钟
 scrape_timeout: 5s    #超时时间
 external_labels: # 用于外部系统标签的，不是用于metrics(度量)数据

常用的命令行参数(prometheus插件基本都是二进制的，可以通过二进制文件 -h了解参数用于自定义启动参数，否则默认)

 ./prometheus -h
 --config.file=&#;/opt/config/prometheus.yml&#;  # 读取指定配置文件
 --web.listen-address=&#;:&#;  # 指定prometheus运行端口 
 --log.level=info # 日志级别
 --alertmanager.timeout=10s # 与报警组件的超时时间

、alerting 模块

 # 警报指定与Alertmanager相关的设置.
 alerting:
   # 告警标签重写
   alert_relabel_configs:
     [ - <relabel_config> ... ]
   # alertmanager 配置
   alertmanagers:
   - static_configs:
     - targets:
       # - alertmanager:

这里定义和prometheus集成的alertmanager插件，用于监控报警。

、alert_relabel_configs

警报重新标记在发送到Alertmanager之前应用于警报。 它具有与目标重新标记相同的配置格式和操作。 外部标签后应用警报重新标记。

这样做的一个用途是确保具有不同外部标签的HA对Prometheus服务器发送相同的警报。

、alertmanager_config

alertmanager部分指定Prometheus服务器向其发送警报的Alertmanager实例。 它还提供参数以配置如何与这些Alertmanagers进行通信。

Alertmanagers可以通过static_configs参数静态配置，也可以使用其中一种支持的服务发现机制动态发现。

此外，relabel_configs允许从发现的实体中选择Alertmanagers，并对使用的API路径提供高级修改，该路径通过__alerts_path__标签公开。

# 推送警报时按目标Alertmanager超时。
[ timeout: <duration> | default = 10s ]

# 将推送HTTP路径警报的前缀。
[ path_prefix: <path> | default = / ]

# 配置用于请求的协议方案。
[ scheme: <scheme> | default = http ]

# 使用配置的用户名和密码在每个请求上设置`Authorization`标头。 password和password_file是互斥的。
basic_auth:
  [ username: <string> ]
  [ password: <string> ]
  [ password_file: <string> ]

# 使用配置的承载令牌在每个请求上设置“Authorization”标头。 它与`bearer_token_file`互斥。
[ bearer_token: <string> ]

# 使用配置的承载令牌在每个请求上设置“Authorization”标头。 它与`bearer_token`互斥。
[ bearer_token_file: /path/to/bearer/token/file ]

# 配置scrape请求的TLS设置。
tls_config:
  [ <tls_config> ]

# 可选的代理URL。
[ proxy_url: <string> ]

# Azure服务发现配置列表。
azure_sd_configs:
  [ - <azure_sd_config> ... ]
# Consul服务发现配置列表。
consul_sd_configs:
  [ - <consul_sd_config> ... ]
# DNS服务发现配置列表。
dns_sd_configs:
  [ - <dns_sd_config> ... ]
# ECS服务发现配置列表。
ec2_sd_configs:
  [ - <ec2_sd_config> ... ]
# 文件服务发现配置列表。
file_sd_configs:
  [ - <file_sd_config> ... ]
# GCE服务发现配置列表。
gce_sd_configs:
  [ - <gce_sd_config> ... ]
# K8S服务发现配置列表。
kubernetes_sd_configs:
  [ - <kubernetes_sd_config> ... ]
# Marathon服务发现配置列表。
marathon_sd_configs:
  [ - <marathon_sd_config> ... ]
# AirBnB&#;s Nerve 服务发现配置列表。
nerve_sd_configs:
  [ - <nerve_sd_config> ... ]
# Zookepper服务发现配置列表。
serverset_sd_configs:
  [ - <serverset_sd_config> ... ]
# Triton服务发现配置列表。
triton_sd_configs:
  [ - <triton_sd_config> ... ]
# 标记为静态配置的Alertmanagers列表。
static_configs:
  [ - <static_config> ... ]

# 对发现的alertmanager进行筛选和标签重写，比如API中PATH
relabel_configs:
  [ - <relabel_config> ... ]

、rule_files 模块

这个主要是用来设置告警规则，基于设定什么指标进行报警（类似触发器trigger）。这里设定好规则以后，prometheus会根据全局global设定的evaluation_interval参数进行扫描加载，规则改动后会自动加载。其报警媒介和route路由由alertmanager插件实现。

# Load rules once and periodically evaluate them according to the global &#;evaluation_interval&#;.
rule_files:
  # - &#;first_rules.yml&#;
  # - &#;second_rules.yml&#;
  # - &#;/etc/config/rules/*.yml&#; # 代表rules目录下的所有以.yml结尾的文件

规则文件分为两种：记录规则(recording rule)和报警规则(altering rule)。报警规则在告警管理中。recording rules 目的是将常用的复杂查询结果周期性写入数据库，避免频繁计算带来的资源消耗，一般将dashboard中复杂查询写入recording rules 中。

、recording rule

 # recording rule
 groups:
   # 组名，配置文件中不能重复
   - name: <string>
     # 多久计算计算一次
     [ interval: <duration> | default = global.evaluation_interval ]
     rules:
       # 入库的指标名称
       - record: <string>
         # PromQL表达式
         expr: <string>
         # 标签
     labels:
       [ <labelname>: <labelvalue> ]

、altering rule

# alerting rule
groups:
  # 组名，一个文件中唯一标识
  - name: <string>
    [ interval: <duration> | default = global.evaluation_interval ]
    rules:
      - alert: <string> # 报警名称
        expr: <string>  # 报警规则表达式
  [ for: <duration> | default = 0s ] # 当触发条件持续指定时间再发送告警，发送前告警为pending
  labels:         # 告警标签
      [ <labelname>: <tmpl_string> ] # 会覆盖已有的标签，用于后面alertmanager中筛选
  annotations:         # 告警注释
    [ <labelname>: <tmpl_string> ]   # 一般添加发送邮件的内容、标题等等。常用字段有:summary,description

、scrape_configs 模块

scrape_configs 默认规则：
scrape_configs:
  # The job name is added as a label `job=` to any timeseries scraped from this config.
  - job_name: &#;prometheus&#;
 
    # metrics_path defaults to &#;/metrics&#;
    # scheme defaults to &#;http&#;.
 
    static_configs:
    - targets: [&#;localhost:&#;]

prometheus获取数据源target的方式有多种，如静态配置和服务发现配置，prometheus支持多种服务发现，在prometheus中的服务发现主要分为以下几种：

  • static_configs：静态服务发现
  • kubernetes_sd_configs: 基于Kubernetes的服务发现，这章讲的内容
  • consul_sd_configs: Consul 服务发现
  • dns_sd_configs: DNS 服务发现
  • file_sd_configs: 文件服务发现
  • ......
# 默认分配给已抓取指标的job名称。
job_name: <job_name>

# 从job中抓取目标的频率.
[ scrape_interval: <duration> | default = <global_config.scrape_interval> ]

# 抓取此job时，每次抓取超时时间.
[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ]

# 从目标获取指标的HTTP资源路径.
[ metrics_path: <path> | default = /metrics ]

# honor_labels控制Prometheus如何处理已经存在于已抓取数据中的标签与Prometheus将附加服务器端的标签之间的冲突（&#;job&#;和&#;instance&#;标签，手动配置的目标标签以及服务发现实现生成的标签）。
# 
# 如果honor_labels设置为&#;true&#;，则通过保留已抓取数据的标签值并忽略冲突的服务器端标签来解决标签冲突。
#
# 如果honor_labels设置为&#;false&#;，则通过将已抓取数据中的冲突标签重命名为&#;exported_ <original-label>&#;（例如&#;exported_instance&#;，&#;exported_job&#;）然后附加服务器端标签来解决标签冲突。 这对于联合等用例很有用，其中应保留目标中指定的所有标签。
# 
# 请注意，任何全局配置的&#;external_labels&#;都不受此设置的影响。 在与外部系统通信时，它们始终仅在时间序列尚未具有给定标签时应用，否则将被忽略。
# 
[ honor_labels: <boolean> | default = false ]

# 配置用于请求的协议方案.
[ scheme: <scheme> | default = http ]

# 可选的HTTP URL参数.
params:
  [ <string>: [<string>, ...] ]

# 使用配置的用户名和密码在每个scrape请求上设置`Authorization`标头。 password和password_file是互斥的。
basic_auth:
  [ username: <string> ]
  [ password: <secret> ]
  [ password_file: <string> ]

# 使用配置的承载令牌在每个scrape请求上设置`Authorization`标头。 它`bearer_token_file`和是互斥的。
[ bearer_token: <secret> ]

# 使用配置的承载令牌在每个scrape请求上设置`Authorization`标头。 它`bearer_token`和是互斥的。
[ bearer_token_file: /path/to/bearer/token/file ]

# 配置scrape请求的TLS设置.
tls_config:
  [ <tls_config> ]

# 可选的代理URL.
[ proxy_url: <string> ]

# Azure服务发现配置列表.
azure_sd_configs:
  [ - <azure_sd_config> ... ]

# Consul服务发现配置列表.
consul_sd_configs:
  [ - <consul_sd_config> ... ]

# DNS服务发现配置列表。
dns_sd_configs:
  [ - <dns_sd_config> ... ]

# EC2服务发现配置列表。
ec2_sd_configs:
  [ - <ec2_sd_config> ... ]

# OpenStack服务发现配置列表。
openstack_sd_configs:
  [ - <openstack_sd_config> ... ]

# 文件服务发现配置列表。
file_sd_configs:
  [ - <file_sd_config> ... ]

# GCE服务发现配置列表。
gce_sd_configs:
  [ - <gce_sd_config> ... ]

# Kubernetes服务发现配置列表。
kubernetes_sd_configs:
  [ - <kubernetes_sd_config> ... ]

# Marathon服务发现配置列表。
marathon_sd_configs:
  [ - <marathon_sd_config> ... ]

# AirBnB的神经服务发现配置列表。
nerve_sd_configs:
  [ - <nerve_sd_config> ... ]

# Zookeeper Serverset服务发现配置列表。
serverset_sd_configs:
  [ - <serverset_sd_config> ... ]

# Triton服务发现配置列表。
triton_sd_configs:
  [ - <triton_sd_config> ... ]

# 静态抓取目标配置，一般只有极个别场景才会配置，否则会导致主配置文件更新频繁，并且很臃肿
static_configs:
  # 指定抓取目标的地址
  targets:
    [ - &#;<host>&#; ]
  # 对采集到的数据指定额外的标签
  labels:
    [ <labelname>: <labelvalue> ... ]

# target 标签重写规则
relabel_configs:
  [ - <relabel_config> ... ]

# metrics 标签重写规则。
metric_relabel_configs:
  [ - <relabel_config> ... ]

# 样本数限制，超过规定之则被丢弃。0表示不限制
[ sample_limit: <int> | default = 0 ]

# target 数量限制，超过的将被丢弃，目前为实验性功能。0表示不限制
[ target_limit: <int> | default = 0 ]

、tls_config

tls_config允许配置TLS连接。

# 用于验证API服务器证书的CA证书。
[ ca_file: <filename> ]

# 用于服务器的客户端证书身份验证的证书和密钥文件。
[ cert_file: <filename> ]
[ key_file: <filename> ]

# ServerName扩展名，用于指示服务器的名称。
# https://tools.ietf.org/html/rfc4366#section-
[ server_name: <string> ]

# 禁用服务器证书的验证。
[ insecure_skip_verify: <boolean> ]

、file_sd_config

配置target 的文件可以是json也可以是yaml，推荐使用yaml，方便查看。

 # 主配置文件中 <file_sd_config>
 # 配置target的文件列表
 files:
   [ - <filename_pattern> ... ]
 
 # 从这些文件中读取配置的时间间隔
 [ refresh_interval: <duration> | default = 5m ]
 
 # 自动发现文件配置案例
 - targets:
     - address1
     - address2
   labels:
     labelname1: labelvalue1
     labelname2: labelvalue2

、dns_sd_config

基于DNS的服务发现配置允许指定一组DNS域名，这些域名会定期查询以发现目标列表。 要联系的DNS服务器从/etc/resolv.conf中读取。

此服务发现方法仅支持基本的DNS A，AAAA和SRV记录查询，但不支持RFC6763中指定的高级DNS-SD方法。

在重新标记阶段，元标签__meta_dns_name在每个目标上可用，并设置为生成已发现目标的记录名称。

 # 要查询的DNS域名列表。
 names:
   [ - <domain_name> ]
 
 # 要执行的DNS查询的类型。
 [ type: <query_type> | default = &#;SRV&#; ]
 
 # 查询类型不是SRV时使用的端口号。
 [ port: <number>]
 
 # 提供名称后刷新的时间。
 [ refresh_interval: <duration> | default = 30s ]

其中<domain_name>是有效的DNS域名。 其中<query_type>是SRV，A或AAAA。

、consul_sd_configs

consul 是基于go语言写的注册中心，在生产中可以作为prometheus自动发现的中间件。

# consul 地址信息
[ server: <host> | default = &#;localhost:&#; ]
[ token: <secret> ]
[ datacenter: <string> ]
[ scheme: <string> | default = &#;http&#; ]
[ username: <string> ]
[ password: <secret> ]

tls_config:
  [ <tls_config> ]

# 自动发现请求访问哪些服务，默认是所有服务
services:
  [ - <string> ]

# 过滤目标节点，只有全部包含这些tag的服务地址才会给prometheus认定为target
tags:
  [ - <string> ]

# 通过元数据的键值对节点进行过滤
[ node_meta:
  [ <string>: <string> ... ] ]

# The string by which Consul tags are joined into the tag label.
[ tag_separator: <string> | default = , ]

# Allow stale Consul results (see https://www.consul.io/api/features/consistency.html). Will reduce load on Consul.
[ allow_stale: <boolean> | default = true ]

# 访问consul的时间间隔
[ refresh_interval: <duration> | default = 30s ]

、kubernetes_sd_config

Kubernetes SD配置允许从Kubernetes的RESTAPI中检索scrape目标，并始终与群集状态保持同步。

可以配置以下role类型之一来发现目标：

  • node
  • service
  • pod
  • endpoints
  • ingress

、node

node角色发现每个群集节点有一个目标，其地址默认为Kubelet的HTTP端口。 目标地址默认为NodeInternalIP，NodeExternalIP，NodeLegacyHostIP和NodeHostName的地址类型顺序中Kubernetes节点对象的第一个现有地址。

可用元标签：

__meta_kubernetes_node_name: 节点名称
__meta_kubernetes_node_label_<labelname>: node的labels
__meta_kubernetes_node_annotation_<annotationname>: node的annotation
__meta_kubernetes_node_address_<address_type>: 如果存在四个值中(NodeInternalIP, NodeExternalIP, NodeLegacyHostIP, and NodeHostName)的一个

此外，节点的instance标签将设置为从API服务器检索的节点名称。

、service

service角色为每个服务发现每个服务端口的目标。 这对于服务的黑盒监控通常很有用。 该地址将设置为服务的Kubernetes DNS名称和相应的服务端口。

可用元标签：

 __meta_kubernetes_namespace：服务对象的命名空间。
 __meta_kubernetes_service_annotation_<annotationname>：服务对象的注释。
 __meta_kubernetes_service_cluster_ip：服务的群集IP地址。 （不适用于ExternalName类型的服务）
 __meta_kubernetes_service_external_name：服务的DNS名称。 （适用于ExternalName类型的服务）
 __meta_kubernetes_service_label_ <labelname>：服务对象的标签。
 __meta_kubernetes_service_name：服务对象的名称。
 __meta_kubernetes_service_port_name：目标服务端口的名称。
 __meta_kubernetes_service_port_number：目标的服务端口号。
 __meta_kubernetes_service_port_protocol：目标服务端口的协议。

、pod

pod角色发现所有pod并将其容器暴露为目标。 对于容器的每个声明端口，将生成单个目标。 如果容器没有指定端口，则会创建每个容器的无端口目标，以通过重新标记手动添加端口。

可用元标签：

 __meta_kubernetes_namespace：pod对象的命名空间。
 __meta_kubernetes_pod_name：pod对象的名称。
 __meta_kubernetes_pod_ip：pod对象的pod IP。
 __meta_kubernetes_pod_label_ <labelname>：pod对象的标签。
 __meta_kubernetes_pod_annotation_ <annotationname>：pod对象的注释。
 __meta_kubernetes_pod_container_name：目标地址指向的容器的名称。
 __meta_kubernetes_pod_container_port_name：容器端口的名称。
 __meta_kubernetes_pod_container_port_number：容器端口号。
 __meta_kubernetes_pod_container_port_protocol：容器端口的协议。
 __meta_kubernetes_pod_ready：对于pod的就绪状态，设置为true或false。
 __meta_kubernetes_pod_phase：在生命周期中设置为Pending，Running，Succeeded，Failed或Unknown。
 __meta_kubernetes_pod_node_name：将pod安排到的节点的名称。
 __meta_kubernetes_pod_host_ip：pod对象的当前主机IP。
 __meta_kubernetes_pod_uid：pod对象的UID。
 __meta_kubernetes_pod_controller_kind：对象类型的pod控制器。
 __meta_kubernetes_pod_controller_name：pod控制器的名称。

、endpoints

endpoints角色从列出的服务端点发现目标。 对于每个端点地址，每个端口发现一个目标。 如果端点由pod支持，则pod的所有其他容器端口（未绑定到端点端口）也会被发现为目标。

可用元标签：

 __meta_kubernetes_namespace：端点对象的命名空间。
 __meta_kubernetes_endpoints_name：端点对象的名称。对于直接从端点列表中发现的所有目标（不是从底层pod中另外推断的那些），附加以下标签：
 __meta_kubernetes_endpoint_ready：对端点的就绪状态设置为true或false。
 __meta_kubernetes_endpoint_port_name：端点端口的名称。
 __meta_kubernetes_endpoint_port_protocol：端点端口的协议。
 __meta_kubernetes_endpoint_address_target_kind：端点地址目标的种类。
 __meta_kubernetes_endpoint_address_target_name：端点地址目标的名称。

如果端点属于某个服务，则会附加角色：服务发现的所有标签。 对于由pod支持的所有目标，将附加角色的所有标签：pod发现。
ingress

ingress角色发现每个入口的每个路径的目标。 这通常用于黑盒监控入口。 地址将设置为入口规范中指定的主机。

可用元标签：

 __meta_kubernetes_namespace：入口对象的名称空间。
 __meta_kubernetes_ingress_name：入口对象的名称。
 __meta_kubernetes_ingress_label_ <labelname>：入口对象的标签。
 __meta_kubernetes_ingress_annotation_<annotationname>：入口对象的注释。
 __meta_kubernetes_ingress_scheme：入口的协议方案，如果设置了TLS配置，则为https。 默认为http。
 __meta_kubernetes_ingress_path：来自入口规范的路径。 默认为/。

有关Kubernetes发现的配置选项，请参见下文：

# 访问Kubernetes API的信息。

# API服务器地址。 如果保留为空，则假定Prometheus在集群内部运行并自动发现API服务器，并在/var/run/secrets/kubernetes.io/serviceaccount/上使用pod的CA证书和不记名令牌文件。
[ api_server: <host> ]

# 应该被发现的实体的Kubernetes角色。
role: <role>

# 用于向API服务器进行身份验证的可选身份验证信息。请注意，`basic_auth`，`bearer_token`和`bearer_token_file`选项是互斥的.password和password_file是互斥的。

# 可选的HTTP基本认证信息。
basic_auth:
  [ username: <string> ]
  [ password: <secret> ]
  [ password_file: <string> ]

# 可选的承载令牌认证信息。
[ bearer_token: <secret> ]

# 可选的承载令牌文件认证信息。
[ bearer_token_file: <filename> ]

# 可选的代理URL。
[ proxy_url: <string> ]

# TLS配置。
tls_config:
  [ <tls_config> ]

# 可选命名空间发现 如果省略，则使用所有名称空间。
namespaces:
  names:
    [ - <string> ]

其中<role>必须是endpoints，service，pod，node或ingress。

有关为Kubernetes配置Prometheus的详细示例，请参阅此示例Prometheus配置文件。

您可能希望查看第三方Prometheus操作，它可以在Kubernetes上自动执行Prometheus设置。

、static_config

static_config允许指定目标列表和它们的公共标签集。 这是在scrape配置中指定静态目标的规范方法。

 # 静态配置指定的目标。
 targets:
   [ - &#;<host>&#; ]
 
 # 分配给从目标中已抓取的所有指标的标签。
 labels:
   [ <labelname>: <labelvalue> ... ]

、relabel_config

重新标记是一个功能强大的工具，可以在目标的标签集被抓取之前重写它，每个采集配置可以配置多个重写标签设置，并按照配置的顺序来应用于每个目标的标签集。

目标重新标签之后，以__开头的标签将从标签集中删除的。

如果使用只需要临时的存储临时标签值的，可以使用_tmp作为前缀标识。

relabel的action类型

  • replace: regex匹配source_labels，替换为 replacement ，写入 target_label
  • keep：删除regex与source_labels不匹配的target
  • drop: 删除regex与source_labels匹配的target
  • labelmap: 对所有标签key进行regex匹配(不是source_labels)，将原标签的key替换为replacement指定的key，通常用于改写 __ 开头的标签
  • labeldrop: 对所有标签key进行regex匹配(不是source_labels)，匹配到的标签被删除(不是target被删除)
  • labelkeep: 对所有标签key进行regex匹配(不是source_labels)，不匹配到的标签被删除(不是target被删除)
  • hashmod: 当一个job中监控目标数量太多时(自动发现中容易出现)，将任务分散到不同的机器上。hashmod会将 source_labels值哈希后采用 modulus 取余数，并赋值到一个标签，然后在接下来的relabel中进行保留或者剔除，这样能实现每个prometheus采集一部分target数据

对于标签重写规则重点关注下。本节针对不同 action 进行 target 的标签重写，实验环境如下: 在 prometheus- 上启动三个 node_exporter 实例，分别监听 , , 端口，prometheus- 从这三个 node_exporter 中采集数据。

 [root@prometheus- ~]# jobs
 [1]   Running                 /opt/apps/node_exporter/node_exporter --log.level=error --web.listen-address=&#;:&#; &
 [2]-  Running                 /opt/apps/node_exporter/node_exporter --log.level=error --web.listen-address=&#;:&#; &
 [3]+  Running                 /opt/apps/node_exporter/node_exporter --log.level=error --web.listen-address=&#;:&#; &

、action: replace(默认)

重写规则之前：

 [root@prometheus- prometheus]# cat prometheus.yml 
 global:
   scrape_interval:     60s
   external_labels:
     monitor: &#;codelab-monitor&#;
 
 scrape_configs:
   - job_name: &#;node&#;
     static_configs:
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: dev
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: slave

添加新标签host，使其格式为: master-dev-

global:
  scrape_interval:     60s
  external_labels:
    monitor: &#;codelab-monitor&#;

scrape_configs:
  - job_name: &#;node&#;
    static_configs:
      - targets: [&#;:&#;]
        labels:
          app: app-
          env: dev
          role: master
      - targets: [&#;:&#;]
        labels:
          app: app-
          env: prod
          role: master
      - targets: [&#;:&#;]
        labels:
          app: app-
          env: prod
          role: slave
    relabel_configs:
      - source_labels: [&#;role&#;, &#;env&#;, &#;__address__&#;]
        target_label: host
        regex: (.+);(.+);([]{1,3}\.){3}([]+):[]+ # source_labels默认 ; 拼接
        replacement: $1-$2-$4


、action: keep

 global:
   scrape_interval:     60s
   external_labels:
     monitor: &#;codelab-monitor&#;
 
 scrape_configs:
   - job_name: &#;node&#;
     static_configs:
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: dev
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: slave
     relabel_configs:
       - source_labels: [&#;role&#;, &#;env&#;, &#;__address__&#;]
         target_label: host
         regex: (.+);(.+);([]{1,3}\.){3}([]+):[]+ # source_labels默认 ; 拼接
         replacement: $1-$2-$4
       - source_labels: [&#;env&#;]  # 仅保留 env=prod 的target
         regex: prod
         action: keep

、action: drop

 global:
   scrape_interval:     60s
   external_labels:
     monitor: &#;codelab-monitor&#;
 
 scrape_configs:
   - job_name: &#;node&#;
     static_configs:
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: dev
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: slave
     relabel_configs:
       - source_labels: [&#;role&#;, &#;env&#;, &#;__address__&#;]
         target_label: host
         regex: (.+);(.+);([]{1,3}\.){3}([]+):[]+ # source_labels默认 ; 拼接
         replacement: $1-$2-$4
       - source_labels: [&#;env&#;]  # 删除 lable_name 为env，切value为prod的target
         regex: prod
         action: drop

、action: labelkeep

尽量不要删除 __ 的标签，比如删了 __address__ 标签会导致 instance 生成异常，进而导致无法获取target信息

 [root@prometheus- prometheus]# cat prometheus.yml 
 global:
   scrape_interval:     60s
   external_labels:
     monitor: &#;codelab-monitor&#;
 
 scrape_configs:
   - job_name: &#;node&#;
     static_configs:
       - targets: [&#;:&#;]
         labels:
           app: app-
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: slave
     relabel_configs:
       - regex: (__|role).* # 非临时标签仅保留 role
         action: labelkeep

、action: labeldrop

 global:
   scrape_interval:     60s
   external_labels:
     monitor: &#;codelab-monitor&#;
 
 scrape_configs:
   - job_name: &#;node&#;
     static_configs:
       - targets: [&#;:&#;]
         labels:
           app: app-
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: slave
     relabel_configs:
       - regex: env  # 将env标签删除，并是上次target
         action: labeldrop

、action: labelmap

 global:
   scrape_interval:     60s
   external_labels:
     monitor: &#;codelab-monitor&#;
 
 scrape_configs:
   - job_name: &#;node&#;
     static_configs:
       - targets: [&#;:&#;]
         labels:
           app: app-
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: slave
     relabel_configs:
       - regex: __(.+)__ # 将所有双下划线的标签名改为非双下划线的标签名称
         action: labelmap

、action: hashmod

当一个job中监控目标数量太多时(自动发现中容易出现)，将任务分散到不同的机器上。hashmod会将 source_labels值哈希后采用 modulus 取余数，并赋值到一个标签，然后在接下来的relabel中进行保留或者剔除，这样能实现每个prometheus采集一部分target数据。下面案例中，其余后 __tmp_hash_value 值有 0、1、2，因此将target分为三组，可以由三个不同的prometheus去获取监控指标。

 global:
   scrape_interval:     60s
   external_labels:
     monitor: &#;codelab-monitor&#;
 
 scrape_configs:
   - job_name: &#;node&#;
     static_configs:
       - targets: [&#;:&#;]
         labels:
           app: app-
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: master
       - targets: [&#;:&#;]
         labels:
           app: app-
           env: prod
           role: slave
     relabel_configs:
       - source_labels: [&#;__address__&#;]
         action: hashmod
         modulus: 3
         target_label: __tmp_hash_value
       - source_labels: [__tmp_hash_value]
         regex: &#;0&#;
         action: drop

、metric_relabel_configs

Prometheus 从数据源拉取数据后，会对原始数据进行编辑

其中 metric_relabel_configs是 Prometheus 在保存数据前的最后一步标签重新编辑（relabel_configs）。所以，哪怕你将 metric_relabel_configs模块放在 job_name模块的最前端，Prometheus 解析编辑文件后，也会将 metric_relabel_configs放在最后。

metric_relabel_configs 模块和 relabel_config 模块很相似。metric_relabel_configs一个很常用的用途：将监控不需要的数据，直接丢掉，不在Prometheus 中保存。

一般用于：

  1. 删除不必要的指标。
  2. 从指标中删除敏感或不需要的标签。
  3. 添加、编辑或者修改指标的标签值或者标签格式。

、删除不需要的指标(metric)

prometheus 默认会将所有拉取到的 metrics 都写入自己的存储中。如果某些 metrics 对我们并没有太多意义，可以设置直接丢掉，减少磁盘空间的浪费。‘node_netstat_Icmp_OutMsgs’ 指标数据。

   metric_relabel_configs:
    - source_labels: [ __name__ ]
      regex: &#;node_netstat_Icmp_OutMsgs&#;
      action: drop

使用 source_labels 参数选择要要操作的指标，并且还需要一组标签名称。 示例中使用 __name__ 标签，此标签是标识指标名称的预留标签。

如上，我们丢掉指定job_name 中的

参考上面的配置，我们可以对指标(metric) 进行添加，删除，重命名等操作。

、修改指标(metric) 中的标签(label)

如果我们使用 prometheus 监控 Kubernetes 运行状态；应该会遇到，在一个 query 中结合一个以上的job_name(metric_source)的情况。 不同的job_name中metric的label命名可能不相同。比如：pod的名称可以使用“pod”或者“pod_name” 这两个 label 记录。如果相同含义的label，名称却不相同；对query的编写就很困难了。至少我没有在PromQL 中找到类似SQL 语句中的 as 的功能的关键词和方法。 这样的话，正确的解决思路应该是在 Prometheus 拉取数据后，保存数据前；将 label 的名称进行重写；保证相同含义的label 有相同的名称。

 metric_relabel_configs:
   - source_labels: [pod]
     separator: ;
     regex: (.+)
     target_label: pod_name
     replacement: $1
     action: replace
   - source_labels: [container]
     separator: ;
     regex: (.+)
     target_label: container_name
     replacement: $1
     action: replace

如上，将指定job_name中，所有的metrics中含有名为“pod”和“container”名称的label分别拷贝到名为“pod_name”，“container_name”的label中。 注意：如果metric 的 label的名称包含了“pod”和“container”关键词，但是不等于；则不会处理此label。

、删除标签

删除标签通常用于隐藏敏感信息或者简化时间序列。

   metric_relabel_configs:
   - regex: &#;kernelVersion&#;
     action: labeldrop

为了删除标签，我们指定了一个正则表达式，然后指定删除标签的操作labeldrop。 这将删除与正在表达式匹配的所有标签。

、remote_write

write_relabel_configs是在将样本发送到远程端点之前应用于样本的重新标记。 在外部标签之后应用写入重新标记。 这可用于限制发送的样本。

有一个如何使用此功能的小型演示。

 # 要发送样本的端点的URL.
 url: <string>
 
 # 对远程写端点的请求超时。
 [ remote_timeout: <duration> | default = 30s ]
 
 # 远程写入重新标记配置列表。
 write_relabel_configs:
   [ - <relabel_config> ... ]
 
 # 使用配置的用户名和密码在每个远程写请求上设置`Authorization`标头.password和password_file是互斥的。
 basic_auth:
   [ username: <string> ]
   [ password: <string> ]
   [ password_file: <string> ]
 
 # 使用配置的承载令牌在每个远程写请求上设置`Authorization`头。 它与`bearer_token_file`互斥。
 [ bearer_token: <string> ]
 
 # 使用配置的承载令牌在每个远程写请求上设置`Authorization`头。 它与`bearer_token`互斥。
 [ bearer_token_file: /path/to/bearer/token/file ]
 
 # 配置远程写入请求的TLS设置。
 tls_config:
   [ <tls_config> ]
 
 # 可选的代理URL。
 [ proxy_url: <string> ]
 
 # 配置用于写入远程存储的队列。
 queue_config:
   # 在我们开始删除之前每个分片缓冲的样本数。
   [ capacity: <int> | default =  ]
   # 最大分片数，即并发数。
   [ max_shards: <int> | default =  ]
   # 最小分片数，即并发数。
   [ min_shards: <int> | default = 1 ]
   # 每次发送的最大样本数。
   [ max_samples_per_send: <int> | default = ]
   # 样本在缓冲区中等待的最长时间。
   [ batch_send_deadline: <duration> | default = 5s ]
   # 在可恢复错误上重试批处理的最大次数。
   [ max_retries: <int> | default = 3 ]
   # 初始重试延迟。 每次重试都会加倍。
   [ min_backoff: <duration> | default = 30ms ]
   # 最大重试延迟。
   [ max_backoff: <duration> | default = 100ms ]

有一个与此功能集成的列表。

、remote_read

prometheus 可以从远程存储读取时间序列数据

 # 要发送样本的端点的URL.
 url: <string>
 
 # 可选的匹配器列表，必须存在于选择器中以查询远程读取端点。
 required_matchers:
   [ <labelname>: <labelvalue> ... ]
 
 # 对远程读取端点的请求超时。
 [ remote_timeout: <duration> | default = 1m ]
 
 # 本地存储应该有完整的数据。
 [ read_recent: <boolean> | default = false ]
 
 # 使用配置的用户名和密码在每个远程写请求上设置`Authorization`标头.password和password_file是互斥的。
 basic_auth:
   [ username: <string> ]
   [ password: <string> ]
   [ password_file: <string> ]
 
 # 使用配置的承载令牌在每个远程写请求上设置`Authorization`头。 它与`bearer_toke_filen`互斥。
 [ bearer_token: <string> ]
 
 # 使用配置的承载令牌在每个远程写请求上设置`Authorization`头。 它与`bearer_token`互斥。
 [ bearer_token_file: /path/to/bearer/token/file ]
 
 # 配置远程写入请求的TLS设置。
 tls_config:
   [ <tls_config> ]
 
 # 可选的代理URL。
 [ proxy_url: <string> ]

有一个与此功能集成的列表。

2、其他监控工具

在前言中，简单介绍了我们选择 Prometheus 的理由，以及使用后给我们带来的好处。

在这里主要和其他监控方案对比，方便大家更好的了解 Prometheus。

、Prometheus vs Zabbix

  • Zabbix 使用的是 C 和 PHP, Prometheus 使用 Golang, 整体而言 Prometheus 运行速度更快一点。
  • Zabbix 属于传统主机监控，主要用于物理主机，交换机，网络等监控，Prometheus 不仅适用主机监控，还适用于 Cloud, SaaS, Openstack，Container 监控。
  • Zabbix 在传统主机监控方面，有更丰富的插件。
  • Zabbix 可以在 WebGui 中配置很多事情，但是 Prometheus 需要手动修改文件配置。

、Prometheus vs Graphite

  • Graphite 功能较少，它专注于两件事，存储时序数据， 可视化数据，其他功能需要安装相关插件，而 Prometheus 属于一站式，提供告警和趋势分析的常见功能，它提供更强的数据存储和查询能力。
  • 在水平扩展方案以及数据存储周期上，Graphite 做的更好。

、Prometheus vs InfluxDB

  • InfluxDB 是一个开源的时序数据库，主要用于存储数据，如果想搭建监控告警系统， 需要依赖其他系统。
  • InfluxDB 在存储水平扩展以及高可用方面做的更好, 毕竟核心是数据库。

、Prometheus vs OpenTSDB

  • OpenTSDB 是一个分布式时序数据库，它依赖 Hadoop 和 HBase，能存储更长久数据， 如果你系统已经运行了 Hadoop 和 HBase, 它是个不错的选择。
  • 如果想搭建监控告警系统，OpenTSDB 需要依赖其他系统。

、Prometheus vs Nagios

  • Nagios 数据不支持自定义 Labels, 不支持查询，告警也不支持去噪，分组, 没有数据存储，如果想查询历史状态，需要安装插件。
  • Nagios 是上世纪 年代的监控系统，比较适合小集群或静态系统的监控，显然 Nagios 太古老了，很多特性都没有，相比之下Prometheus 要优秀很多。

、Prometheus vs Sensu

  • Sensu 广义上讲是 Nagios 的升级版本，它解决了很多 Nagios 的问题，如果你对 Nagios 很熟悉，使用 Sensu 是个不错的选择。
  • Sensu 依赖 RabbitMQ 和 Redis，数据存储上扩展性更好。
原文链接：，转发请注明来源！
七桃资源网 › 技术文章 › Prometheus配置文件_Kubernetes