Prometheus 監(jiān)控系統(tǒng)：30個常見問題（下）

點擊“程序員面試吧”，選擇“星標??”

點擊文末“閱讀原文”解鎖資料！

十六、Prometheus 重啟慢與熱加載

Prometheus 重啟的時候需要把 Wal 中的內(nèi)容 Load 到內(nèi)存里，保留時間越久、Wal 文件越大，重啟的實際越長，這個是 Prometheus 的機制，沒得辦法，因此能 Reload 的就不要重啟，重啟一定會導(dǎo)致短時間的不可用，而這個時候Prometheus高可用就很重要了。

Prometheus 也曾經(jīng)對啟動時間做過優(yōu)化，在 2.6 版本中對于Wal的 Load 速度就做過速度的優(yōu)化，希望重啟的時間不超過 1 分鐘

Prometheus 提供了熱加載能力，不過需要開啟web.enable-lifecycle配置，更改完配置后，curl 下 reload 接口即可。prometheus-operator 中更改了配置會默認觸發(fā) reload，如果你沒有使用operator，又希望可以監(jiān)聽 configmap 配置變化來 reload 服務(wù)，可以試下這個簡單的腳本

#!/bin/shFILE=$1URL=$2HASH=$(md5sum $(readlink -f $FILE))while true; do   NEW_HASH=$(md5sum $(readlink -f $FILE))   if [ "$HASH" != "$NEW_HASH" ]; then     HASH="$NEW_HASH"     echo "[$(date +%s)] Trigger refresh"     curl -sSL -X POST "$2" > /dev/null   fi   sleep 5done

使用時和 prometheus 掛載同一個 configmap，傳入如下參數(shù)即可：

args:    - /etc/prometheus/prometheus.yml    - http://prometheus.kube-system.svc.cluster.local:9090/-/reloadargs:    - /etc/alertmanager/alertmanager.yml    - http://prometheus.kube-system.svc.cluster.local:9093/-/reload

十七、你的應(yīng)用需要暴露多少指標

當你開發(fā)自己的服務(wù)的時候，你可能會把一些數(shù)據(jù)暴露 Metric出去，比如特定請求數(shù)、Goroutine 數(shù)等，指標數(shù)量多少合適呢？

雖然指標數(shù)量和你的應(yīng)用規(guī)模相關(guān)，但也有一些建議(Brian Brazil),

比如簡單的服務(wù)如緩存等，類似 Pushgateway，大約 120 個指標，Prometheus 本身暴露了 700 左右的指標，如果你的應(yīng)用很大，也盡量不要超過 10000 個指標，需要合理控制你的 Label。

十八、node-exporter 的問題

• node-exporter 不支持進程監(jiān)控，這個前面已經(jīng)提到了。

• node-exporter 只支持 unix 系統(tǒng)，windows機器 請使用 wmi_exporter。因此以 yaml 形式不是 node-exporter 的時候，node-selector 要表明os類型。

• 因為node_exporter是比較老的組件，有一些最佳實踐并沒有merge進去，比如符合Prometheus命名規(guī)范，因此建議使用較新的0.16和0.17版本。

一些指標名字的變化：

* node_cpu ->  node_cpu_seconds_total* node_memory_MemTotal -> node_memory_MemTotal_bytes* node_memory_MemFree -> node_memory_MemFree_bytes* node_filesystem_avail -> node_filesystem_avail_bytes* node_filesystem_size -> node_filesystem_size_bytes* node_disk_io_time_ms -> node_disk_io_time_seconds_total* node_disk_reads_completed -> node_disk_reads_completed_total* node_disk_sectors_written -> node_disk_written_bytes_total* node_time -> node_time_seconds* node_boot_time -> node_boot_time_seconds* node_intr -> node_intr_total

如果你之前用的舊版本 exporter，在繪制 grafana 的時候指標名稱就會有差別，解決方法有兩種：

• 一是在機器上啟動兩個版本的node-exporter，都讓prometheus去采集。

• 二是使用指標轉(zhuǎn)換器,他會將舊指標名稱轉(zhuǎn)換為新指標

十九、kube-state-metric 的問題

kube-state-metric 的使用和原理可以先看下這篇

除了文章中提到的作用，kube-state-metric還有一個很重要的使用場景，就是和 cadvisor 指標組合，原始的 cadvisor 中只有 pod 信息，不知道屬于哪個 deployment 或者 sts，但是和kube-state-metric 中的 kube_pod_info 做 join 查詢之后就可以顯示出來，kube-state-metric的元數(shù)據(jù)指標，在擴展 cadvisor 的 label 中起到了很多作用，prometheus-operator 的很多 record rule 就使用了 kube-state-metric 做組合查詢。

