??本文由于工作任務需要，快速入門了一下Prometheus的一些相關理論知識，供開發過程中快速查閱。

一：監控概念&誤區

監控是管理基礎設施和業務的核心工具，監控應該和應用程序一起構建和部署，沒有監控，將無法了解你的系統運行環境，進行故障診斷，也無法阻止提供系統性的性能、成本和狀態等信息

誤區：
??要盡量避免進行機械式的監控、不夠準確的監控、靜態和監控、不頻繁的監控、缺少自動化或自服務

二：黑盒監控&白盒監控

1. 黑盒監控（也叫探針）

• 應用程序或主機是從外部觀察的，因此，這種方法可能相當有限。檢查是為了評估被觀察的系統是否以已知的方式響應探測。
• 例子：
  (1) 主機是否相應PING的請求
  (2)特定的TCP端口是否打開
  (3)應用程序在接受到特定的HTTP請求時，是否使用正確的數據和狀態代碼進行響應
  (4)特定應用程序的進程是否在其主機中運行

2. 白盒監控

系統在被測對象表面顯示其內部狀態和臨界段的性能數據。這種類型的自省可能非常強大，因為它暴露了內部操作，顯示不同內部組件的健康狀況，否則很難甚至不可能確定。這種數據處理通常以胰腺癌方式進行處理：
（1）通過日志導出：到目前為止。這是也是在廣泛引入庫之前，應用程序是如何暴露其內部工作的最常見的情況，例如：可以處理HTTP服務器的訪問日志來監視請求率、延遲和錯誤百分比
（2）以結構化的事件輸出：這種方法類似于日志記錄，但不是將數據寫入磁盤，而是直接將數據發送到處理系統進行分析和聚合。
（3）以聚合的方式保存在內存中：這種格式的數據可以駐留在端點中，也可以直接從命令行工具中讀取。這種方法的例子有/metrics with Prometheus metrics、HAProxy的stats頁面或varnishstats命令行工具

三：度量指標

度量指標有監控系統執行的過程通常可以分為兩種方式——push（監控系統去服務進行拉取）、pull（被監控的服務自動往監控系統進行推送）【站在客戶的角度】

• push VSpull
• 測量什么：
  ??谷歌提出應該監控的四個指標：
  1、延遲：服務請求所需的時間
  2、流量：正在發出的請求的數量
  3、錯誤：求失敗的比率
  4、飽和：未處理的工作量，通常在隊列中
  ??Brendan的方法更關注于及其，他聲明對于每個資源（CPU、磁盤、網絡接口等等），應該監視以下指標：
  1、利用率：以資源繁忙的百分比來衡量
  2、飽和：資源無法處理的工作量，通常會排隊
  3、錯誤：發生的錯誤數量
  ??湯姆威爾基的紅色方法：更側重于服務級別方法，而不是底層系統本身。顯然，這種才領略對于見識服務很有用，對于預測外部客戶的體驗也很有價值。如果服務的錯誤率增加，那么就可以合理地假設這些錯誤將直接或間接地影響客戶的體驗。
  1、速率：轉換成每秒請求數
  2、錯誤：每秒失敗請求的數量
  3、持久性：這些請求所花費的時間

四：Prometheus

1. 介紹&架構

??介紹：Prometheus是一個開源系統監控和警報工具包，將其監控的指標進行收集并存儲為時間序列數據，即指標信息與記錄時的時間戳以及稱為標簽的可選鍵值對一起存儲。很多公司用來監控K8s集群。

其架構組成：

• Prometheus server用于抓取和存儲時間序列化數據
• 用于檢測應用程序代碼的客戶端庫
• 支持短期工作的推送網關Pushgateway
• HAProxy、StatsD、Graphite等服務的專用出口商
• 處理警報的警報管理器AlertManager
• 各種支持工具

2. 合適&不合適場景

