Prometheus 后續雜記

在后續prometheus的使用中遇到的一些問題我會在此記錄

搭建初期幾個問題

rule.yml中對每條告警加上主機名？

要在告警通知中加上故障機器主機名不能從prometheus的采集監控項數據中的主機名入手，需要prometheus添加主機名target，即instance="hostname:port"，而不是instance="ip:port"。主機名的解析可在/etc/hosts添加或自行搭建dns服務器。在告警中引用instance變量，即實現此需求。

如何實現告警通知人分組，再在配置文件中引用組名？

只能在alertmanager配置中加。除非自己寫webhook。

對prometheus的數值保留兩位小數？

可以通過函數保留整數，ceil()將樣本值向上保留一位整數。

報警模板

在alermanager.yml 中可以帶入告警信息的模板文件

默認模板
https://github.com/prometheus/alertmanager/blob/master/template/default.tmpl

自定義模板

模板1:
{{ define "wechat.default.message" }}{{ if gt (len .Alerts.Firing) 0 -}}{{ range .Alerts }}Alerts Firing:{{ .Labels.severity }} / {{ .Labels.instance }} / {{ .Annotations.summary }} / {{ .StartsAt.Format "2006-01-02 15:04:05" }}{{- end }}{{- end }}{{ if gt (len .Alerts.Resolved) 0 -}}{{ range .Alerts }}Alerts Resolved:{{ .Labels.severity }} / {{ .Labels.instance }} / [ {{ .Annotations.summary }} ]Restored / {{ .StartsAt.Format "2006-01-02 15:04:05" }}{{- end }}{{- end }}{{- end }}

模板2:
以下是我企業微信告警的模板配置(極度簡化)：
{{ define "wechat.default.message" }}{{ if gt (len .Alerts.Firing) 0 -}}{{ range .Alerts }}
warning: {{ .Labels.hostname }} {{ .Labels.instance }} {{ .Annotations.summary }} {{- end }}{{- end }}{{ if gt (len
.Alerts.Resolved) 0 -}}{{ range .Alerts }}
Resolved: {{ .Labels.hostname }} {{ .Labels.instance }} {{ .Annotations.summary }} {{- end }}{{- end }}{{- end }}

告警實例:
warning: centos_CcbDbS_d3378 10.0.0.80 /data 91%

模板3：
{{ define "wechat.default.message" }}
{{ range .Alerts }}
start==
告警程序：prometheus_alert
告警級別：{{ .Labels.severity }}
告警類型：{{ .Labels.alertname }}
故障主機: {{ .Labels.instance }}
告警主題: {{ .Annotations.summary }}
告警詳情: {{ .Annotations.description }}
觸發時間: {{ .StartsAt.Format "2006-01-02 15:04:05" }}
end==
{{ end }}
{{ end }}

promql 函數

1. 使用increase 計算累計監控項1h內的增量，監控取值都為整數，為什么increase處理后有小數？

   increase() 函數獲取區間向量中的第一個和最后一個樣本並返回其增長量, 它會在單調性發生變化時(如由於采樣目標重啟引起的計數器復位)自動中斷。由於這個值被外推到指定的整個時間范圍，所以即使樣本值都是整數，你仍然可能會得到一個非整數值。也就是它會根據第一個與最后一個樣本的增長量與兩個取樣點時間長度而估算出函數中所設定的時間長度對應的增長量。

2. rate與irate區別
   取自：https://www.zhukun.net/archives/8301
   rate() 函數計算某個時間序列范圍內的每秒平均增長率，基於設定范圍內的第一個和最后一個數據點來計算每秒比率(允許計數器重置)，(last值-first值)/時間差。自適應單調性中斷(比如target重啟導致的計數器重置)，計算結果是推算到每個時間范圍的最后而得出, 允許漏抓和抓取周期與時間范圍的不完美結合，rate應該只和計數器一起使用。最適合告警和緩慢計數器的繪圖，數據曲線較緩和。

   irate() 函數計算一段時間范圍內某個時刻的每秒增長率，它只觀測設定的范圍內的最后兩個點，並計算每秒的速率，(last值-last前一個值)/時間戳差值. 自適應單調性中斷(比如target重啟導致的計數器重置).irate應該只和快速的, 不穩定的計數器一起使用。irate繪圖更精准。如果irate只需要最近兩個點的數據，那為什么我們要傳比這兩個點長得多的時間范圍呢？答案是，你想要限制這兩點的取值范圍，因為你不希望使用幾個小時前的數據。還有另外一個好處，在面板(dashboards)選擇比率范圍(rate range)時，不需要考慮所有可能的拉取間隔(scrape intervals)。因為那樣做通常會導致計算的時間比需要的長得多。如果拉取動作(scrape)變得更頻繁，圖像會自動提高分辨率。
   

alertmanager.yml中route分組告警走向

這個地方比較坑，你以為同一個告警信息匹配到的每個receiver都會發消息，其實，並不是！！！告警會自動從上級路由走到下級路由，下級路由會覆蓋上級路由的設置，同級路由加上continue: true 才會繼續往之后的同級路由匹配，並給所有匹配到的同級路由的receiver發信息。

舉個栗子喲：

以上有三個receiver，以下有三台主機，他們的告警信息該發給誰？：
主機1（廣告項目的mysql機子）標簽 type: mysql job: adv；
主機2（廣告項目代理機子）標簽 type: ngx job: adv;
主機3 (其他項目的代理機子) 標簽 type: ngx job: other