kube-state-metric 中也可以展示 pod 的 label 信息，可以在拿到 cadvisor 數(shù)據(jù)后更方便地做 group by，如按照 pod 的運行環(huán)境分類。但是 kube-state-metric 不暴露 pod 的 annotation，原因是下面會提到的高基數(shù)問題，即 annotation 的內(nèi)容太多，不適合作為指標暴露。

二十、relabel_configs 與 metric_relabel_configs

relabel_config 發(fā)生在采集之前，metric_relabel_configs 發(fā)生在采集之后，合理搭配可以滿足很多場景的配置。

如：

metric_relabel_configs:  - separator: ;    regex: instance    replacement: $1    action: labeldrop

- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_endpoints_name,      __meta_kubernetes_service_annotation_prometheus_io_port]    separator: ;    regex: (.+);(.+);(.*)    target_label: __metrics_path__    replacement: /api/v1/namespaces/${1}/services/${2}:${3}/proxy/metrics    action: replace

二十一、找到最大的 metric 或 job

top10的 metric 數(shù)量：按 metric 名字分

topk(10, count by (__name__)({__name__=~".+"}))
apiserver_request_latencies_bucket{}  62544apiserver_response_sizes_bucket{}   44600

top10的 metric 數(shù)量：按 job 名字分

topk(10, count by (__name__, job)({__name__=~".+"}))
{job="master-scrape"}   525667{job="xxx-kubernetes-cadvisor"}  50817{job="yyy-kubernetes-cadvisor"}   44261

二十二、反直覺的 P95 統(tǒng)計

histogram_quantile 是 Prometheus 常用的一個函數(shù)，比如經(jīng)常把某個服務(wù)的 P95 響應(yīng)時間來衡量服務(wù)質(zhì)量。不過它到底是什么意思很難解釋得清，特別是面向非技術(shù)的同學(xué)，會遇到很多“靈魂拷問”。

我們常說 P95（P99,P90都可以） 響應(yīng)延遲是 100ms，實際上是指對于收集到的所有響應(yīng)延遲，有 5% 的請求大于 100ms，95% 的請求小于 100ms。Prometheus 里面的 histogram_quantile 函數(shù)接收的是 0-1 之間的小數(shù)，將這個小數(shù)乘以 100 就能很容易得到對應(yīng)的百分位數(shù)，比如 0.95 就對應(yīng)著 P95，而且還可以高于百分位數(shù)的精度，比如 0.9999。

當你用 histogram_quantile 畫出響應(yīng)時間的趨勢圖時，可能會被問：為什么P95大于或小于我的平均值？

正如中位數(shù)可能比平均數(shù)大也可能比平均數(shù)小，P99 比平均值小也是完全有可能的。通常情況下 P99 幾乎總是比平均值要大的，但是如果數(shù)據(jù)分布比較極端，最大的 1% 可能大得離譜從而拉高了平均值。一種可能的例子：

1, 1, ... 1, 901 // 共 100 條數(shù)據(jù)，平均值=10，P99=1

服務(wù) X 由順序的 A，B 兩個步驟完成，其中 X 的 P99 耗時 100Ms，A 過程 P99 耗時 50Ms，那么推測 B 過程的 P99 耗時情況是？

直覺上來看，因為有 X=A+B，所以答案可能是 50Ms，或者至少應(yīng)該要小于 50Ms。實際上 B 是可以大于 50Ms 的，只要 A 和 B 最大的 1% 不恰好遇到，B 完全可以有很大的 P99：

A = 1, 1, ... 1,  1,  1,  50,  50 // 共 100 條數(shù)據(jù)，P99=50B = 1, 1, ... 1,  1,  1,  99,  99 // 共 100 條數(shù)據(jù)，P99=99X = 2, 2, ... 1, 51, 51, 100, 100 // 共 100 條數(shù)據(jù)，P99=100

如果讓 A 過程最大的 1% 接近 100Ms，我們也能構(gòu)造出 P99 很小的 B：A = 50, 50, ... 50,  50,  99 // 共 100 條數(shù)據(jù)，P99=50B =  1,  1, ...  1,   1,  50 // 共 100 條數(shù)據(jù)，P99=1X = 51, 51, ... 51, 100, 100 // 共 100 條數(shù)據(jù)，P99=100