??合適場景：Prometheus可以很好地記錄任何數字時間序列，它既適合以機器為中心的監控，也適合監控高度動態的面向服務的架構。在微服務的世界中，他對多維數據收集的查詢的支持是一個特殊的優勢。專為可靠性而設計，是在中斷期間可以使用的系統，可讓你快速診斷問題。每個Prometheus服務器都是獨立的，不依賴于網絡存儲或其他遠程服務。當你的基礎設施的其他部分損壞時，你可以依賴他，并且你無需設置大量基礎設施即可使用
??不合適場景：你需要100%準確性，例如按請求計費。這時候Prometheus就不太適合，你最好使用其他系統來收集和分析數據以進行計費。

3. 數據模型

因為監控數量極大，所以使用了時間序列數據存儲（就是帶時間戳和值的）

• Prometheus本地存儲：
  ??Prometheus的本地存儲被稱為Prometheus TSDB。TSDB的設計核心有兩個：block和WAL，而block又包含chunk、index、meta.json、tombstones。
  ??TSDB將存儲的監控數據按照時間分隔成block，block大小并不固定，按照設定的步長倍數遞增。隨著數據量的不斷增長，TSDB會將小的block合并成大的block，這樣不僅可以減少數據存儲，還可以減少內存中的block個數，便于對數據進行索引。
  ??每個block都有全局唯一的名稱，通過ULID（Universally Unique Lexicograpphically Sortable Indetifier，全局字典可排序ID）原理生成，可以通過block的文件名確定這個block的創建時間，從而很方便的按照時間對block排序。對時序數據庫的查詢通常會涉及到連續的很多塊，這種通過命名便可以排序的設計非常簡便。
  ??WAL（Write-Ahead Logging，預寫日志）是關系型數據庫中利用日志來實現事務性和持久性的一種技術，即在進行某個操作之前先將這件事情記錄下來，以便之后數據進行回滾、重試等操作并保證數據的可靠性。Prometheus為了防止丟失暫存在內存中還未被寫入磁盤的監控數據，引入了WAL機制。
  ??按照每種對象設定的采集周期，Prometheus會將周期性采集的監控數據通過Add接口添加到head block中，但這些數據沒有被持久化，TSDB通過WAL將提交的數據先保存到磁盤中，在TSDB宕機重啟后，會首先啟動多協程讀取WAL，從而恢復之前的狀態。
• Prometheus數據模型：
  ??Prometheus將數據存儲為時間序列，其中包括稱為標簽的鍵值對、時間戳和最后的值
  ??表示法：<metric_name>[{<label_1=“value_1”>,<label_N=“value_N”>}]<datapoint_numercial_value>

4. 指標

Counter：Prometheus實例接收的數據包總數**（一直增）**

• Gauge：測量是一種度量，他在收集時對給定的測量進行快照，可以增加或減少（例如溫度、磁盤空間、內存使用量）
• Histogram：常常用于觀察，一個Histogram包含下列值的合并：【某時間段內的百分比或者請求數量有多少】
  （1）Buckets：桶是觀察的計數器，他應該有個最大值的邊界和最小值的邊界。
  （2）觀察結果的和，這是所有觀察的和
  （3）觀察結果統計，這是在本次觀察的和
  （4）Summaries：蕾絲Histogram

5. 指標的摘要和聚合

指標摘要：通常來說。單個指標對我們來說價值很小，往往需要聯合并可視化多個指標，這其中需要一些數學變換，例如我們可能會統計函數應用于指標或指標組，常見函數有：計數、求和、平均值、中間數、百分位數、標準差、變化率等等

• 指標聚合：就是能看到來自多個源的指標的聚合視圖

6. Prometheus部署【省】

7. Prometheus配置【省】

重新標記：有兩個階段可以重新標記。第一階段是對來自服務發現的目標進行重新標記，這是對來自服務發現的元數據標簽中的信息應用于指標上的標簽來說非常有用。第二階段是抓取指標之后但是在存儲系統之前，這樣就可以確定哪些指標需要保存，那些需要丟棄以及這些指標的樣式

8. NodeExporter部署

Prometheus使用exporter工具來暴露主機和應用程序上的指標。有很多種類型的exporter。

9. cAdvisor監控Docker容器