分析：
主機1：發給dba，下級路由匹配到標簽type: mysql，雖然還有一個job: adv同級路由能匹配，但是同級路由匹配到一個之后不會自動匹配下一個；
主機2：發給adv；
主機3：發給yunwei，下級路由不能匹配到，故不會覆蓋主路由的receiver。

以下配置發送主機1告警給三個receiver ：

route:
  group_interval: 15s
  repeat_interval: 1h
  group_by: ['alertname']
  receiver: 'yunwei'
  routes:
  - match:                       #這三行表示：match下不寫標簽，就是match所有標簽，即所有報警信息都發給yunwei組
    continue: true            #continue 匹配到此規則的告警能繼續同級routes匹配，並對同級中匹配到的所有receiver發送告警
    receiver: 'yunwei'
  - match:
      type: mysql
    continue: true    ####
    receiver: 'dba'
  - match:
      job: adv
    continue: true
    receiver: 'adv'

template的引用

參考：https://prometheus.io/docs/alerting/configuration/
在alertmanager中可以做到不同receiver使用不同的模板
模板1

{{ define "wechat_simple.html" }}{{ if gt (len .Alerts.Firing) 0 -}}{{ range .Alerts }}Alerts Firing:{{ .Labels.severity }} / {{ .Labels.hostname }} / {{ .Annotations.summary }} / {{ .StartsAt.Format "2006-01-02 15:04:05" }}{{- end }}{{- end }}{{ if gt (len .Alerts.Resolved) 0 -}}{{ range .Alerts }}Alerts Resolved:{{ .Labels.severity }}  / {{ .Labels.hostname }} / [ {{ .Annotations.summary }} ]Restored / {{ .StartsAt.Format "2006-01-02 15:04:05" }}{{- end }}{{- end }}{{- end }}

模板2

{{ define "wechat_detail.html" }}
{{ if gt (len .Alerts.Firing) 0 -}}
Alerts Firing:
{{ range .Alerts }}
告警級別：{{ .Labels.severity }}
告警類型：{{ .Labels.alertname }}
Alert：   {{ .Labels.test }}
故障主機: {{ .Labels.instance }}
告警主題: {{ .Annotations.summary }}
告警詳情: {{ .Annotations.description }}
觸發時間: {{ .StartsAt.Format "2006-01-02 15:04:05" }}
{{- end }}
{{- end }}
{{ if gt (len .Alerts.Resolved) 0 -}}
Alerts Resolved:
{{ range .Alerts }}
告警級別：{{ .Labels.severity }}
告警類型：{{ .Labels.alertname }}
故障主機: {{ .Labels.instance }}
告警主題: {{ .Annotations.summary }}
觸發時間: {{ .StartsAt.Format "2006-01-02 15:04:05" }}
恢復時間: {{ .EndsAt.Format "2006-01-02 15:04:05" }}
{{- end }}
{{- end }}
告警鏈接:
{{ template "__alertmanagerURL" . }}
{{- end }}

alertmanager.yml 配置

global:
  resolve_timeout: 1m 
templates:
  - '/usr/local/alertmanager/template/*.tmpl'   #此處需要將以上兩個模板文件引用進來
route:
  group_interval: 15s
  repeat_interval: 1m
  group_by: ['alertname']
  receiver: 'wechat1'
  routes:
  - receiver: 'wechat2'
    match:
        for: 'test'
receivers:
- name: 'wechat1'
  wechat_configs:
  - corp_id: 'wx8659xxxxxx'
    send_resolved: true
    message: '{{ template "wechat_simple.html" . }}'  #此參數可引用模板文件
    to_user: 'jor|Ya'
    agent_id: '10000xx'
    api_secret: '3igxxxxxxxxOg'
- name: 'wechat2'
  wechat_configs:
  - corp_id: 'wxxxxxxx06e'
    send_resolved: true
    message: '{{ template "wechat_detail.html" . }}'
   # to_party: 'jorney'
    to_user: 'joy|Yn'
    agent_id: '1000xxx'
    api_secret: '3igMMxxxxxxxx'

windows安裝exporter

https://github.com/martinlindhe/wmi_exporter/releases/download/v0.3.3/wmi_exporter-0.3.3-amd64.msi
雙擊安裝，應該是會自動開機啟動（不確定），端口 9182
獲取數據：ip:9182/metrics

內存使用率

今天我看到一個計算prometheus內存使用率的表達式是這樣：

(1-((node_memory_Buffers_bytes+node_memory_Cached_bytes+node_memory_MemFree_bytes)/node_memory_MemTotal_bytes))*100

用命令行查看某機器的內存使用情況

[root@one nginx]# free -m            
                      total        used        free      shared  buff/cache   available
Mem:           3530        1801          58         354        1670        1179

神奇的事情發生了：buff/cache 大於available，一般來說 available=free + buff/cache
一查資料發現有這么一句：如果free內存不夠用，，系統會回收buff和cache內存。但是因為內核的buff和cache不能回收，所以available <= free + buff/cache，用avaiblable算出的使用率會大於幾項相加之和的使用率。

所以內存使用率用available來計算是不是更准確呢？

(1-((node_memory_MemAvailable_bytes)/node_memory_MemTotal_bytes))*100

新發現的問題：
node_memory_MemAvailable_bytes指標centos7有，centos6沒有，所以第一種表達式對兩個系統都適用，但是兩種算法的值會有出入。

blackbox_exporter 監控url 狀態返回碼為0

使用blackbox_exporter 監控url,curl -i $url 返回碼為302，但是收集的監控項值為0.
因為沒有加重定向相關配置“no_follow_redirects: true”，默認是false。