所以我們從題目唯一能確定的只有 B 的 P99 應(yīng)該不能超過 100ms，A 的 P99 耗時 50Ms 這個條件其實沒啥用。

類似的疑問很多，因此對于 histogram_quantile 函數(shù)，可能會產(chǎn)生反直覺的一些結(jié)果，最好的處理辦法是不斷試驗調(diào)整你的 Bucket 的值，保證更多的請求時間落在更細致的區(qū)間內(nèi)，這樣的請求時間才有統(tǒng)計意義。

二十三、慢查詢問題

Promql 的基礎(chǔ)知識看這篇文章

Prometheus 提供了自定義的 Promql 作為查詢語句，在 Graph 上調(diào)試的時候，會告訴你這條 Sql 的返回時間，如果太慢你就要注意了，可能是你的用法出現(xiàn)了問題。

評估 Prometheus 的整體響應(yīng)時間，可以用這個默認指標:

prometheus_engine_query_duration_seconds{}

一般情況下響應(yīng)過慢都是Promql 使用不當導(dǎo)致，或者指標規(guī)劃有問題，如：

• 大量使用 join 來組合指標或者增加 label，如將 kube-state-metric 中的一些 meta label和 node-exporter 中的節(jié)點屬性 label加入到 cadvisor容器數(shù)據(jù)里，像統(tǒng)計 pod 內(nèi)存使用率并按照所屬節(jié)點的機器類型分類，或按照所屬 rs 歸類。

• 范圍查詢時，大的時間范圍 step 值卻很小，導(dǎo)致查詢到的數(shù)量過大。

• rate 會自動處理 counter 重置的問題，最好由 promql 完成，不要自己拿出來全部元數(shù)據(jù)在程序中自己做 rate 計算。

• 在使用 rate 時，range duration要大于等于step，否則會丟失部分數(shù)據(jù)

• prometheus 是有基本預(yù)測功能的，如deriv和predict_linear(更準確)可以根據(jù)已有數(shù)據(jù)預(yù)測未來趨勢

• 如果比較復(fù)雜且耗時的sql，可以使用 record rule 減少指標數(shù)量，并使查詢效率更高，但不要什么指標都加 record，一半以上的 metric 其實不太會查詢到。同時 label 中的值不要加到 record rule 的 name 中。

二十四、高基數(shù)問題 Cardinality

高基數(shù)是數(shù)據(jù)庫避不開的一個話題，對于 Mysql 這種 DB 來講，基數(shù)是指特定列或字段中包含的唯一值的數(shù)量?；鶖?shù)越低，列中重復(fù)的元素越多。對于時序數(shù)據(jù)庫而言，就是 tags、label 這種標簽值的數(shù)量多少。

比如 Prometheus 中如果有一個指標 http_request_count{method="get",path="/abc",originIP="1.1.1.1"}表示訪問量，method 表示請求方法，originIP 是客戶端 IP，method的枚舉值是有限的，但 originIP 卻是無限的，加上其他 label 的排列組合就無窮大了，也沒有任何關(guān)聯(lián)特征，因此這種高基數(shù)不適合作為 Metric 的 label，真要的提取originIP，應(yīng)該用日志的方式，而不是 Metric 監(jiān)控

時序數(shù)據(jù)庫會為這些 Label 建立索引，以提高查詢性能，以便您可以快速找到與所有指定標簽匹配的值。如果值的數(shù)量過多，索引是沒有意義的，尤其是做 P95 等計算的時候，要掃描大量 Series 數(shù)據(jù)

官方文檔中對于Label 的建議

CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

如何查看當前的Label 分布情況呢，可以使用 Prometheus提供的Tsdb工具?？梢允褂妹钚胁榭?，也可以在 2.16 版本以上的 Prometheus Graph 查看

[work@xxx bin]$ ./tsdb analyze ../data/prometheus/Block ID: 01E41588AJNGM31SPGHYA3XSXGDuration: 2h0m0sSeries: 955372Label names: 301Postings (unique label pairs): 30757Postings entries (total label pairs): 10842822....

top10 高基數(shù)的 metric

Highest cardinality metric names:87176 apiserver_request_latencies_bucket59968 apiserver_response_sizes_bucket39862 apiserver_request_duration_seconds_bucket37555 container_tasks_state....

高基數(shù)的 label

Highest cardinality labels:4271 resource_version3670 id3414 name1857 container_id1824 __name__1297 uid1276 pod...

二十五、Prometheus 的預(yù)測能力

場景1：你的磁盤剩余空間一直在減少，并且降低的速度比較均勻，你希望知道大概多久之后達到閾值，并希望在某一個時刻報警出來。

場景2：你的 Pod 內(nèi)存使用率一直升高，你希望知道大概多久之后會到達 Limit 值，并在一定時刻報警出來，在被殺掉之前上去排查。

Prometheus 的 Deriv 和 Predict_Linear 方法可以滿足這類需求， Promtheus 提供了基礎(chǔ)的預(yù)測能力，基于當前的變化速度，推測一段時間后的值。

以 mem_free 為例，最近一小時的 free 值一直在下降。

mem_free僅為舉例，實際內(nèi)存可用以mem_available為準

deriv函數(shù)可以顯示指標在一段時間的變化速度:

predict_linear方法是預(yù)測基于這種速度，最后可以達到的值:

predict_linear(mem_free{instanceIP="100.75.155.55"}[1h], 2*3600)/1024/1024

你可以基于設(shè)置合理的報警規(guī)則，如小于 10 時報警:

rule: predict_linear(mem_free{instanceIP="100.75.155.55"}[1h], 2*3600)/1024/1024 <10 

predict_linear 與 deriv 的關(guān)系: 含義上約等于如下表達式，不過 predict_linear 稍微準確一些。

  deriv(mem_free{instanceIP="100.75.155.55"}[1h]) * 2 * 3600+  mem_free{instanceIP="100.75.155.55"}[1h]

如果你要基于 Metric做模型預(yù)測，可以參考下forecast-prometheus

二十六、alertmanager 的上層封裝

Prometheus 部署之后很少會改動，尤其是做了服務(wù)發(fā)現(xiàn)，就不需要頻繁新增 target。但報警的配置是很頻繁的，如修改閾值、修改報警人等。alertmanager 擁有豐富的報警能力如分組、抑制等，但如果你要想把他給業(yè)務(wù)部門使用，就要做一層封裝了，也就是報警配置臺。用戶喜歡表單操作，而非晦澀的 yaml，同時他們也并不愿意去理解 promql。而且大多數(shù)公司內(nèi)已經(jīng)有現(xiàn)成的監(jiān)控平臺，也只有一份短信或郵件網(wǎng)關(guān)，所以最好能使用 webhook 直接集成。

例如: 機器磁盤使用量超過 90% 就報警，rule 應(yīng)該寫為：disk_used/disk_total > 0.9

如果不加 label 篩選，這條報警會對所有機器生效，但如果你想去掉其中幾臺機器，就得在disk_used和disk_total后面加上{instance != “”}。這些操作在 promql 中是很簡單的，但是如果放在表單里操作，就得和內(nèi)部的 cmdb 做聯(lián)動篩選了。

• 對于一些簡單的需求，我們使用了 Grafana 的報警能力，所見即所得，直接在圖表下面配置告警即可，報警閾值和狀態(tài)很清晰。不過 Grafana 的報警能力很弱，只是實驗功能，可以作為調(diào)試使用。

• 對于常見的 pod 或應(yīng)用監(jiān)控，我們做了一些表單化，如下圖所示：提取了 CPU、內(nèi)存、磁盤 IO 等常見的指標作為選擇項，方便配置。

• 使用 webhook 擴展報警能力，改造 alertmanager， 在 send message 時做加密和認證，對接內(nèi)部已有報警能力，并聯(lián)動用戶體系，做限流和權(quán)限控制。

• 調(diào)用 alertmanager api 查詢報警事件，進行展示和統(tǒng)計。

對于用戶來說，封裝 alertmanager yaml 會變的易用，但也會限制其能力，在增加報警配置時，研發(fā)和運維需要有一定的配合。如新寫了一份自定義的 exporter，要將需要的指標供用戶選擇，并調(diào)整好展示和報警用的 promql。還有報警模板、原生 promql 暴露、用戶分組等，需要視用戶需求做權(quán)衡。

二十七、錯誤的高可用設(shè)計

有些人提出過這種類型的方案，想提高其擴展性和可用性。

應(yīng)用程序?qū)?Metric 推到到消息隊列如 Kafaka，然后經(jīng)過 Exposer 消費中轉(zhuǎn)，再被 Prometheus 拉取。產(chǎn)生這種方案的原因一般是有歷史包袱、復(fù)用現(xiàn)有組件、想通過 Mq 來提高擴展性。

這種方案有幾個問題：

