一篇帶你了解 Thanos Ruler 組件的使用
Thano Ruler 組件是用于評(píng)估 Prometheus 的記錄規(guī)則和報(bào)警規(guī)則的組件，其本身不會(huì)抓取 metrics 接口數(shù)據(jù)，而是通過 Query API 從 query 組件定期地獲取指標(biāo)數(shù)據(jù)，如果配置了多個(gè) query 地址，則會(huì)采用輪詢方式獲取。
其中記錄規(guī)則評(píng)估生成的數(shù)據(jù)會(huì)保存在本地，并且定期地掃描本地生成的 TSDB 數(shù)據(jù)塊上傳到對(duì)象存儲(chǔ)桶中作為歷史數(shù)據(jù)長期保存。同時(shí)也實(shí)現(xiàn)了 Store API 可用于查詢本地保存的數(shù)據(jù)。與 Prometheus 節(jié)點(diǎn)類似，每個(gè) ruler 節(jié)點(diǎn)都使用獨(dú)立的存儲(chǔ)，可以同時(shí)運(yùn)行多個(gè)副本，而且需要為每個(gè)副本實(shí)例分配不同的標(biāo)簽以作區(qū)分，因?yàn)?store 組件在查詢對(duì)象存儲(chǔ)中的歷史數(shù)據(jù)時(shí)是以該標(biāo)簽進(jìn)行分組查詢的。
安裝
由于 ruler 組件也實(shí)現(xiàn)了 Store API，所以我們也可以直接將該組件對(duì)接到 store 組件中去，只需要給創(chuàng)建的 Pod 帶上 thanos-store-api: "true" 這個(gè)標(biāo)簽即可(Service 會(huì)進(jìn)行自動(dòng)關(guān)聯(lián))被 query 組件服務(wù)發(fā)現(xiàn)。
整體上我們可以把 ruler 節(jié)點(diǎn)理解為一個(gè)簡(jiǎn)單的 Prometheus 節(jié)點(diǎn)，只是不需要 thanos sidecar，不抓取指標(biāo)數(shù)據(jù)，只負(fù)責(zé)執(zhí)行 PromQL 查詢，由于本身會(huì)保留獨(dú)立的存儲(chǔ)，所以同樣這里我們需要做數(shù)據(jù)的持久化。
然后可以通過部署兩個(gè)副本來實(shí)現(xiàn)高可用，這里我們添加了一個(gè) --label=rule_replica 標(biāo)簽來給數(shù)據(jù)添加一個(gè) rule_replica 的標(biāo)簽, 同時(shí)指定 --alert.label-drop 為 rule_replica，這樣在觸發(fā)告警發(fā)送通知給 AlertManager 時(shí)可以去掉這個(gè) label，以便讓 AlertManager 自動(dòng)去重，可以避免重復(fù)告警。
然后通過 --query 參數(shù)指定 query 組件地址，我們這里還是使用 DNS SRV 來做服務(wù)發(fā)現(xiàn)，這樣就可以從查詢組件中獲取指標(biāo)數(shù)據(jù)了。
ruler 同樣也需要對(duì)象存儲(chǔ)的配置，用于上傳計(jì)算出的數(shù)據(jù)到對(duì)象存儲(chǔ)，所以要掛載對(duì)象存儲(chǔ)的配置文件。--rule-file 參數(shù)可以用來指定掛載的 rule 配置，ruler 組件會(huì)根據(jù)配置來生成數(shù)據(jù)和觸發(fā)報(bào)警。
完整的資源清單文件如下所示：
# thanos-ruler.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: thanos-ruler
namespace: kube-mon
labels:
app: thanos-ruler
spec:
replicas: 2
selector:
matchLabels:
app: thanos-ruler
serviceName: thanos-rule
podManagementPolicy: Parallel
template:
metadata:
labels:
app: thanos-ruler
thanos-store-api: "true"
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- thanos-ruler
containers:
- name: thanos-ruler
image: thanosio/thanos:v0.25.1
args:
- rule
- --grpc-address=0.0.0.0:10901
- --http-address=0.0.0.0:10902
- --rule-file=/etc/thanos/rules/*rules.yaml
- --objstore.config-file=/etc/secret/thanos.yaml
- --data-dir=/var/thanos/rule
- --label=rule_replica="$(NAME)"
- --alert.label-drop=rule_replica
- --query=dnssrv+_http._tcp.thanos-querier.kube-mon.svc.cluster.local
ports:
- containerPort: 10901
name: grpc
- containerPort: 10902
name: http
env:
- name: NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
livenessProbe:
httpGet:
path: /-/healthy
port: 10902
scheme: HTTP
readinessProbe:
httpGet:
path: /-/ready
port: 10902
scheme: HTTP
volumeMounts:
- mountPath: /var/thanos/rule
name: data
readOnly: false
- name: object-storage-config
mountPath: /etc/secret
readOnly: false
- name: thanos-rules
mountPath: /etc/thanos/rules
volumes:
- name: object-storage-config
secret:
secretName: thanos-objectstorage
- name: thanos-rules
configMap:
name: thanos-rules
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes:
- ReadWriteOnce
storageClassName: longhorn
resources:
requests:
storage: 1Gi
要注意上面掛載的對(duì)象存儲(chǔ)配置的 Secret，另外還需要通過一個(gè) ConfigMap 來配置 rules 規(guī)則：
# thanos-rules-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: thanos-rules
namespace: kube-mon
data:
record.rules.yaml: |-
groups:
- name: k8s.rules
rules:
- expr: |
sum(rate(container_cpu_usage_seconds_total{job="cadvisor", image!="", container!=""}[5m])) by (namespace)
record: namespace:container_cpu_usage_seconds_total:sum_rate
- expr: |
sum(container_memory_usage_bytes{job="cadvisor", image!="", container!=""}) by (namespace)
record: namespace:container_memory_usage_bytes:sum
- expr: |
sum by (namespace, pod, container) (
rate(container_cpu_usage_seconds_total{job="cadvisor", image!="", container!=""}[5m])
)
record: namespace_pod_container:container_cpu_usage_seconds_total:sum_rate
這里我們簡(jiǎn)單配置了幾個(gè)記錄規(guī)則，配置方式和之前的規(guī)則一樣的。然后直接創(chuàng)建上面的資源對(duì)象即可：
? ? kubectl apply -f https://p8s.io/docs/thanos/manifests/thanos-rules-config-0.yaml
? ? kubectl apply -f https://p8s.io/docs/thanos/manifests/thanos-ruler-0.yaml
? ? kubectl get pods -n kube-mon -l app=thanos-ruler
NAME READY STATUS RESTARTS AGE
thanos-ruler-0 1/1 Running 0 16m
thanos-ruler-1 1/1 Running 0 16m
部署完成后我們可以去查看 query 組件頁面的 store 信息是否包含上面的 ruler 實(shí)例：
同樣在 rules 頁面可以看到我們定義的記錄規(guī)則信息：
現(xiàn)在我們可以嘗試去查詢下上面的記錄規(guī)則，比如查詢 namespace:container_cpu_usage_seconds_total:sum_rate：
可以看到可以正常獲取到這條記錄規(guī)則的數(shù)據(jù)。
對(duì)接告警
如果要進(jìn)行報(bào)警，首先我們需要通過啟動(dòng)參數(shù) --alertmanagers.url 來指定 Alertmanager 的地址，如果需要更高級(jí)的配置，可以通過啟動(dòng)參數(shù) --alertmanagers.config 或者 --alertmanagers.config-file 來指定對(duì)接 Alertmanager 的配置，格式如下所示：
alertmanagers:
- http_config:
basic_auth:
username: ""
password: ""
password_file: ""
bearer_token: ""
bearer_token_file: ""
proxy_url: ""
tls_config:
ca_file: ""
cert_file: ""
key_file: ""
server_name: ""
insecure_skip_verify: false
static_configs: []
file_sd_configs:
- files: []
refresh_interval: 0s
scheme: http
path_prefix: ""
timeout: 10s
api_version: v1
比如我們這里對(duì)接前面章節(jié)中的 Alertmanager，則直接這上面的資源對(duì)象容器啟動(dòng)參數(shù)中增加 - --alertmanagers.url=http://alertmanager:9093 即可。然后在上面的 thanos-rules 的 ConfigMap 中新增一個(gè) alert.rules.yaml 的配置，用來配置報(bào)警規(guī)則，如下所示：
# thanos-rules-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: thanos-rules
namespace: kube-mon
data:
record.rules.yaml: |-
# ......
alert.rules.yaml: |-
groups:
- name: test-node-mem
rules:
- alert: NodeMemoryUsage
expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 30
for: 1m
labels:
team: node
severity: critical
annotations:
summary: "{{$labels.instance}}: High Memory usage detected"
description: "{{$labels.instance}}: Memory usage is above 30% (current value is: {{ $value }})"
直接更新上面的兩個(gè)資源對(duì)象即可：
更新完成后這 query 的 rules 頁面也可以看到上面新增的報(bào)警規(guī)則了，因?yàn)槲覀儾渴鸬氖莾蓚€(gè)副本，所以能看到兩條一樣的規(guī)則：
? ? kubectl apply -f https://p8s.io/docs/thanos/manifests/thanos-rules-config.yaml
? ? kubectl apply -f https://p8s.io/docs/thanos/manifests/thanos-ruler.yaml
由于我們這 ruler 組件啟動(dòng)參數(shù)中配置了參數(shù) - --alert.label-drop=rule_replica，所以 Alertmanager 中不會(huì)收到重復(fù)報(bào)警，不過需要注意的是經(jīng)測(cè)試這里的 rule_replica 不能加引號(hào)，加上引號(hào)會(huì)去重失效，我們可以前往 Alertmanager 查看觸發(fā)的報(bào)警信息：
由于 ruler 組件獲取評(píng)估數(shù)據(jù)的路徑是 ruler --> query --> sidecar --> prometheus，需要經(jīng)整個(gè)查詢鏈條，這也提升了發(fā)生故障的風(fēng)險(xiǎn)，而且評(píng)估原本就可以在 Prometheus 中進(jìn)行，所以在非必要的情況下更加推薦使用原本的 Prometheus 方式來做報(bào)警和記錄規(guī)則的評(píng)估。