cAdvisor（Constainer Advisor）是由谷歌開發的一個項目，讓從正在運行的容器手機、聚合、分析和導出數據。可用的數據涵蓋了幾乎所有你可能需要的東西，從內存限制到GPU指標

• cAdvisor并不綁定到Docker容器，但它通常作為一個容器部署，從容器守護進程和Linux cgroups收集數據，是容器的發現透明且完全自動化。
• 除了以Prometheus格式公開指標之外，cAdvisor還提供了一個有用的web界面，允許即使可視化主機及其容器的狀態

10. 捕獲目標生命周期

服務發現——》配置——〉重新標記（relable_configs）——》抓取——〉metrics_relable_configs

11. PromQL查詢語言

選擇器及標簽匹配器：
（1）選擇器：Prometheus被設計用來處理成千上萬的時間序列、根據標簽的組合，咩哥指標名稱可以有幾個不同的時間序列；當來自不同的工作的類型名稱的指標混合在一起時，查詢正確的數據可能看起來比較困難。所以在Prometheus中，選擇器指的是一組標簽匹配器、度量名稱也包含在這個定義中，因為從技術上講，他的內容表示也是一個標簽，盡管是一個特殊的標簽：name。選擇器中的每個標簽名稱/值對稱為標簽匹配器，多個匹配器可用于進一步篩選選擇器匹配的時間序列。標簽匹配器用花括號括起來。如果不需要匹配器，可以省略花括號。選擇器可以返回及時或范圍向量

//例如： $ prometheus_build_info{version="2.17.0"}

（2）標簽匹配器

• 標簽匹配器用于將查詢搜索限制為特定的一組標簽值。下面將使用node_cpu_secends_total metric來闡述標簽匹配的操作，匹配的操作符有=、!=、=_和! 如果沒有任何匹配的規范。僅此度量就會返回一個包含度量名稱的所有可用時間序列的及時向量。以及所有的CPU核心數（cpu=“0”，cpu=“1”）和CPU的型號（mode=“idle”，mode=“iowait”，mode=“irq”，mode=“nice”，mode=“softirq”，mode=“steal”，mode=“user”，mode=“system”）
  （3）范圍、偏移、子查詢
• 范圍向量：如果要定義一個范圍向量選擇查詢，你必須設置一個及時向量選擇器和使用[]追加一個范圍。
• 偏移量的修飾符：offset的修飾符查詢過去的數據，也就是說可雙選擇相對于當前時間的多長時間以前
• 子查詢【省，道理類似于mysql中】
  （4）PromQL操作符【省】
• 向量匹配：有one-to-one、many-to-one、one-to-many【其實就類似于mysql的左右外連接】
  （5）PromQL函數
• lable_join()和label_replace()這些函數用于操作標簽——他們允許您將標簽連接到其他標簽，提取標簽值的一部分，甚至刪除標簽（盡管使用標準的聚合操作更容易、更符合人體工程學）。在這兩個函數中，如果定義的目標標簽是一個新的，它將被添加到標簽集；如果他是一個現有的標簽，它將被取代。【也就是說，如果該語句滿足什么條件的話，機會產生相對應的結果】
• predict_linear（）函數可以預測時間序列v在t秒后的值，它基于簡單線性回歸的方式，對時間窗口內的樣本數據進行統計，從而可以對時間序列的變化趨勢作出預測。該函數的返回結果不帶有度量指標，只有標簽列表。
• rate()和irate()函數：
• sort()和sort_desc()

12. 計算CPU的使用率

//例子： avg(irate(node_cpu_seconds_total{job="node"}[5m] by (instance) * 100))

13. 計算CPU負載(飽和度)

在主機上獲得CPU飽和的一種方法是跟蹤平均負載，實際上它是將主機上的CPU數量考慮在內的一段時間內的平均運行隊列長度。平均負載少于CPU的數量通常是正常的，長時間內超過該數字的平均值則表示CPU已經飽和。

• 要查看主機的平均負載，可以使用node_load*指標，他們顯示1分鐘、5分鐘和15分鐘的平均負載。比如使用1分鐘的平均負載：node_load1