• 增加了 Queue 組件，多了一層依賴，如果 App與 Queue 之間連接失敗，難道要在 App 本地緩存監(jiān)控數(shù)據(jù)？

• 抓取時間可能會不同步，延遲的數(shù)據(jù)將會被標記為陳舊數(shù)據(jù)，當然你可以通過添加時間戳來標識，但就失去了對陳舊數(shù)據(jù)的處理邏輯

• 擴展性問題：Prometheus 適合大量小目標，而不是一個大目標，如果你把所有數(shù)據(jù)都放在了 Exposer 中，那么 Prometheus 的單個 Job 拉取就會成為 CPU 瓶頸。這個和 Pushgateway 有些類似，沒有特別必要的場景，都不是官方建議的方式。

• 缺少了服務(wù)發(fā)現(xiàn)和拉取控制，Prom 只知道一個 Exposer，不知道具體是哪些 Target，不知道他們的 UP 時間，無法使用 Scrape_* 等指標做查詢，也無法用scrape_limit做限制。

如果你的架構(gòu)和 Prometheus 的設(shè)計理念相悖，可能要重新設(shè)計一下方案了，否則擴展性和可靠性反而會降低。

二十八、prometheus-operator 的場景

如果你是在 K8S 集群內(nèi)部署 Prometheus，那大概率會用到 prometheus-operator，他對 Prometheus 的配置做了 CRD 封裝，讓用戶更方便的擴展 Prometheus實例，同時 prometheus-operator 還提供了豐富的 Grafana 模板，包括上面提到的 master 組件監(jiān)控的 Grafana 視圖，operator 啟動之后就可以直接使用，免去了配置面板的煩惱。

operator 的優(yōu)點很多，就不一一列舉了，只提一下 operator 的局限：

• 因為是 operator，所以依賴 K8S 集群，如果你需要二進制部署你的 Prometheus，如集群外部署，就很難用上prometheus-operator了，如多集群場景。當然你也可以在 K8S 集群中部署 operator 去監(jiān)控其他的 K8S 集群，但這里面坑不少，需要修改一些配置。

• operator 屏蔽了太多細節(jié)，這個對用戶是好事，但對于理解 Prometheus 架構(gòu)就有些 gap 了，比如碰到一些用戶一鍵安裝了operator，但 Grafana 圖表異常后完全不知道如何排查，record rule 和 服務(wù)發(fā)現(xiàn)還不了解的情況下就直接配置，建議在使用 operator 之前，最好熟悉 prometheus 的基礎(chǔ)用法。

• operator 方便了 Prometheus 的擴展和配置，對于 alertmanager 和 exporter 可以很方便的做到多實例高可用，但是沒有解決 Prometheus 的高可用問題，因為無法處理數(shù)據(jù)不一致，operator目前的定位也還不是這個方向，和 Thanos、Cortex 等方案的定位是不同的，下面會詳細解釋。

二十九、高可用方案

Prometheus 高可用有幾種方案：

1. 基本 HA：即兩套 Prometheus 采集完全一樣的數(shù)據(jù)，外邊掛負載均衡

2. HA + 遠程存儲：除了基礎(chǔ)的多副本 Prometheus，還通過 Remote Write 寫入到遠程存儲，解決存儲持久化問題

3. 聯(lián)邦集群：即 Federation，按照功能進行分區(qū)，不同的 Shard 采集不同的數(shù)據(jù)，由Global節(jié)點來統(tǒng)一存放，解決監(jiān)控數(shù)據(jù)規(guī)模的問題。

4. 使用 Thanos 或者 Victoriametrics，來解決全局查詢、多副本數(shù)據(jù) Join 問題。

就算使用官方建議的多副本 + 聯(lián)邦，仍然會遇到一些問題:

1. 官方建議數(shù)據(jù)做 Shard，然后通過Federation來實現(xiàn)高可用，

2. 但是邊緣節(jié)點和Global節(jié)點依然是單點，需要自行決定是否每一層都要使用雙節(jié)點重復(fù)采集進行?；睢?br>也就是仍然會有單機瓶頸。

3. 另外部分敏感報警盡量不要通過Global節(jié)點觸發(fā)，畢竟從Shard節(jié)點到Global節(jié)點傳輸鏈路的穩(wěn)定性會影響數(shù)據(jù)到達的效率，進而導(dǎo)致報警實效降低。

4. 例如服務(wù)Updown狀態(tài)，Api請求異常這類報警我們都放在Shard節(jié)點進行報警。

