<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          基于 Prometheus 的監(jiān)控系統(tǒng)實踐

          共 15807字,需瀏覽 32分鐘

           ·

          2021-11-27 07:44

          監(jiān)控作為底層基礎(chǔ)設(shè)施的一環(huán),是保障生產(chǎn)環(huán)境服務(wù)穩(wěn)定性不可或缺的一部分,線上問題從發(fā)現(xiàn)到定位再到解決,通過監(jiān)控和告警手段可以有效地覆蓋了「發(fā)現(xiàn)」和「定位」,甚至可以通過故障自愈等手段實現(xiàn)解決,服務(wù)開發(fā)和運維人員能及時有效地發(fā)現(xiàn)服務(wù)運行的異常,從而更有效率地排查和解決問題。
          一個典型的監(jiān)控(如白盒監(jiān)控),通常會關(guān)注于目標(biāo)服務(wù)的內(nèi)部狀態(tài),例如:
          • 單位時間接收到的請求數(shù)量
          • 單位時間內(nèi)請求的成功率/失敗率
          • 請求的平均處理耗時
          白盒監(jiān)控很好地描述了系統(tǒng)的內(nèi)部狀態(tài),但缺少從外部角度看到的現(xiàn)象,比如:白盒監(jiān)控只能看到已經(jīng)接收的請求,并不能看到由于 DNS 故障導(dǎo)致沒有發(fā)送成功的請求,而黑盒監(jiān)控此時便可以作為補(bǔ)充手段,由探針(probe)程序來探測目標(biāo)服務(wù)是否成功返回,更好地反饋系統(tǒng)的當(dāng)前狀態(tài)。
          某日需要為服務(wù)搭建一個監(jiān)控系統(tǒng)來采集應(yīng)用埋點上報的指標(biāo),經(jīng)過一番對比,最終選擇了 Prometheus 來作為我們的業(yè)務(wù)監(jiān)控,因為它具有以下優(yōu)點:
          • 支持 PromQL(一種查詢語言),可以靈活地聚合指標(biāo)數(shù)據(jù)

          • 部署簡單,只需要一個二進(jìn)制文件就能跑起來,不需要依賴分布式存儲

          • Go 語言編寫,組件更方便集成在同樣是Go編寫項目代碼中

          • 原生自帶 WebUI,通過 PromQL 渲染時間序列到面板上

          • 生態(tài)組件眾多,Alertmanager,Pushgateway,Exporter……

          Prometheus 的架構(gòu)圖如下:

          在上面流程中,Prometheus 通過配置文件中指定的服務(wù)發(fā)現(xiàn)方式來確定要拉取監(jiān)控指標(biāo)的目標(biāo)(Target),接著從要拉取的目標(biāo)(應(yīng)用容器和Pushgateway)發(fā)起HTTP請求到特定的端點(Metric Path),將指標(biāo)持久化至本身的TSDB中,TSDB最終會把內(nèi)存中的時間序列壓縮落到硬盤,除此之外,Prometheus 會定期通過 PromQL 計算設(shè)置好的告警規(guī)則,決定是否生成告警到 Alertmanager,后者接收到告警后會負(fù)責(zé)把通知發(fā)送到郵件或企業(yè)內(nèi)部群聊中。
          Prometheus 的指標(biāo)名稱只能由 ASCII 字符、數(shù)字、下劃線以及冒號組成,而且有一套命名規(guī)范:
          • 使用基礎(chǔ) Unit(如 seconds 而非 milliseconds)

          • 指標(biāo)名以 application namespace 作為前綴,如:

            • process_cpu_seconds_total

            • http_request_duration_seconds

          • 用后綴來描述 Unit,如:

            • http_request_duration_seconds

            • node_memory_usage_bytes

            • http_requests_total

            • process_cpu_seconds_total

            • foobar_build_info

          Prometheus 提供了以下基本的指標(biāo)類型:

          • Counter:代表一種樣本數(shù)據(jù)單調(diào)遞增的指標(biāo),即只增不減,通常用來統(tǒng)計如服務(wù)的請求數(shù),錯誤數(shù)等。

          • Gauge:代表一種樣本數(shù)據(jù)可以任意變化的指標(biāo),即可增可減,通常用來統(tǒng)計如服務(wù)的CPU使用值,內(nèi)存占用值等。

          • Histogram?和?Summary:用于表示一段時間內(nèi)的數(shù)據(jù)采樣和點分位圖統(tǒng)計結(jié)果,通常用來統(tǒng)計請求耗時或響應(yīng)大小等。

          Prometheus 是基于時間序列存儲的,首先了解一下什么是時間序列,時間序列的格式類似于(timestamp,value)這種格式,即一個時間點擁有一個對應(yīng)值,例如生活中很常見的天氣預(yù)報,如:[(14:00,27℃),(15:00,28℃),(16:00,26℃)],就是一個單維的時間序列,這種按照時間戳和值存放的序列也被稱之為向量(vector)。

          再來舉另一個例子,如上圖所示,假如有一個指標(biāo) http_requests,它的作用是統(tǒng)計每個時間段對應(yīng)的總請求量是多少,這時候它即為上面提到的是一個單維矩陣,而當(dāng)我們給這個指標(biāo)加上一個維度:主機(jī)名,這時候這個指標(biāo)的作用就變成了統(tǒng)計每個時間段各個主機(jī)名對應(yīng)的請求量是多少,這時候這個矩陣區(qū)域就變成擁有多列向量(每一列對應(yīng)一個主機(jī)名)的時間序列,當(dāng)給這個時間序列再添加多個標(biāo)簽(key=value)時,這個矩陣就相應(yīng)會變成一個多維矩陣。

          每一組唯一的標(biāo)簽集合對應(yīng)著一個唯一的向量(vector),也可叫做一個時間序列(Time Serie),當(dāng)在某一個時間點來看它時,它是一個瞬時向量(Instant Vector),瞬時向量的時序只有一個時間點以及它對于的一個值,比如:今天 12:05:30 時服務(wù)器的 CPU 負(fù)載;而在一個時間段來看它時,它是一個范圍向量(Range Vector),范圍向量對于一組時序數(shù)據(jù),比如:今天11:00到12:00時服務(wù)器的CPU負(fù)載。

          類似的,可以通過指標(biāo)名和標(biāo)簽集來查詢符合條件的時間序列:

          http_requests{host="host1",service="web",code="200",env="test"}

          查詢結(jié)果會是一個瞬時向量:

          http_requests{host="host1",service="web",code="200",env="test"} 10http_requests{host="host2",service="web",code="200",env="test"} 0http_requests{host="host3",service="web",code="200",env="test"} 12

          而如果給這個條件加上一個時間參數(shù),查詢一段時間內(nèi)的時間序列:

          http_requests{host="host1",service="web",code="200",env="test"}[:5m]

          結(jié)果將會是一個范圍向量:

          http_requests{host="host1",service="web",code="200",env="test"} 0 4 6 8 10http_requests{host="host2",service="web",code="200",env="test"} 0 0 0 0 0http_requests{host="host3",service="web",code="200",env="test"} 0 2 5 9 12
          擁有了范圍向量,我們是否可以針對這些時間序列進(jìn)行一些聚合運算呢?沒錯,PromQL就是這么干的,比如我們要算最近5分鐘的請求增長速率,就可以拿上面的范圍向量加上聚合函數(shù)來做運算:
          rate(http_requests{host="host1",service="web",code="200",env="test"}[:5m])

          比如要求最近5分鐘請求的增長量,可以用以下的 PromQL:

          increase(http_requests{host="host1",service="web",code="200",env="test"}[:5m])

          要計算過去10分鐘內(nèi)第90個百分位數(shù):

          histogram_quantile(0.9, rate(employee_age_bucket_bucket[10m]))

          在 Prometheus 中,一個指標(biāo)(即擁有唯一的標(biāo)簽集的 metric)和一個(timestamp,value)組成了一個樣本(sample),Prometheus 將采集的樣本放到內(nèi)存中,默認(rèn)每隔2小時將數(shù)據(jù)壓縮成一個 block,持久化到硬盤中,樣本的數(shù)量越多,Prometheus占用的內(nèi)存就越高,因此在實踐中,一般不建議用區(qū)分度(cardinality)太高的標(biāo)簽,比如:用戶IP,ID,URL地址等等,否則結(jié)果會造成時間序列數(shù)以指數(shù)級別增長(label數(shù)量相乘)。

          除了控制樣本數(shù)量和大小合理之外,還可以通過降低 storage.tsdb.min-block-duration 來加快數(shù)據(jù)落盤時間和增加 scrape interval 的值提高拉取間隔來控制 Prometheus 的占用內(nèi)存。

          通過聲明配置文件中的 scrape_configs 來指定 Prometheus 在運行時需要拉取指標(biāo)的目標(biāo),目標(biāo)實例需要實現(xiàn)一個可以被 Prometheus 進(jìn)行輪詢的端點,而要實現(xiàn)一個這樣的接口,可以用來給 Prometheus 提供監(jiān)控樣本數(shù)據(jù)的獨立程序一般被稱作為 Exporter,比如用來拉取操作系統(tǒng)指標(biāo)的 Node Exporter,它會從操作系統(tǒng)上收集硬件指標(biāo),供 Prometheus 來拉取。
          在開發(fā)環(huán)境,往往只需要部署一個 Prometheus 實例便可以滿足數(shù)十萬指標(biāo)的收集。但在生產(chǎn)環(huán)境中,應(yīng)用和服務(wù)實例數(shù)量眾多,只部署一個 Prometheus 實例通常是不夠的,比較好的做法是部署多個Prometheus實例,每個實例通過分區(qū)只拉取一部分指標(biāo),例如Prometheus Relabel配置中的hashmod功能,可以對拉取目標(biāo)的地址進(jìn)行hashmod,再將結(jié)果匹配自身ID的目標(biāo)保留:
          relabel_configs:- source_labels: [__address__]  modulus:       3  target_label:  __tmp_hash  action:        hashmod- source_labels: [__tmp_hash]  regex:         $(PROM_ID)  action:        keep
          或者說,我們想讓每個 Prometheus 拉取一個集群的指標(biāo),一樣可以用 Relabel 來完成:
          relabel_configs:- source_labels:  ["__meta_consul_dc"]  regex: "dc1"  action: keep
          現(xiàn)在每個 Prometheus 都有各自的數(shù)據(jù)了,那么怎么把他們關(guān)聯(lián)起來,建立一個全局的視圖呢?官方提供了一個做法:聯(lián)邦集群(federation),即把 Prometheuse Server 按照樹狀結(jié)構(gòu)進(jìn)行分層,根節(jié)點方向的 Prometheus 將查詢?nèi)~子節(jié)點的 Prometheus 實例,再將指標(biāo)聚合返回。

          不過顯然易見的是,使用聯(lián)邦集群依然不能解決問題,首先單點問題依然存在,根節(jié)點掛了的話查詢將會變得不可用,如果配置多個父節(jié)點的話又會造成數(shù)據(jù)冗余和抓取時機(jī)導(dǎo)致數(shù)據(jù)不一致等問題,而且葉子節(jié)點目標(biāo)數(shù)量太多時,更加會容易使父節(jié)點壓力增大以至打滿宕機(jī),除此之外規(guī)則配置管理也是個大麻煩。
          還好社區(qū)出現(xiàn)了一個 Prometheus 的集群解決方案:Thanos,它提供了全局查詢視圖,可以從多臺Prometheus查詢和聚合數(shù)據(jù),因為所有這些數(shù)據(jù)均可以從單個端點獲取。

          1. Querier 收到一個請求時,它會向相關(guān)的 Sidecar 發(fā)送請求,并從他們的 Prometheus 服務(wù)器獲取時間序列數(shù)據(jù)。
          2. 它將這些響應(yīng)的數(shù)據(jù)聚合在一起,并對它們執(zhí)行 PromQL 查詢。它可以聚合不相交的數(shù)據(jù)也可以針對 Prometheus 的高可用組進(jìn)行數(shù)據(jù)去重。
          再來說到存儲,Prometheus 查詢的高可用可以通過水平擴(kuò)展+統(tǒng)一查詢視圖的方式解決,那么存儲的高可用要怎么解決呢?在 Prometheus 的設(shè)計中,數(shù)據(jù)是以本地存儲的方式進(jìn)行持久化的,雖然本地持久化方便,但也會帶來一些麻煩,比如節(jié)點掛了或者 Prometheus 被調(diào)度到其他節(jié)點上,就會意味著原節(jié)點上的監(jiān)控數(shù)據(jù)在查詢接口中丟失,本地存儲導(dǎo)致了 Prometheus 無法彈性擴(kuò)展,為此 Prometheus 提供了 Remote Read 和 Remote Write 功能,支持把 Prometheus 的時間序列遠(yuǎn)程寫入到遠(yuǎn)端存儲中,查詢時可以從遠(yuǎn)端存儲中讀取數(shù)據(jù)。

          其中一個例子中就是M3DB,M3DB是一個分布式的時間序列數(shù)據(jù)庫,它提供了Prometheus的遠(yuǎn)程讀寫接口,當(dāng)一個時間序列寫入到M3DB集群后會按照分片(Shard)和復(fù)制(Replication Factor)參數(shù)把數(shù)據(jù)復(fù)制到集群的其他節(jié)點上,實現(xiàn)存儲高可用。除了M3DB外,Prometheus目前還支持InfluxDB、OpenTSDB等作為遠(yuǎn)程寫的端點。
          解決了 Prometheus 的高可用,再來關(guān)注一下 Prometheus 如何對監(jiān)控目標(biāo)進(jìn)行采集,當(dāng)監(jiān)控節(jié)點數(shù)量較小時,可以通過 Static Config 將目標(biāo)主機(jī)列表寫到 Prometheus 的拉取配置中,但如果目標(biāo)節(jié)點一多的話這種方式管理便有很大問題了,而且在生產(chǎn)環(huán)境中,服務(wù)實例的IP通常不是固定的,這時候用靜態(tài)配置就沒辦法對目標(biāo)節(jié)點進(jìn)行有效管理,這時候 Prometheus 提供的服務(wù)發(fā)現(xiàn)功能便可以有效解決監(jiān)控節(jié)點狀態(tài)變化的問題,在這種模式下,Prometheus 會到注冊中心監(jiān)聽查詢節(jié)點列表,定期對節(jié)點進(jìn)行指標(biāo)的拉取。
          如果對服務(wù)發(fā)現(xiàn)有更靈活的需求,Prometheus 也支持基于文件的服務(wù)發(fā)現(xiàn)功能,這時候我們可以從多個注冊中心中獲取節(jié)點列表,再通過自己的需求進(jìn)行過濾,最終寫入到文件,這時候 Prometheus 檢測到文件變化后便能動態(tài)地替換監(jiān)控節(jié)點,再去拉取目標(biāo)了。
          前面看到 Prometheus 都是以拉模式定期對目標(biāo)節(jié)點進(jìn)行抓取的,那假如有一種情況是一些任務(wù)節(jié)點還沒來得及被拉取就運行完退出了,這時候監(jiān)控數(shù)據(jù)就會丟失,為了應(yīng)對這種情況,Prometheus 提供了一個工具:Pushgateway,用來接收來自服務(wù)的主動上報,它適用于那些短暫存活的批量任務(wù)來將指標(biāo)推送并暫存到自身上,借著再由Prometheus 來拉取自身,以防止指標(biāo)還沒來得及被 Prometheus 拉取便退出。
          除此以外 Pushgateway 也適用于在 Prometheus 與應(yīng)用節(jié)點運行在異構(gòu)網(wǎng)絡(luò)或被防火墻隔絕時,無法主動拉取節(jié)點的問題,在這種情況下應(yīng)用節(jié)點可以通過使用Pushgateway的域名將指標(biāo)推送到Pushgateway實例上,Prometheus就可以拉取同網(wǎng)絡(luò)下的Pushgateway 節(jié)點了,另外配置拉取 Pushgateway 時要注意一個問題:Prometheus 會把每個指標(biāo)賦予 job 和instance標(biāo)簽,當(dāng)Prometheus拉取Pushgateway時,job和instance則可能分別是Pushgateway和Pushgateway主機(jī)的ip,當(dāng)pushgateway上報的指標(biāo)中也包含job和instance標(biāo)簽時,Prometheus會把沖突的標(biāo)簽重命名為exported_job和exported_instance,如果需要覆蓋這兩個標(biāo)簽的話,需要在Prometheus中配置honor_labels: true。

          Pushgateway可以替代拉模型來作為指標(biāo)的收集方案,但在這種模式下會帶來許多負(fù)面影響:

          Pushgateway 被設(shè)計為一個監(jiān)控指標(biāo)的緩存,這意味著它不會主動過期服務(wù)上報的指標(biāo),這種情況在服務(wù)一直運行的時候不會有問題,但當(dāng)服務(wù)被重新調(diào)度或銷毀時,Pushgateway 依然會保留著之前節(jié)點上報的指標(biāo)。而且,假如多個 Pushgateway 運行在LB下,會造成一個監(jiān)控指標(biāo)有可能出現(xiàn)在多個 Pushgateway 的實例上,造成數(shù)據(jù)重復(fù)多份,需要在代理層加入一致性哈希路由來解決。
          在拉模式下,Prometheus可以更容易的查看監(jiān)控目標(biāo)實例的健康狀態(tài),并且可以快速定位故障,但在推模式下,由于不會對客戶端進(jìn)行主動探測,因此對目標(biāo)實例的健康狀態(tài)也變得一無所知。

          最后再來聊一下Alertmanager,簡單說 Alertmanager 是與 Prometheus 分離的告警組件,主要接收 Promethues 發(fā)送過來的告警事件,然后對告警進(jìn)行去重,分組,抑制和發(fā)送,在實際中可以搭配 webhook 把告警通知發(fā)送到企業(yè)微信或釘釘上,其架構(gòu)圖如下:

          最后的最后再來嘗試一下用 Kubernetes 來搭建一套 Prometheus 的監(jiān)控系統(tǒng),關(guān)于Kubernetes 也是摸爬滾打折騰了一周才清楚怎么使用的,雖然 Promehteus 已經(jīng)有官方的 Operator 了,但是為了學(xué)習(xí)都用手動編寫 yaml 文件,整個完成下來發(fā)現(xiàn)還是挺方便的,而且只需要用幾個實例就可以完成收集監(jiān)控200+服務(wù)數(shù)千個實例的業(yè)務(wù)指標(biāo)。

          為了部署 Prometheus 實例,需要聲明 Prometheus 的 StatefulSet,Pod 中包括了三個容器,分別是 Prometheus 以及綁定的 Thanos Sidecar,最后再加入一個 watch 容器,來監(jiān)聽 prometheus 配置文件的變化,當(dāng)修改 ConfigMap 時就可以自動調(diào)用Prometheus 的 Reload API 完成配置加載,這里按照之前提到的數(shù)據(jù)分區(qū)的方式,在Prometheus 啟動前加入一個環(huán)境變量 PROM_ID,作為 Relabel 時 hashmod 的標(biāo)識,而 POD_NAME 用作 Thanos Sidecar 給 Prometheus 指定的 external_labels.replica 來使用:

          apiVersion: apps/v1kind: StatefulSetmetadata:  name: prometheus  labels:    app: prometheusspec:  serviceName: "prometheus"  updateStrategy:    type: RollingUpdate  replicas: 3  selector:    matchLabels:      app: prometheus  template:    metadata:      labels:        app: prometheus        thanos-store-api: "true"    spec:      serviceAccountName: prometheus      volumes:      - name: prometheus-config        configMap:          name: prometheus-config      - name: prometheus-data        hostPath:          path: /data/prometheus      - name: prometheus-config-shared        emptyDir: {}      containers:      - name: prometheus        image: prom/prometheus:v2.11.1        args:          - --config.file=/etc/prometheus-shared/prometheus.yml          - --web.enable-lifecycle          - --storage.tsdb.path=/data/prometheus          - --storage.tsdb.retention=2w          - --storage.tsdb.min-block-duration=2h          - --storage.tsdb.max-block-duration=2h          - --web.enable-admin-api        ports:          - name: http            containerPort: 9090        volumeMounts:          - name: prometheus-config-shared            mountPath: /etc/prometheus-shared          - name: prometheus-data            mountPath: /data/prometheus        livenessProbe:          httpGet:            path: /-/healthy            port: http      - name: watch        image: watch        args: ["-v", "-t", "-p=/etc/prometheus-shared", "curl", "-X", "POST", "--fail", "-o", "-", "-sS", "http://localhost:9090/-/reload"]        volumeMounts:        - name: prometheus-config-shared          mountPath: /etc/prometheus-shared      - name: thanos        image: improbable/thanos:v0.6.0        command: ["/bin/sh", "-c"]        args:          - PROM_ID=`echo $POD_NAME| rev | cut -d '-' -f1` /bin/thanos sidecar            --prometheus.url=http://localhost:9090            --reloader.config-file=/etc/prometheus/prometheus.yml.tmpl            --reloader.config-envsubst-file=/etc/prometheus-shared/prometheus.yml        env:          - name: POD_NAME            valueFrom:              fieldRef:                fieldPath: metadata.name        ports:          - name: http-sidecar            containerPort: 10902          - name: grpc            containerPort: 10901        volumeMounts:          - name: prometheus-config            mountPath: /etc/prometheus          - name: prometheus-config-shared            mountPath: /etc/prometheus-shared

          因為 Prometheus 默認(rèn)是沒辦法訪問 Kubernetes 中的集群資源的,因此需要為之分配RBAC:

          apiVersion: v1kind: ServiceAccountmetadata:  name: prometheus---kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:  name: prometheus  namespace: default  labels:    app: prometheusrules:- apiGroups: [""]  resources: ["services", "pods", "nodes", "nodes/proxy", "endpoints"]  verbs: ["get", "list", "watch"]- apiGroups: [""]  resources: ["configmaps"]  verbs: ["create"]- apiGroups: [""]  resources: ["configmaps"]  resourceNames: ["prometheus-config"]  verbs: ["get", "update", "delete"]- nonResourceURLs: ["/metrics"]  verbs: ["get"]---kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: prometheus  namespace: default  labels:    app: prometheussubjects:- kind: ServiceAccount  name: prometheus  namespace: defaultroleRef:  kind: ClusterRole  name: prometheus  apiGroup: ""

          接著 Thanos Querier 的部署比較簡單,需要在啟動時指定 store 的參數(shù)為dnssrv+thanos-store-gateway.default.svc來發(fā)現(xiàn)Sidecar:

          apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: thanos-query  name: thanos-queryspec:  replicas: 2  selector:    matchLabels:      app: thanos-query  minReadySeconds: 5  strategy:    type: RollingUpdate    rollingUpdate:      maxSurge: 1      maxUnavailable: 1  template:    metadata:      labels:        app: thanos-query    spec:      containers:      - args:        - query        - --log.level=debug        - --query.timeout=2m        - --query.max-concurrent=20        - --query.replica-label=replica        - --query.auto-downsampling        - --store=dnssrv+thanos-store-gateway.default.svc        - --store.sd-dns-interval=30s        image: improbable/thanos:v0.6.0        name: thanos-query        ports:        - containerPort: 10902          name: http        - containerPort: 10901          name: grpc        livenessProbe:          httpGet:            path: /-/healthy            port: http---apiVersion: v1kind: Servicemetadata:  labels:    app: thanos-query  name: thanos-queryspec:  type: LoadBalancer  ports:  - name: http    port: 10901    targetPort: http  selector:    app: thanos-query---apiVersion: v1kind: Servicemetadata:  labels:    thanos-store-api: "true"  name: thanos-store-gatewayspec:  type: ClusterIP  clusterIP: None  ports:  - name: grpc    port: 10901    targetPort: grpc  selector:    thanos-store-api: "true"部署Thanos Ruler:apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: thanos-rule  name: thanos-rulespec:  replicas: 1  selector:    matchLabels:      app: thanos-rule  template:    metadata:      labels:      labels:        app: thanos-rule    spec:      containers:      - name: thanos-rule        image: improbable/thanos:v0.6.0        args:        - rule        - --web.route-prefix=/rule        - --web.external-prefix=/rule        - --log.level=debug        - --eval-interval=15s        - --rule-file=/etc/rules/thanos-rule.yml        - --query=dnssrv+thanos-query.default.svc        - --alertmanagers.url=dns+http://alertmanager.default        ports:        - containerPort: 10902          name: http        volumeMounts:          - name: thanos-rule-config            mountPath: /etc/rules      volumes:      - name: thanos-rule-config        configMap:          name: thanos-rule-config

          部署 Pushgateway:

          apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: pushgateway  name: pushgatewayspec:  replicas: 15  selector:    matchLabels:      app: pushgateway  template:    metadata:      labels:        app: pushgateway    spec:      containers:      - image: prom/pushgateway:v1.0.0        name: pushgateway        ports:        - containerPort: 9091          name: http        resources:          limits:            memory: 1Gi          requests:            memory: 512Mi---apiVersion: v1kind: Servicemetadata:  labels:    app: pushgateway  name: pushgatewayspec:  type: LoadBalancer  ports:  - name: http    port: 9091    targetPort: http  selector:    app: pushgateway

          部署 Alertmanager:

          apiVersion: apps/v1kind: Deploymentmetadata:  name: alertmanagerspec:  replicas: 3  selector:    matchLabels:      app: alertmanager  template:    metadata:      name: alertmanager      labels:        app: alertmanager    spec:      containers:      - name: alertmanager        image: prom/alertmanager:latest        args:          - --web.route-prefix=/alertmanager          - --config.file=/etc/alertmanager/config.yml          - --storage.path=/alertmanager          - --cluster.listen-address=0.0.0.0:8001          - --cluster.peer=alertmanager-peers.default:8001        ports:        - name: alertmanager          containerPort: 9093        volumeMounts:        - name: alertmanager-config          mountPath: /etc/alertmanager        - name: alertmanager          mountPath: /alertmanager      volumes:      - name: alertmanager-config        configMap:          name: alertmanager-config      - name: alertmanager        emptyDir: {}---apiVersion: v1kind: Servicemetadata:  labels:    name: alertmanager-peers  name: alertmanager-peersspec:  type: ClusterIP  clusterIP: None  selector:    app: alertmanager  ports:  - name: alertmanager    protocol: TCP    port: 9093    targetPort: 9093

          最后部署一下 ingress,大功告成:

          apiVersion: extensions/v1beta1kind: Ingressmetadata:  name: pushgateway-ingress  annotations:    kubernetes.io/ingress.class: "nginx"    nginx.ingress.kubernetes.io/upstream-hash-by: "$request_uri"    nginx.ingress.kubernetes.io/ssl-redirect: "false"spec:  rules:  - host: $(DOMAIN)    http:      paths:      - backend:          serviceName: pushgateway          servicePort: 9091        path: /metrics---apiVersion: extensions/v1beta1kind: Ingressmetadata:  name: prometheus-ingress  annotations:    kubernetes.io/ingress.class: "nginx"spec:  rules:  - host: $(DOMAIN)    http:      paths:      - backend:          serviceName: thanos-query          servicePort: 10901        path: /      - backend:          serviceName: alertmanager          servicePort: 9093        path: /alertmanager      - backend:          serviceName: thanos-rule          servicePort: 10092        path: /rule      - backend:          serviceName: grafana          servicePort: 3000        path: /grafana

          訪問 Prometheus 地址,監(jiān)控節(jié)點狀態(tài)正常:

          來源:https://zhuanlan.zhihu.com/p/101184971

          Linux學(xué)習(xí)指南

          有收獲,點個在看?

          瀏覽 50
          點贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  国产黑丝操逼 | 一级一片免费观看 | 国精产品乱码一区一区三区四区 | 狠狠操无码免费 | 成年人视频免费在线观看大香蕉 |