prometheus配置看着一篇就够了

prometheus_config

配置热加载：
#1.  kill -HUP pid
#2.  curl -X POST http://IP/-/reload

job_name

• 如果一个job里有多台主机，只需要在targets里配置多个ip和端口即可，使用逗号隔开
• 过滤不需要收集的指标。 如下，只收集和返回cpu和内存相关的指标

- job_name: 'node'
    static_configs:
    - targets: ['192.168.68.17:9100']
    params:
      collect[]:
        - cpu
        - meminfo

• 每次增加 Target 时会自动增加一个 instance 标签，而 instance 标签的内容刚好对应 Target 实例的 address 值
• honor_labels主要用于解决prometheus server的label与exporter端用户自定义label冲突的问题

看看官方怎么说：

#If honor_labels is set to "true", label conflicts are resolved by keeping label
# values from the scraped data and ignoring the conflicting server-side labels.
#
# If honor_labels is set to "false", label conflicts are resolved by renaming
# conflicting labels in the scraped data to "exported_" (for
# example "exported_instance", "exported_job") and then attaching server-side
# labels. This is useful for use cases such as federation, where all labels
# specified in the target should be preserved.

relabel_config

看官网说明 看官网例子
路人理解：relabel_config发生在抓取之前，metric_relabel_configs发生在抓取之后

重新标记，可以在目标的标签集被抓取之前重写它，每个采集配置可以配置多个重写标签设置，并按照配置的顺序来应用于每个目标的标签集。
Relabel 的配置允许你选择你想抓取的目标和这些目标的标签是什么。所以说如果你想要抓取这种类型的服务器而不是那种，可以使用relabel_configs

source_labels指定需要处理的源标签
target_labels指定要replace后的标签名字
action指定relabel动作，这里使用replace替换动作
regex去匹配源标签（__hostname__）的值，"(.*)"代表__hostname__这个标签是什么值都匹配的
replacement指定的替换后的标签（target_label）对应的数值

系统使用的标签
	__address__：		当前Target实例的访问地址[host]:[port]
	__scheme__：		采集目标服务访问地址的HTTP Scheme，HTTP或者HTTPS
	__metrics_path__：	采集目标服务访问地址的访问路径
	__param_：			采集任务目标服务的中包含的请求参数
	__name__: 			此标签是标识指标名称的预留标签

action:
	replace:   对标签和标签值进行替换。
	keep: 	   满足特定条件的实例进行采集，其他的不采集。
	drop： 	   满足特定条件的实例不采集，其他的采集。
	hashmod：  将 target_label 设置为关联的 source_label 的哈希模块。
	labelmap： 根据 regex 去匹配 Target 实例所有标签的名称（注意是名称），并且将捕获到的内容作为为新的标签名称，regex 匹配到标签的的值作为新标签的值。
	labeldrop：对抓取的实例特定标签进行删除。
	labelkeep：对抓取的实例特定标签进行保留，其他标签删除。

标签其实可以理解是一个key-value对组成。
默认的：
	target的job标签设置为配置文件里的job_name的值；
	__address__设置为配置里的targets的值；
	而instance标签的值,是重定义标签操作之后__address__的值，instance的值会比__address__多一个端口号 ；
	__scheme__和__metrics_path__标签的值,也是从配置里取值的;
	__param_>标签的值,是传给URL的查询参数>的值;

relabel_configs:
  - source_labels: [__address__]
    target_label: __param_target
  - source_labels: [__param_target]
    target_label: instance
  - target_label: __address__
    replacement: 192.168.56.200:9116 # snmp_exporter 服务IP地址
上面example的作用就是把 __address__标签替换成__param_target，value不变，只不过是key变了，
最后的 replacement 表示把标签__address__的value替换成 192.168.56.200:9116

在scrape_configs标签下，params.module中可以配置需要抓取的模块，不配置表示全部抓取。

rule_config

需要将指标做相应计算后再进行返回。这时候我们就需要添加记录规则

alert_config

• global

全局配置，主要配置告警方式，如邮件、webhook

• route

prometheus的告警先是到达alertmanager的根路由(route)，alertmanager的根路路由不能包含任何匹配项，因为根路由是所有告警的入口点。另外,根路由需要匹配一个接收器(receiver),用来处理哪些没有匹配到任何子路由的告警（如果没有配置子路由，则全部由根路由发送告警）

• group_by

用于分组聚合，对告警通知按标签(label)进行分组，将具有相同标签或相同告警名称(alertname)的告警通知
聚合在一个组，然后作为一个通知发送。如果想完全禁用聚合，可以设置为group_by:[…]

• group_wait

当一个新的告警组被创建时，需要等待’group_wait’后才发送初始通知。这样可以确保在发送等待前能收集更
多具有相同标签的告警，最后合并为一个通知发送

cat > alertmanager.yml <global:
  resolve_timeout: 5m
route:
  receiver: webhook
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [alertname]
  routes:
  - receiver: webhook
    group_wait: 10s
    match:
      team: node
receivers:
- name: webhook
  webhook_configs:
  - url: 'http://apollo/hooks/dingtalk/'
    send_resolved: true
  - url: 'http://apollo/hooks/prome/'
    send_resolved: true
EOF

cat > /usr/lib/systemd/system/alertmanager.service <[Unit]
Description=alertmanager

[Service]
ExecStart=/root/go/bin/alertmanager --config.file=/root/go/bin/config.yml --storage.path=/usr/local/alertmanager/data --web.listen-address=:9093 --data.retention=120h
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF