監控的基本理論和prometheus安裝
前言
這篇博客主要講的是關于理論的知識,大家盡可能的消化和吸收,也能擴展大家的知識面
監控的基本概念
監控俗稱為運維的第三只眼。沒有了監控,業務運維都是“瞎子”。所以說監控室運維這個職業的根本,尤其是在Devops這么活的時候,用監控數據給自己撐腰,這個顯得更加的必要,有人說運維是背鍋俠,那么有了監控,就有了證據,一切以證據說話,運維就不需要背鍋了,
所以作為一個運維工程師,如何構建一套監控系統是你的第一個工作
SRE必修課程,搞懂SLI,SLO,SLA的區別
SRE團隊主要承擔的職責,可用性的改進,延遲優化,效率提高,變更管理,監控,緊急事物的處理以及容量規劃與管理,總結一句話,就是提升服務質量,就要指定一個針對于客戶服務質量的目標,這就是今天要聊的SLI,SLO,SLA
- SLI
SLI是指的服務質量水平標準(service level lndicator)用來描述一個服務有多好,達到好的標準,對于業務來說是重要的指標,對于一個網站而言,一個常見的sli是 請求的響應時間是多少,比如tcp延遲小于200ms,又比如pod在一分鐘內交付。我i們通常從延遲性,可用性,吞吐率和成功率這些角度來指定sli
- SLO
slo (service level object) 表示目標服務器,來衡量一個SLI指標在一段時間內達到好的標準比例,通常是一個百分比,并與一個時間范圍內掛鉤,比如,月度、季度、年度等。如果脫離了時間的度量,SLO的意義就不大了。比如說,99%的Pod在1min內交付。每月 99.99% 的 TCP 請求延遲(SLI)小于 200ms。
- SLA
SLA是服務水平協議,常用于SLO定義的目標比例唯有完成時,服務器方要賠付多少。
區別SLO和SLA的一個簡單方法是問“如果SLO沒有達到時,有什么后果?”如果沒有定義明確的后果,那么我們就肯定是在討論一個SLO,而不是SLA。
監控方法論
目前業界比較流行的方法論有Google的4個黃金指標,RED方法,USE方法
Google的4個黃金指標
google的4個黃金指標對于服務器監控分別是延遲,流量,錯誤和飽和度。
延遲:表示服務請求所花費的時間,比如說用戶獲取商品列表上的每個接口,花費30毫秒,注意請求成功的延遲和失敗請求的延遲區別。通常延遲較高時不好的表現,大多數的情況下也意味著系統的系統系能不好,用戶的體驗不好。
流量:表示系統承載的用戶活交易的量級,流量對于不同類型的服務而言可能代表著不同的含義,比如對于web的http應用。這類的指標可能表現為tps,qps,流量指標通常是2用來展現當前系統的負載狀態和不同時段的負載情況。
錯誤:表示當前系統發生錯誤的評價維度,錯誤一般可以分為顯示錯誤和隱藏式錯誤。
舉例子來說:http返回了500狀態碼,說明這個請求是失敗的,也就屬于顯示錯誤,而某些情況下,http盡管返回了200的狀態碼但是返回的內容不符合預期這個就是隱藏式的錯誤,也就是請求失敗。此類指標可以用來衡量系統的運行質量
飽和度:表示當前資源使用的飽和度情況,通常情況下,資源達到飽和度,服務器的性能會下降,比如磁盤的讀寫功能,還有式I/o操作下降會處于阻礙狀態,此外cpu使用率也可以作為飽和度的指標,這類指標可以衡量系統資源的使用率
RED方法
RED方法式Google的4類的黃金指標基礎上提出的,它重點關注應用請求的3個關鍵指標,希望由此涵蓋web服務(也是占比最高的服務類型)相關問題
(Request)Rate:請求速率,每秒請求數
(Request)Errors:錯誤,每秒,錯誤請求數量
(Request)Duration:延遲,每一個請求延遲分布情況
三個英文單詞取首字母組成 RED 方法,姑且可以看做是 Google 四個黃金指標的簡化版。RED方法是以請求為中心,聚焦用戶在使用Web服務時所應關注的重點,通過這三項指標,我們就能監測到 通常情況下影響客戶使用體驗的關鍵信息。
Red方法,主要適用于關注和請求相關的指標數據,適合云原生應用和微服務應用下的應用
USE 方法
USE 是使用率(Utilization)、飽和度(Saturation)、錯誤(Error)的縮寫,主要用于分析資源問題。
什么是資源?主要是指傳統意義上的物理服務器組件,比如 CPU、硬盤等,但現在很多人已經擴展了資源的范圍,把一些軟件資源也包含在內。下面我們對使用率、飽和度、錯誤做一個更詳細的解釋。
資源使用率:這個我們最熟悉,比如CPU、內存、網絡、磁盤I/O等。如果某項資源使用率持續較高,那么通常說明其存在一定的性能瓶頸。
飽和度:與Google的4個黃金信號中的飽和度意義相同。
錯誤:與錯誤相關的指標統計信息,比如調用失敗次數、或通過 ifconfig 看到的 errors、dropped 包量。還有很多錯誤是以系統錯誤日志的方式暴露的,沒法直接拿到某個統計指標,此時可以進行日志關鍵字監控。
USE 方法,可以從資源使用率、資源飽和度等指標維度進行監控和分析,對于系統性能監控和性能瓶頸識別可以起到很好的作用,適用于主機級監控。
需要監控的指標有那些
我們在這里用一個圖來表示
1.資源監控
資源監控,主要是針對硬件設備和網絡,硬件設備又分為服務器,網絡設備又衍生為通信監控,質量監控,流量監控
2.組件監控
我們將常用web,數據庫,中間間,容器等系統通常稱之為組件,因此監控組件。
3.應用監控
應用監控就是指對應用程序(Application)的監控,Google 的四個黃金指標、RED 方法主要就是針對應用監控的。其實主要監控的是應用的性能指標
4.業務監控
這類監控指標非常重要,它代表著業務系統是否正常,同時也是管理層非常關注的,因為業務系統代表企業營收,或者跟客戶項目相關,核心業務指標異常,一定是故障,業務指標異常代表著最終用戶體驗受損,或者造成公司直接資產損失。
5、監控與可觀測性
監控的本質就是收集、分析和使用信息來觀察一段時間內監控對象的運行進度,并且進行相應的決策管理的過程,監控側重于觀察特定指標。
但是隨著云原生時代的到來,我們對監控提出了更多的要求:
通過監控了解數據趨勢,知道系統在未來的某個時刻可能出問題,預知問題。
通過監控了解系統的資源情況,為服務擴縮容提供數據支撐。
通過監控來給系統把脈,感知到哪里需要優化,比如一些中間件參數的調優。
通過監控來洞察業務,提供業務決策的數據依據,及時感知業務異常。
要實現這些功能,就是今天要講的“可觀測性”。可觀測性是云原生時代必須具備的能力。目前,“可觀測性”逐漸取代“監控”,成為云原生技術領域最熱門的話題之一。
可觀測性是指在軟件系統中,通過度量、監控和分析系統的各個組件行為,以便于了解系統的狀態、性能和問題的能力。
可觀測性的重要性在于它可以幫助開發人員及時發現問題,快速定位問題,并在問題發生時采取相應的措施,以減少系統的故障率和維護成本。此外,可觀測性還有助于開發人員了解系統的實際運行情況,以便于對系統進行優化和升級。
在可觀測性中,有三個重要的組件:
- 聚合指標:聚合指標指的是將多個指標數據聚合到一個單獨的指標中以簡化數據。例如,將多個節點的 CPU 利用率聚合為一個單一的平均值。聚合指標允許我們更輕松地理解系統的整體性能。同時,聚合指標還可以幫助我們快速識別潛在問題并了解系統中哪些部分 可能需要更多的資源。
- 事件日志:事件日志是一組事件的記錄,這些事件可以提供系統的歷史記錄和狀態變化。例如,錯誤、警告和信息性事件都可以記錄在事件日志中。事件日志對于診斷和調試問題非常有用,因為它們提供了對系統活動的詳細記錄。還可以發現系統中無法預知的行為。
- **鏈路追蹤:鏈路追蹤是一種用于跟蹤分布式系統中請求的過程,以了解請求的路徑以及請求在每個服務中花費的時間。**這有助于識別分布式系統中的性能瓶頸和瓶頸來源。鏈路追蹤還可以幫助我們診斷分布式系統中出現的錯誤和問題,因為它提供了有關請求在哪個組件中失敗的信息。
因此,可觀測性能夠回答以下幾個問題:
- 性能瓶頸有哪些
- 請求需要接受的服務有哪些
- 請求執行過程與系統行為之間的差異性
- 請求失敗的原因
- 每一個微服務將如何處理請求
Prometheus的組件和架構
Prometheus介紹
Prometheus是一套開源的系統監控報警框架,作為新一代的云原生監控系統,Prometheus既可以實現主機為中心的監控,也可以完成以服務為導向的動態架構監控,在微服務的世界里,它支持多維度的數據集合,查詢功能非常強大,
Prometheus的優勢
- 簡單部署,Prometheus唯一需要的是一個本地磁盤,因為他的核心是一個二進制的文件,沒有數據庫,緩存等一系列的第三方的依賴
- Prometheus可以實現監控服務的內部狀態
- Prometheus 內置強大的一個數據查詢語言PromQL,通過PromQL可以實現對于數據的查詢,聚合。
- Prometheus可以高速的處理10多萬的數據。
與zabbix相比,使用的場景區別
- 偏基礎的監控,像主機,網絡這種場景,使用zabbix更加適合
- 簡單來說更適合于硬件方面,cpu,硬盤,內存。。。
- 偏服務類型的容器的,使用Prometheus來作為監控。
一句話總結
服務類如:mysql,redis,php,python用于Prometheus
硬件類如:硬盤,cpu,內存
Prometheus的組件和架構
Prometheus 的生態系統包括多個組件,大部分組件都是由go語言編寫而成,因此部署十分的方便,而這些組件都是可以選擇的
主要的組件如下
Prometheus Server
Prometheus Server 是prometheus的核心組件之一,負責對于監控數據的獲得,存儲以及查詢推送網關(push gateway)
主要是用來接收client push 推送過來的指標數據,在指定的時間間隔,由Prometheus Server來抓取Exporter
主要來采集數據,通過http服務的形式暴露于 Prometheus server -》它通過訪問Exporter提供接口,即可采集到監控數據數據
常見的Exporter有很多,例如node_exporter、mysqld_exporter、statsd_exporter、blackbox_exporter、haproxy_exporter等等,支持如 HAProxy,StatsD,Graphite,Redis 此類的服務監控。警告管理器(Alertmanager)
管理告警,主要是負責實現監控報警功能。在Prometheus Server中支持基于PromQL創建告警規則,如果滿足PromQL定義的規則,則會產生一條告警,而告警的后續處理流程則由AlertManager進行管理。
pull 和 push
pull監控主動的拉取目標數據
push目標推送數據到監控
- Prometheus是通過HTTP方式抓取組件的狀態,任意組件只要提供的http接口符合Prometheus定義的數據格式,就可以接入prometheus監控
- Prometheus Server負責定時在目標上抓取metrics(指標)數據,每個抓取目標都需要暴露一個HTTP服務接口用于Prometheus定時抓取。這種調用被監控對象獲取監控數據的方式被稱為Pull(拉);Pull方式體現了Prometheus獨特的設計哲學與大多數采用Push(推)方式的監控不同
- Pull方式的優勢是可以降低耦合。pull模式可控性好,pull模式下,監控系統是主動的一方,可以控制頻率;push模式,客戶端是主動的一方,如果代碼寫的有問題,就會給監控系統造成很大壓力。所以通過Pull方式,被采集端無需感知監控系統的存在,完全獨立于監控系統之外,這樣數據的采集完全由監控系統控制。
- Pull方式的優勢是可以降低耦合。pull模式可控性好,pull模式下,監控系統是主動的一方,可以控制頻率;push模式,客戶端是主動的一方,如果代碼寫的有問題,就會給監控系統造成很大壓力。所以通過Pull方式,被采集端無需感知監控系統的存在,完全獨立于監控系統之外,這樣數據的采集完全由監控系統控制。
所以說pull模式完美打敗push模式
Prometheus安裝配置
時序數據庫全稱是時間序列數據庫,時間序列數據庫指用于處理時間標簽,按照時間順序變換,即時間上的變化,常用于物聯網設別和互聯網監控的業務場景,提供讀寫的性能和強聚合計算的服務。
時間序列數據庫主要按照一定的時間間隔產生一個個的數據點,以時間軸為橫坐標,序列為縱坐標,如圖所示:
時序數據庫的特點:
- 嚴重依賴于采集時間:每條數據都有一個時間戳,通常以UNIX時間為單位,可以方便地對數據進行排序和查詢。
- 數據產生頻率快:高并發寫入,主要是寫入和讀取操作,沒有更新操作,通常以秒或毫秒為單位,有時甚至會達到微秒級別。
- 存在明顯的冷熱數據:一般只會查詢近期數據。對冷數據降低精度存儲,對歷史數據做聚合,節省存儲空間。
- 大量的統計查詢要求:查詢一定時間范圍內的計數、最大值、最小值和平均值。
常見時序數據庫:InfluxDB、OpenTSDB等。
Prometheus數據指標的概念及命名方式
promethes監控中,對于采集過來的數據統稱為指標(metrics)數據,當我們需要為某個系統、某個服務做監控統計時,就需要用到指標數據。因此,指標是對采樣數據的總稱,注意,metrics并不代表某種具體的數據格式,它是對于度量計算單位的抽象。
Prometheus將采集的監控數據以指標(metric)的形式保存在內置的時間序列數據庫當中(TSDB),每一條時間序列是由 metric 的名字和一系列的標簽(key/value鍵值對)來唯一標識的,不同的標簽代表不同的時間序列。格式如下:
<metric name>{<label name>=<label value>, …}
-
metric(指標)名字:指標名稱可以反映監控樣本的含量,一般用于metric的功能,例如prometheus_http_requests_total, 表示http請求的總數。其中,metric 名字由 ASCII 字符,數字,下劃線,以及冒號組成。
-
標簽:標簽可以使 Prometheus的數據更加豐富,對于相同的指標名稱,通過不同標簽列表的集合,會形成特定的維度實例。改變任何指標上的任何標簽值(包括添加或刪除指標),都會創建新的時間序列。例如:
prometheus_http_requests_total{code="200"}
在時間序列中的每一個點稱為一個樣本(sample),時間序列的樣本數據包括一個float64的值和一個毫秒級的unix時間戳,這些數據是按照某個時序以時間維度采集的數據。這樣,一個完整的時間序列的組成如下圖所示:
下面的例子:
<--------------- metric and lable----------------------><-timestamp -> <-value->
http_request_total{status="200", method="GET"} @1434417560938 => 94355
http_request_total{status="200", method="GET"} @1434417561287 => 94334
?
http_request_total{status="404", method="GET"} @1434417560938 => 38473
http_request_total{status="404", method="GET"} @1434417561287 => 38544
?
http_request_total{status="200", method="POST"} @1434417560938 => 4748
http_request_total{status="200", method="POST"} @1434417561287 => 4785
Prometheus server 下載
安裝Prometheus之前必須要先安裝ntp時間同步,因為prometheus server對系統時間的準確性要求很高,必須保證本機時間實時同步。這里我們以Almalinux9.1/RHEL9.1為例,先執行時間同步,執行如下計劃任務:
[root@docker-110 ~]# timedatectl set-timezone Asia/Shanghai
[root@docker-110 ~]# crontab -e
首先需要到Prometheus官網 http://prometheus.io 下載最新版本的Prometheus,自己去下載
安裝與啟動Prometheus server
prometheus的安裝非常簡單,只需解壓即可,然后執行命令可直接啟動。
[root@localhost ~]# tar -xvzf prometheus-2.44.0.linux-amd64.tar.gz
[root@localhost ~]# mv prometheus-2.44.0.linux-amd64 /usr/local/prometheus[root@docker-110 prometheus]# ll
total 302892
-rw-r--r-- 1 1001 docker 11357 Jun 30 21:38 LICENSE
-rw-r--r-- 1 1001 docker 3773 Jun 30 21:38 NOTICE
-rwxr-xr-x 1 1001 docker 159395306 Jun 30 21:25 prometheus
-rw-r--r-- 1 1001 docker 1093 Jun 30 21:38 prometheus.yml
-rwxr-xr-x 1 1001 docker 150742130 Jun 30 21:25 promtool
[root@docker-110 local]# cd prometheus/
[root@docker-110 prometheus]# ./prometheus --version
prometheus, version 3.5.0-rc.0 (branch: HEAD, revision: 31f0c7007e7187b706da03e05aeeb303101164f8)build user: root@d6b2cb516986build date: 20250630-13:23:30go version: go1.24.4platform: linux/amd64tags: netgo,builtinassets
使用systemctl管理prometheus
# 創建prometheus本地存儲的數據庫
mkdir -p /var/lib/prometheusvim /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus
Documentation=https://prometheus.io/
After=network.target[Service]
# Type設置為notify時,服務會不斷重啟
Type=simple
User=root
# --storage.tsdb.path是可選項,默認數據目錄在運行目錄的./dada目錄中
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus --web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure[Install]
WantedBy=multi-user.target
訪問本機ip:9090地址