這篇文章主要介紹“Prometheus-operator的介紹和配置方法”,在日常操作中,相信很多人在Prometheus-operator的介紹和配置方法問題上存在疑惑,小編查閱了各式資料,整理出簡(jiǎn)單好用的操作方法,希望對(duì)大家解答”Prometheus-operator的介紹和配置方法”的疑惑有所幫助!接下來,請(qǐng)跟著小編一起來學(xué)習(xí)吧!
創(chuàng)新互聯(lián)公司長(zhǎng)期為1000+客戶提供的網(wǎng)站建設(shè)服務(wù),團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年,關(guān)注不同地域、不同群體,并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù);打造開放共贏平臺(tái),與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為武清企業(yè)提供專業(yè)的成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì),武清網(wǎng)站改版等技術(shù)服務(wù)。擁有10余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。
隨著云原生概念盛行,對(duì)于容器、服務(wù)、節(jié)點(diǎn)以及集群的監(jiān)控變得越來越重要。Prometheus 作為 Kubernetes 監(jiān)控的事實(shí)標(biāo)準(zhǔn),有著強(qiáng)大的功能和良好的生態(tài)。但是它不支持分布式,不支持?jǐn)?shù)據(jù)導(dǎo)入、導(dǎo)出,不支持通過 API 修改監(jiān)控目標(biāo)和報(bào)警規(guī)則,所以在使用它時(shí),通常需要寫腳本和代碼來簡(jiǎn)化操作。Prometheus Operator 為監(jiān)控 Kubernetes service、deployment 和 Prometheus 實(shí)例的管理提供了簡(jiǎn)單的定義,簡(jiǎn)化在 Kubernetes 上部署、管理和運(yùn)行 Prometheus 和 Alertmanager 集群。
Prometheus Operator (后面都簡(jiǎn)稱 Operater) 提供如下功能:
創(chuàng)建/銷毀:在 Kubernetes namespace 中更加容易地啟動(dòng)一個(gè) Prometheues 實(shí)例,一個(gè)特定應(yīng)用程序或者團(tuán)隊(duì)可以更容易使用 Operator。
便捷配置:通過 Kubernetes 資源配置 Prometheus 的基本信息,比如版本、存儲(chǔ)、副本集等。
通過標(biāo)簽標(biāo)記目標(biāo)服務(wù): 基于常見的 Kubernetes label 查詢自動(dòng)生成監(jiān)控目標(biāo)配置;不需要學(xué)習(xí) Prometheus 特定的配置語言。
對(duì)于版本高于 0.18.0
的 Prometheus Operator 要求 Kubernetes 集群版本高于 1.8.0
。如果你才開始使用 Prometheus Operator,推薦你使用最新版。
如果你使用的舊版本的 Kubernetes 和 Prometheus Operator 還在運(yùn)行,推薦先升級(jí) Kubernetes,再升級(jí) Prometheus Operator。
使用 helm 安裝 Prometheus Operator。使用 helm 安裝后,會(huì)在 Kubernetes 集群中創(chuàng)建、配置和管理 Prometheus 集群,chart 中包含多種組件:
prometheus-operator
prometheus
alertmanager
node-exporter
kube-state-metrics
grafana
收集 Kubernetes 內(nèi)部組件指標(biāo)的監(jiān)控服務(wù)
kube-apiserver
kube-scheduler
kube-controller-manager
etcd
kube-DNS/coredns
kube-proxy
安裝一個(gè)版本名為 my-release 的 chart:
helm install --name my-release stable/prometheus-operator
這會(huì)在集群中安裝一個(gè)默認(rèn)配置的 prometheus-operator。這份配置文件列出了安裝過程中可以配置的選項(xiàng)。
默認(rèn)會(huì)安裝 Prometheus Operator, Alertmanager, Grafana。并且會(huì)抓取集群的基本信息。
卸載 my-release
部署:
helm delete my-release
這個(gè)命令會(huì)刪除與這個(gè) chart 相關(guān)的所有 Kubernetes 組件。
這個(gè) chart 創(chuàng)建的 CRDs 不會(huì)被默認(rèn)刪除,需要手動(dòng)刪除:
kubectl delete crd prometheuses.monitoring.coreos.com kubectl delete crd prometheusrules.monitoring.coreos.com kubectl delete crd servicemonitors.monitoring.coreos.com kubectl delete crd podmonitors.monitoring.coreos.com kubectl delete crd alertmanagers.monitoring.coreos.com
Prometheus Operator 架構(gòu)圖如下:
上面架構(gòu)圖中,各組件以不同的方式運(yùn)行在 Kubernetes 集群中:
Operator: 根據(jù)自定義資源(Custom Resource Definition / CRDs)來部署和管理 Prometheus Server,同時(shí)監(jiān)控這些自定義資源事件的變化來做相應(yīng)的處理,是整個(gè)系統(tǒng)的控制中心。
Prometheus:聲明 Prometheus deployment 期望的狀態(tài),Operator 確保這個(gè) deployment 運(yùn)行時(shí)一直與定義保持一致。
Prometheus Server: Operator 根據(jù)自定義資源 Prometheus 類型中定義的內(nèi)容而部署的 Prometheus Server 集群,這些自定義資源可以看作是用來管理 Prometheus Server 集群的 StatefulSets 資源。
ServiceMonitor:聲明指定監(jiān)控的服務(wù),描述了一組被 Prometheus 監(jiān)控的目標(biāo)列表。該資源通過 Labels 來選取對(duì)應(yīng)的 Service Endpoint,讓 Prometheus Server 通過選取的 Service 來獲取 Metrics 信息。
Service:簡(jiǎn)單的說就是 Prometheus 監(jiān)控的對(duì)象。
Alertmanager:定義 AlertManager deployment 期望的狀態(tài),Operator 確保這個(gè) deployment 運(yùn)行時(shí)一直與定義保持一致。
Prometheus Operater 定義了如下的四類自定義資源:
Prometheus
ServiceMonitor
Alertmanager
PrometheusRule
Prometheus 自定義資源(CRD)聲明了在 Kubernetes 集群中運(yùn)行的 Prometheus 的期望設(shè)置。包含了副本數(shù)量,持久化存儲(chǔ),以及 Prometheus 實(shí)例發(fā)送警告到的 Alertmanagers等配置選項(xiàng)。
每一個(gè) Prometheus 資源,Operator 都會(huì)在相同 namespace 下部署成一個(gè)正確配置的 StatefulSet,Prometheus 的 Pod 都會(huì)掛載一個(gè)名為
一個(gè)樣例配置如下:
kind: Prometheus metadata: # 略 spec: alerting: alertmanagers: - name: prometheus-prometheus-oper-alertmanager # 定義該 Prometheus 對(duì)接的 Alertmanager 集群的名字, 在 default 這個(gè) namespace 中 namespace: default pathPrefix: / port: web baseImage: quay.io/prometheus/prometheus replicas: 2 # 定義該 Proemtheus “集群”有兩個(gè)副本,說是集群,其實(shí) Prometheus 自身不帶集群功能,這里只是起兩個(gè)完全一樣的 Prometheus 來避免單點(diǎn)故障 ruleSelector: # 定義這個(gè) Prometheus 需要使用帶有 prometheus=k8s 且 role=alert-rules 標(biāo)簽的 PrometheusRule matchLabels: prometheus: k8s role: alert-rules serviceMonitorNamespaceSelector: {} # 定義這些 Prometheus 在哪些 namespace 里尋找 ServiceMonitor serviceMonitorSelector: # 定義這個(gè) Prometheus 需要使用帶有 k8s-app=node-exporter 標(biāo)簽的 ServiceMonitor,不聲明則會(huì)全部選中 matchLabels: k8s-app: node-exporter version: v2.10.0
Prometheus 配置
ServiceMonitor 自定義資源(CRD)能夠聲明如何監(jiān)控一組動(dòng)態(tài)服務(wù)的定義。它使用標(biāo)簽選擇定義一組需要被監(jiān)控的服務(wù)。這樣就允許組織引入如何暴露 metrics 的規(guī)定,只要符合這些規(guī)定新服務(wù)就會(huì)被發(fā)現(xiàn)列入監(jiān)控,而不需要重新配置系統(tǒng)。
要想使用 Prometheus Operator 監(jiān)控 Kubernetes 集群中的應(yīng)用,Endpoints 對(duì)象必須存在。Endpoints 對(duì)象本質(zhì)是一個(gè) IP 地址列表。通常,Endpoints 對(duì)象由 Service 構(gòu)建。Service 對(duì)象通過對(duì)象選擇器發(fā)現(xiàn) Pod 并將它們添加到 Endpoints 對(duì)象中。
一個(gè) Service 可以公開一個(gè)或多個(gè)服務(wù)端口,通常情況下,這些端口由指向一個(gè) Pod 的多個(gè) Endpoints 支持。這也反映在各自的 Endpoints 對(duì)象中。
Prometheus Operator 引入 ServiceMonitor 對(duì)象,它發(fā)現(xiàn) Endpoints 對(duì)象并配置 Prometheus 去監(jiān)控這些 Pods。
ServiceMonitorSpec 的 endpoints 部分用于配置需要收集 metrics 的 Endpoints 的端口和其他參數(shù)。在一些用例中會(huì)直接監(jiān)控不在服務(wù) endpoints 中的 pods 的端口。因此,在 endpoints 部分指定 endpoint 時(shí),請(qǐng)嚴(yán)格使用,不要混淆。
注意:endpoints(小寫)是 ServiceMonitor CRD 中的一個(gè)字段,而 Endpoints(大寫)是 Kubernetes 資源類型。
ServiceMonitor 和發(fā)現(xiàn)的目標(biāo)可能來自任何 namespace。這對(duì)于跨 namespace 的監(jiān)控十分重要,比如 meta-monitoring。使用 PrometheusSpec 下 ServiceMonitorNamespaceSelector, 通過各自 Prometheus server 限制 ServiceMonitors 作用 namespece。使用 ServiceMonitorSpec 下的 namespaceSelector 可以現(xiàn)在允許發(fā)現(xiàn) Endpoints 對(duì)象的命名空間。要發(fā)現(xiàn)所有命名空間下的目標(biāo),namespaceSelector 必須為空。
spec: namespaceSelector: any: true
一個(gè)樣例配置如下:
kind: ServiceMonitor metadata: labels: k8s-app: node-exporter # 這個(gè) ServiceMonitor 對(duì)象帶有 k8s-app=node-exporter 標(biāo)簽,因此會(huì)被 Prometheus 選中 name: node-exporter namespace: default spec: selector: matchLabels: # 定義需要監(jiān)控的 Endpoints,帶有 app=node-exporter 且 k8s-app=node-exporter標(biāo)簽的 Endpoints 會(huì)被選中 app: node-exporter k8s-app: node-exporter endpoints: - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token interval: 30s # 定義這些 Endpoints 需要每 30 秒抓取一次 targetPort: 9100 # 定義這些 Endpoints 的指標(biāo)端口為 9100 scheme: https jobLabel: k8s-app
ServiceMonitor 配置
Alertmanager 自定義資源(CRD)聲明在 Kubernetes 集群中運(yùn)行的 Alertmanager 的期望設(shè)置。它也提供了配置副本集和持久化存儲(chǔ)的選項(xiàng)。
每一個(gè) Alertmanager 資源,Operator 都會(huì)在相同 namespace 下部署成一個(gè)正確配置的 StatefulSet。Alertmanager pods 配置掛載一個(gè)名為 Secret
, 使用 alertmanager.yaml
key 對(duì)作為配置文件。
當(dāng)有兩個(gè)或更多配置的副本時(shí),Operator 可以高可用性模式運(yùn)行Alertmanager實(shí)例。
一個(gè)樣例配置如下:
kind: Alertmanager # 一個(gè) Alertmanager 對(duì)象 metadata: name: prometheus-prometheus-oper-alertmanager spec: baseImage: quay.io/prometheus/alertmanager replicas: 3 # 定義該 Alertmanager 集群的節(jié)點(diǎn)數(shù)為 3 version: v0.17.0
Alertmanager 配置
PrometheusRule CRD 聲明一個(gè)或多個(gè) Prometheus 實(shí)例需要的 Prometheus rule。
Alerts 和 recording rules 可以保存并應(yīng)用為 yaml 文件,可以被動(dòng)態(tài)加載而不需要重啟。
一個(gè)樣例配置如下:
kind: PrometheusRule metadata: labels: # 定義該 PrometheusRule 的 label, 顯然它會(huì)被 Prometheus 選中 prometheus: k8s role: alert-rules name: prometheus-k8s-rules spec: groups: - name: k8s.rules rules: # 定義了一組規(guī)則,其中只有一條報(bào)警規(guī)則,用來報(bào)警 kubelet 是不是掛了 - alert: KubeletDown annotations: message: Kubelet has disappeared from Prometheus target discovery. expr: | absent(up{job="kubelet"} == 1) for: 15m labels: severity: critical
PrometheusRule 配置
它們之間的關(guān)系如下圖:
Prometheus Operator 中所有的 API 對(duì)象都是 CRD 中定義好的 Schema,API Server會(huì)校驗(yàn)。當(dāng)開發(fā)者使用 ConfigMap 保存配置沒有任何校驗(yàn),配置文件寫錯(cuò)時(shí),自表現(xiàn)為功能不可用,問題排查復(fù)雜。在 Prometheus Operator 中,所有在 Prometheus 對(duì)象、ServiceMonitor 對(duì)象、PrometheusRule 對(duì)象中的配置都是有 Schema 校驗(yàn)的,校驗(yàn)失敗 apply 直接出錯(cuò),這就大大降低了配置異常的風(fēng)險(xiǎn)。
Prometheus Operator 借助 K8S 將 Prometheus 服務(wù)平臺(tái)化。有了 Prometheus 和 AlertManager 這樣的 API 對(duì)象,非常簡(jiǎn)單、快速的可以在 K8S 集群中創(chuàng)建和管理 Prometheus 服務(wù)和 AlertManager 服務(wù),以應(yīng)對(duì)不同業(yè)務(wù)部門,不同領(lǐng)域的監(jiān)控需求。
ServiceMonitor 和 PrometheusRule 解決了 Prometheus 配置難維護(hù)問題,開發(fā)者不再需要去專門學(xué)習(xí) Prometheus 的配置文件,不再需要通過 CI 和 k8s ConfigMap 等手段把配置文件更新到 Pod 內(nèi)再觸發(fā) webhook 熱更新,只需要修改這兩個(gè)對(duì)象資源就可以了。
到此,關(guān)于“Prometheus-operator的介紹和配置方法”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí),請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章!