//計算主機上的CPU數量，可以使用count聚合實現 count by (instance)(node_cpu_seconds_total{mode="idle"}) //接下來將此計算與node_load指標結合起來 node_load1 > on (instance) 2 * count by (instance)(node_cpu_seconds_total{mode="idle"}) //這里我們查詢的是1分鐘的負載超過主機CPU數量的兩倍的結果

14. 計算內存使用率

Node Exporter的內存指標按內存的類型和使用率進行細分。可以在node_memory為前綴的指標列表找到他們。

//查看主機上的總內存 node_memory_MemTotal_bytes //主機上的可用內存 node_memory_MemFree_bytes //緩沖緩存中的內存 node_memory_Buffers_bytes //頁面緩存中的內存 node_memory_Cached_bytes //通過以上的就可以計算出內存使用率 （總內存-可用內存-緩沖緩存中的內存-頁面緩沖中的內存）/總內存 * 100

15. 計算內存飽和度

還可以通過檢查內存和磁盤的讀寫來監控內存飽和度，可以使用從/proc/vmstat收集的兩個Node Exporter指標

• node_vmstat_pswpin：系統每秒從磁盤讀到內存的字節數
• node_vmstat_pswpout：系統每秒從內存寫到磁盤的字節數
• 兩者都是自上次啟動以來的字節數，以KB為單位
• 為了獲得飽和度指標，對每個指標計算每一分鐘的速率，將兩個速率相加，然后乘以1024獲得字節數

1024 * sum by (instance) ((rate(node_vmstat_pgpgin[1m]) + rate(node_vmstat_pgpgout[1m])))

• 然后，可以對此設置圖形化展示或者警報，以識別行為不當的應用程序主機。

16. 磁盤使用率

對于磁盤，只測量磁盤使用情況而不是使用率、飽和或錯誤。這是因為在大多數情況下，它是對可視化和警報最有用的數據。

//node_filesystem_size_bytes指標顯示了被監控的每個文件系統掛載的大小。 node_filesystem_size_bytes

• 可以使用與內存指標類似的查詢來生成在主機上使用的磁盤空間百分比

(node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_free_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100

• 與內存指標不同，在每個主機上的每個掛載點都有文件系統指標。所以添加了mountpoint標簽，特別是跟文件系統"/"掛載。這將在每臺主機上返回該文件系統磁盤使用指標
• 如果想要或需要監控特定掛載點，那么我們可以為其添加查詢。比如要監控/data掛載點，可以使用

(node_filesystem_size_bytes{mountpoint="/data"} - node_filesystem_free_bytes{mountpoint="/data"}) / node_filesystem_size_bytes{mountpoint="/data"} * 100

• 或者可以使用正則表達式匹配多個掛載點

(node_filesystem_size_bytes{mountpoint="/|/run"} - node_filesystem_free_bytes{mountpoint="/|/run"}) / node_filesystem_size_bytes{mountpoint="/|/run"} * 100

• 可以使用predict_linear函數來構建在未來什么時候會耗盡磁盤空間

//預測四小時之后磁盤空間會不會爆滿 predict_linear(node_filesystem_free_bytes{mountpoint="/"}[1h], 4* 3600) < 0

• 上面是指定跟文件系統，還可以通過制定作業名稱或使用正則表達式來選擇所有文件系統

predict_linear(node_filesystem_free_bytes{job="node"}[1h], 4* 3600) < 0

17. 服務狀態

systemd收集器的數據，它向我們展示了主機上的服務狀態和其他各種systemd配置。服務的狀態在node_systemd_unit_state指標中暴露出來。對于收集的每個服務和服務狀態都有一個指標。

//查詢docker的服務 node_systemd_unit_state{name="docker.service"} //此查詢為每個潛在的服務和狀態（failed、inactive、active）的組合生成指標，其中表示當前服務狀態的指標的值為1，我們可以通過state標簽來進一步縮小搜索范圍 node_systemd_unit_state{name="docker.service",state="active"} //或者可以搜索值為1的所有指標，這將返回當前服務的狀態 node_systemd_unit_state{name="docker.service"} == 1

18. up指標

用于監控特定節點狀態的另一個有用指標，對于每個實例抓取，Prometheus都會在以下時間序列中存儲樣本

//如果是健康的，則指標設置為1，即數據抓取成功返回，如果抓取失敗，則設置為0，指標使用作業名稱job和時間序列的實例instance來進行標記 up{job="<job-name>",instance="<instance-id>"}

19. metadata指標

使用Node Exporter的textfile收集器來查看我們創建的metadata指標

metadata{role="docker_server",datacenter="SH"} 1

20. 向量匹配

可以使用metadata指標來進行向量匹配，向量匹配可以使用任何的PromQL二次運算符。向量匹配嘗試針對左側向量中的每個元素在右側向量中查找對應的匹配元素。

• 一對一、多對一、一對多

21. 查詢持久化

可以通過以下三種方式使查詢持久化
（1）記錄規則：根據查詢創建新指標
（2）警報規則：從查詢生成警報
（3）可視化規則：使用Grafana等儀表板可視化查詢
之前的查詢都可以交替應用這三種機制，因此所有這些機制都能理解和執行PromQL查詢

• 記錄規則：一種根據已有時間序列計算新時間序列（特別是聚合時間序列）的方法
  （1）跨多個時間序列生成聚合
  （2）預先計算消耗大的查詢
  （3）產生可用于生成警報的時間序列
• 配置記錄規則：記錄規則存儲在Prometheus服務器上，位于Prometheus服務器加載的文件中，規則是自動計算的，頻率則由prometheus.yml配置文件中的evaluation_interval參數控制

22. 服務發現

對于指定的每個目標，在抓取配置中手動列出了他們的IP地址和端口。這種方法在主機較少時還行，但不適用于規模較大的集群，尤其不適用于使用容器和給予云的實例的動態集群，這些實例經常會出現變化、創建或銷毀的情況。

• Prometheus通過使用服務發現解決了這個問題：通過自動化的機制來檢測、分類和識別新的變更的目標。服務發現可以通過以下幾種機制實現：
  （1）從配置管理工具生成的文件中接收目標列表
  （2）查詢API以獲取目標列表
  （3）使用DNS記錄以返回目標列表
• 基于文件的服務發現：這些文件可以是YAML或JSON格式，包含定義的目標列表，就像我們在靜態配置中定義的一樣。讓我們將現有作業遷移到基于文件的服務發現開始。refresh_interval
• 基于API的服務發現：原生的服務發現集成在某些工具和平臺上提供，他們內置支持Prometheus，這些服務發現插件使用工具和現有的數據存儲或API來返回目標列表。當前可用的本機服務發現插件包括的平臺有（Amazon、Azure、Consul、Googe Compute Cloud、kubernetes）。監控K8s上運行的應用程序會用到K8s服務發現
• 基于DNS的服務發現：DNS服務發現允許你制定DNS條目列表，然后查詢這些條目中的記錄以發現目標列表。它依賴于A、AAAA或SRV DNS記錄查詢。dns_sd_configs

23. 警報的管理

Prometheus是一個按功能劃分的平臺，指標的收集和存儲與警報是分開的。警報管理功能由名為Alertmanager的工具提供，該工具是監控體系中的獨立組件。我們需要用Prometheus定義警報規則——觸發事件——傳播到Alertmanager——處理相應的警報——發送給對應的負責人員進行處理（釘釘、微信、郵件）

24 alertmanager集群部署【省】

25 alertmanager基本配置【省】

26 Prometheus與Alertmanager的集成

靜態配置：

• 需要告訴prometheus關于Alertmanager的信息，如果使用的默認prometheus.yml的配置【具體的配置項省】

服務發現：

• 由于我們可以使用服務發現機制，因此也可以使用這些機制來識別一個或多個AlertManager。我們可以添加一條DNS SRV記錄，讓Prometheus發現Alertmanager

27 添加警報規則

• 警報規則在Prometheus服務器配置中加載的規則文件，也是使用yaml語句定義
• 警報觸發：Prometheus以一個固定時間間隔來評估所有規則，這個時間由evaluate_interval定義，我們將其設置為5秒，在每個評估周期，Prometheus運行每個警報規則中定義的表達式并更新報警狀態。
• 警報可能有以下三種狀態：

Inactive：警報未激活

Pending：警報已滿足測試表達式條件，但仍在等待for字句中指定的持續時間

Firing：警報已滿足測試表達式條件，并且Pending的時間已超過for子句的持續時間

• Pending到Firing的轉換可以確保警報更有效，且不會來回浮動，沒有for子句的警報會自動從Inactive轉換為Firing，只需要一個評估周期即可觸發，帶有for子句的警報將首先轉換為Pending，然后轉換為Firing，因此至少需要兩個評估周期才能觸發。
• 警報的生命周期如下：

節點的CPU不斷變化，每隔一段時間由scrape_interval定義的時間被Prometheus抓取一次

根據每個evaluation_interval的指標來評估警報規則

當警報表達式為true時（比如CPU超過80%），會創建一個警報并轉換為Pending狀態，執行for子句

在下一個評估周期中，如果警報測試表達式仍然為true，則檢查for的持續時間，如果超過持續的時間，則警報將轉換為Firing，生成通知并將其推送到Alertmanager

如果警報測試表達式不再為true，則Prometheus會將警報規則的狀態從Pending更改為Inactive

28 alertmanager的路由定義

• 我們選擇了一些具有不同屬性的警報，需要將他們路由到不同的目的地。

29 接收器（發送方式）和通知模版【省】

30 警報的靜音

• 通常我們需要讓警報系統知道我們已經停止服務以進行維護，并且不希望觸發警報。或者，當上游出現問題時，我們需要將下游服務器和應用程序“靜音”。Prometheus稱這種警報靜音為silence。silence可以設定為特定時期
• 可以使用以下兩種方式來設置silence：

通過Alertmanager Web控制臺

通過amtool命令行工具

31 Prometheus的可靠性、容錯性和可擴展性

• Prometheus解決容錯問題的方法考慮到了操作和技術的復雜性。在多數情況下，監控服務的容錯性可以通過使監控服務高可用來解決。通常的實現方式是構建集群。但是，集群解決方案需要相對復雜的網絡，并且需要解決集群中節點之間的狀態管理問題。
• Prometheus專注于實時監控，通常會保留一段時間內的數據，并且我們假設配置是由配置管理工具管理的。從可用性的角度來看，單個Prometheus服務器通常被認為是不可靠的。Prometheus架構認為，實現集群所需的投入以及維護集群節點之間數據一致性的成本要高于數據本身的價值。
• 但是Prometheus并沒有忽視解決容錯問題的必要性，實際上，Prometheus推薦的容錯解決方案是并行運行兩個配置相同的Prometheus服務器，并且這兩個服務器同時處于活動狀態，該配置生成的重復警報交由上游Alertmanager使用其分組（及抑制）功能進行處理。一個推薦的方法是盡可能使上有Alertmanager高度容錯，而不是關注Prometheus服務的容錯能力
• Prometheus環境擴展通常有兩種方式：水平擴展或功能擴展

功能擴展

• 功能擴展使用分片獎監控內容分布到不同的Prometheus服務器上（例如通過地理位置或者邏輯域來進行拆分服務），或者可以通過特定功能，將所有基礎設施加濃發送到一臺服務器，而將所有應用程序監控發送到另一臺服務器
• 如果需要對某些區域或功能進行整體視圖查看，你可以使用聯合功能，將時間序列提取到集中的Prometheus服務器。Grafana支持從多個Prometheus服務器提取數據構建圖形，這可能對你沒有幫助，他允許在可視化級別聯合來自多個服務器的數據，前提是收集的時間序列具有一定的一致性

水平擴展

• 通常在大規模部署中，垂直分片的容器和復雜性將會出現問題，當單個作業包含數千個實例時尤其如此。這種情況下，你可以考慮另外一種方案：水平分片。水平分片使用一系列工作節點（worker），每個節點都抓取一部分目標，然后，我們在工作節點上匯總感興趣的特定時間序列。
• 我們的主節點不僅可以提取聚合指標，還可以為Grafana等工具暴露指標或者作為可視化的默認數據源。如果需要更深入或者進一步擴展，則可以添加分層的主節點或工作節點。一個很好的例子是基于區域的主節點和工作節點，可能是故障域或者像AWS可用區這樣的邏輯區域，將給予區域的主節點視為全局的工作節點，然后想全局的主節點進行報告。
• 需要注意的是，這種擴展方式存在風險和限制，最顯而易見的是，你需要從工作節點中抓取一部分指標。而不是大量貨正在收集的所有指標，這是一個類似金字塔的層級結構，而不是分布式的層級結構。此外，你還需要考慮主節點對工作階段的抓取請求負載。
• 接下來，你會在你的環境中創建復雜的Prometheus服務器層級結構，還需要擔心主節點與工作節點之間的連接，而不僅僅是工作節點與目標之間的連接，這可能會降低解決方案的可靠性。
• 最后，數據的一致性和正確性也可能會降低，工作節點正在根據設定的間隔抓取目標，而你的主節點也要抓取工作節點。這會導致到達主節點的結果出現延遲，并可能導致數據傾斜或警報延遲
• 這兩個問題的后果是，在主節點上集中警報可能不是一個好主意，相反，應該將警報推送到工作節點上，在哪里更有可能識別出問題，或減少識別雞公煲條件和處罰靜吧之間的滯后。
• 配置【省略】

32 mtail的部署與使用

• 是一個非常輕的日志處理器，它能夠運行具有模式匹配邏輯的程序，允許從所述提取指標。他支持多種導出格式，如Prometheus、StatsD、Graphites等

33 blackbox的部署和使用

• 內省對于收集關于系統的數據是非常寶貴的，但是有時我們需要從系統用戶的角度進行度量。在這種情況下，探測是模擬用戶交互的一個很好的選擇。由于探測是在外部進行的，并且不了解系統內部的工作情況，因此將其歸類為黑盒監視
• blackbox_exporters是普邏輯休斯生態系統中所有現有出口最奇特的一家。他的使用模式是巧妙的
• blackbox_exporter服務暴露兩個主要的端點

/metrics：暴露自己的度量

/probe：正是查詢斷電啟用了blockbox探測，以Prometheus呈示格式返回他們的結果

• 除了前面的兩個端點之外，服務還提供了有價值的信息，包括執行探測的日志。
• blackbox導出器支持通過各種各樣的本地協議探測端點，比如TCP、ICMP、DNS、HTTP，以及大多數探測上的TLS。此外，他還支持腳本的機遇文本的協議，如IRC、IMAP或AMTP，通過TCP連接并配置應該發送哪些消息和需要哪些響應；即使是普通的HTTP也可以編寫腳本，但是由于HTTP探測是如此常見的用例，他已經內置了。
• 盡管如此，這個出口商并不能滿足所有blackbox類型的監視需求，對于這些情況，可能需要編寫自己的出口商。例如你不能使用blackbox_exportes來從頭到尾測試一個Kafka主題，所以你可能需要尋找一個能夠生成一條消息給Kafka并將其消費掉的出口商

34 Pushgateway部署和使用

• 盡管普羅米修斯服務器的設計中存在關于推和拉的激烈爭論，以及使用拉的慎重決定，但是在一些合法的情況下，推更合適
• pushgateway：這個導出程序應該只在非常特定的用例中使用。例如，我們應該注意一些常見的陷阱，一個可能的問題是缺乏高可用性，使其成為單點故障。這也會影響可伸縮性，因此容納更多度量/客戶端的唯一方法是垂直伸縮實例（添加更多資源）或分片（為不同的邏輯組擁有不同的Pushgateway實例）。通過使用pushgateway，Prometheus不會直接獲取應用程序實例，這就防止了up指標成為健康狀況的代理。
• 要推送一個度量，您需要使用以下URL路徑定義向Pushgateway端點發送一個HTTP POST請求。

http://<pushgateway_address>: <push_port>/metrics/job/<job_name>/[<label_name1>/<label_value1>] 上述,<job_name>將成為被推送的指標的標簽作業的值，而<label_name>/<label_value>對將成為額外的標簽/值對，請記住，在手動刪除之前，或者在沒有配置持久性的情況下重啟之前，指標都是可用的

• pushgateway使用詳情【省】

35 promtool工具的使用【省】

36 logs和endpoint的校驗

• endpoints：檢查prometheus是否啟動并運行通常非常簡單，因為它遵循了大多數云本地應用程序用于服務健康狀況的慣例：一個端點檢查服務是否健康，另一個端點檢查服務是否準備好開始處理傳入的請求。實際上，Kubernetes還使用了這些約定來評估是否需要重新啟動容器（例如，如果應用程序死鎖并停止響應健康狀況探測），以及是否可以開始向容器發送流量
• logs：通過 --log.level選項來設置日志級別

37 k8s部署prometheus和alertmanager【省】

38 k8s部署nodeExporter【省】

39 監控k8s本身

• 有很多種方法可以監控kubernetes本身，其中包括凱源kubernetes生態系統中的工具，如Heapster和Kube-state-metrics，以及其他商業化和給予SaaS的工具。因為Heapster已經過時了，所以可以采用Kube-state-metrics來進行監控

40 kube-prometheus部署

• prometheus operator：他抽取了kubernetes應用的打包、部署和管理復雜性。操作員綜合應用程序的操作所需的知識（如配置和部署邏輯）Kubernetes定義資源和自定義控制器。除了管理部署（包括Prometheus服務器的pod數量和持久卷）之外，普羅米修斯操作員還將使用ServiceMonitor的概念動態更新配置，該概念針對服務使用與運行容器的標簽相匹配的規則
  

41 k8s中服務的監控

告警通知（郵件、微信、釘釘）

• 非kube-prometheus中的配置

42 matelLB部署

• Layer 2 mode（ARP/NDP）

在這種模式下，服務由集群中的一個節點擁有，他是通過兩層地址實現的，與外部IP匹配的是節點的mac地址，對于外部設備，節點有多個IP地址

• 架構

在兩層的MetalLB運行兩個組件及賬戶：

• 集群級的控制器：這是在集群范圍內處理IP地址分配的控制器
• Speaker daemonset：Speaker必須安裝在集群中的每個節點上，是服務可訪問的協議的組件。他通告兩層地址。
• 針對controller和speaker運行的服務賬戶，還有組件運行所需的權限

43 ingress-controller(nginx)部署【省】

44 kube-controlelr監控控制器

45 kube-scheduler（k8s調度器）監控

46 kube-proxy監控【省】

47 Grafana

Prometheus有一個內置的儀表板和圖形界面。通常適合查看指標和呈現單個圖表。為了給prometheus添加一個功能更全面的可視化界面，可以選擇與開源的grafana進行集成。Grafana接受來自不同數據源的數據，然后提供可視化儀表板。它支持多種數據源，例如Grapgite、ElasticSearch和Prometheus。值得注意的是，Prometheus通常不同于長期數據保留，默認保存15天的時間序列化數據。這意味著Prometheus更專注于監控問題。而不是其他可視化和儀表板系統。針對Prometheus時間序列數據的處理，更加實用的方式是使用表達式瀏覽器、繪制Prometheus UI內置圖形以及構建適當的警報，而不是構建大量儀表板。

可視化操作

五：服務端開發過程中常用到的Linux命令

• top: 查看整個系統資源使用情況
• free -m 查看內存使用情況
• iostat 查看磁盤讀寫活動情況
• netstat 查看網絡連接情況
• df -h 查看磁盤空間使用情況
• du -sh 查看文件大小情況（也可以用ll命令）
• pwd：查看自己所在路徑
• cat：查看文件內容
• more：分段查看文件內容
• tail：從尾部查看文件內容
• head：從頭開始查看文件內容
• ps：查看進程快照信息
• grep：對內容進行過濾篩選
• touch/vi/vim：創建文件
• locate、find：查找文件所在目錄

總結

以上是生活随笔為你收集整理的Prometheus企业级监控——理论入门的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。