本質(zhì)原因是，Prometheus 的本地存儲沒有數(shù)據(jù)同步能力，要在保證可用性的前提下，再保持數(shù)據(jù)一致性是比較困難的，基礎(chǔ)的 HA Proxy 滿足不了要求，比如：

• 集群的后端有 A 和 B 兩個實例，A 和 B 之間沒有數(shù)據(jù)同步。A 宕機一段時間，丟失了一部分數(shù)據(jù)，如果負載均衡正常輪詢，請求打到A 上時，數(shù)據(jù)就會異常。

• 如果 A 和 B 的啟動時間不同，時鐘不同，那么采集同樣的數(shù)據(jù)時間戳也不同，就不是多副本同樣數(shù)據(jù)的概念了

• 就算用了遠程存儲，A 和 B 不能推送到同一個 TSDB，如果每人推送自己的 TSDB，數(shù)據(jù)查詢走哪邊就是問題了。

因此解決方案是在存儲、查詢兩個角度上保證數(shù)據(jù)的一致:

• 存儲角度：如果使用 Remote Write 遠程存儲， A 和 B后面可以都加一個 Adapter，Adapter做選主邏輯，只有一份數(shù)據(jù)能推送到 TSDB，這樣可以保證一個異常，另一個也能推送成功，數(shù)據(jù)不丟，同時遠程存儲只有一份，是共享數(shù)據(jù)。方案可以參考這篇文章

• 查詢角度：上邊的方案實現(xiàn)很復(fù)雜且有一定風險，因此現(xiàn)在的大多數(shù)方案在查詢層面做文章，比如 Thanos 或者 Victoriametrics，仍然是兩份數(shù)據(jù)，但是查詢時做數(shù)據(jù)去重和 Join。只是 Thanos 是通過 Sidecar 把數(shù)據(jù)放在對象存儲，Victoriametrics 是把數(shù)據(jù) Remote Write 到自己的 Server 實例，但查詢層 Thanos-Query 和 Victor 的 Promxy的邏輯基本一致。

我們采用了 Thanos 來支持多地域監(jiān)控數(shù)據(jù)，具體方案可以看這篇文章

三十、容器日志與事件

本文主要是 Prometheus 監(jiān)控內(nèi)容, 這里只簡單介紹下 K8S 中的日志、事件處理方案，以及和 Prometheus 的搭配。

日志處理：

• 日志采集與推送：一般是Fluentd/Fluent-Bit/Filebeat等采集推送到 ES、對象存儲、kafaka，日志就該交給專業(yè)的 EFK 來做，分為容器標準輸出、容器內(nèi)日志。

• 日志解析轉(zhuǎn) metric：可以提取一些日志轉(zhuǎn)為 Prometheus 格式的指標，如解析特定字符串出現(xiàn)次數(shù)，解析 Nginx 日志得到 QPS 、請求延遲等。常用方案是 mtail 或者 grok

日志采集方案：

• sidecar 方式：和業(yè)務(wù)容器共享日志目錄，由 sidecar 完成日志推送，一般用于多租戶場景。

• daemonset 方式：機器上運行采集進程，統(tǒng)一推送出去。

需要注意的點：對于容器標準輸出，默認日志路徑是/var/lib/docker/containers/xxx， kubelet 會將改日志軟鏈到/var/log/pods，同時還有一份/var/log/containers 是對/var/log/pods的軟鏈。不過不同的 K8S 版本，日志的目錄格式有所變化，采集時根據(jù)版本做區(qū)分：

• 1.15 及以下：/var/log/pods/{pod_uid}/

• 1.15 以上：var/log/pods/{pod_name+namespace+rs+uuid}/

事件：在這里特指 K8S Events，Events 在排查集群問題時也很關(guān)鍵，不過默認情況下只保留 1h，因此需要對 Events 做持久化。一般 Events 處理方式有兩種：

• 使用 kube-eventer 之類的組件采集 Events 并推送到 ES

• 使用 event_exporter 之類的組件將Events 轉(zhuǎn)化為 Prometheus Metric，同類型的還有谷歌云的 stackdriver 下的 event-exporter

作者：徐亞松 

來源：http://www.xuyasong.com

轉(zhuǎn)自：DevOps技術(shù)棧

資料專區(qū)：Prometheus 官方中文文檔

這份文檔共分為7大部分，從最基礎(chǔ)的Prometheus介紹安裝及啟動講起，對不同監(jiān)控系統(tǒng)的優(yōu)缺點進行了對比。 點擊文末閱讀原文免費領(lǐng)??！