prometheus--一些知识
prometheus--一些知識
- 1、安裝
- 一些基本知識
- counter
- Gauge
- Histogram
- summy
- promQL常用的一些函數
- prometheus配置文件
- 使用pushgateway模塊及自定義監控
1、安裝
-
prometheus安裝較為簡單，直接官網下載tar包，解壓之后直接運行默認端口9090，添加path環境變量PATH=$PATH:/prometheus/prometheus-2.29.1.linux-amd64
直接啟動prometheus start或者使用程序入口啟動bash ./prometheus --config.file=prometheus.yml
由于prometheus前端啟動，因此我們可以使用nohup與&一起讓其后臺運行 -
export存在各種各樣的，目前常用的為node-export和db-export，安裝方式也是非常簡單，和prometheus安裝方式一樣，端口默認9100，后臺運行，安裝之后可以檢查一下是否運行，如 bash curl localhost:9100/metrics 來驗證
-
grafana安裝更簡單了，可以使用rpm包，wget rpm地址，在yum install rpm包
一些基本知識
prometheus對于采集過來對數據統一稱之為metrics
metrics是數據形式有：
Counter（計數器）、Gauge（儀表盤）、Histogram（直方圖）、Summary（摘要）
counter
只增不減/reset歸零，記錄某些事件發生次數，系統運行時間，用戶訪問量，記錄請求次數、任務完成數、錯誤發生次數,該指標的工作方式和計數器一樣，只增不減（除非系統發生了重置）。通常來講許多指標counter本身并沒有什么意義，有意義的是counter隨時間的變化率如采用rate函數能計算出每秒增長，通常配合各種函數使用
Gauge
瞬時狀態，可增可減，側重于反應系統的當前狀態，比如cpu，磁盤，內存容量（這類數值采集多少就是多少，不會一直一個狀態），客戶端計算主要用于表示一段時間范圍內對數據進行采樣（通常是請求持續時間或響應大小），并能夠對其指定區間以及總數進行統計
Histogram
Histogram統計數據分布情況，如中間值，最大最小值等，比較常用如http_response_time http響應時間等，或者求某些平均響應時間（有些響應快，有些慢請求混合），可以使用H，按照某段時間截取數據
summy
略
promQL常用的一些函數
sum(increase(node_cpu)[1m]) by(instance) 主機1分鐘cpu的使用率 node_cpu 是key name 還想篩選，可以使用label{mode='idel'}rate（）和increase（）都是計算某段增長量，不同的是rate比較精細，increase比較粗略
rate是某一段時間內每秒的增量 ,時間/60s
increase是某一段時間的增量
sum（）把所有東西加和，但是這樣太籠統了，比如cpu使用，我們不關心每一核的具體使用量，但是我們把所有機器聚合起來顯然也不是我們要的結果，可以使用by，by是按照sum加和的指標，按照某種方式進行拆分，例子是按照主機實例進行拆分，與之相反的without移除指定標簽
count（）類似于求和。predict- linear（）可以預測未來變化
prometheus配置文件
prometheus的歷史數據存放在/data/prometheus/data里面，如果斷電可以從里面恢復數據（命名是一串較長的字符串）
配置文件指標說明
- global: 全局配置（如果有內部單獨設定，會覆蓋這個參數）
- alerting: 告警插件定義。這里會設定alertmanager這個報警插件。
- rule_files: 告警規則。
按照設定參數進行掃描加載，用于自定義報警規則，其報警媒介和route路由由alertmanager插件實現。 - scrape_configs:采集配置。配置數據源，包含分組job_name以及具體target。又分為靜態配置和服務發現
-
job_name: 任務目標名，可以理解成分組，每個分組包含具體的target組員。
-
scrape_interval: 5s #這里如果單獨設定的話，會覆蓋global設定的參數，拉取時間間隔為5s
-
metrics_path #
監控項訪問的url路徑,https://prometheus.21yunwei.com/metrics【通過前端web做了反向代理到后端】 -
targets: Endpoint # 監控目標訪問地址，[‘service1:9091’]需要在/etc/hosts做域名解析或者local dns server
說明：上述為靜態規則，沒有設置自動發現。這種情況下增加主機需要自行修改規則，通過supervisor reload 對應任務，也是缺點：每次靜態規則添加都要重啟prometheus服務，不利于運維自動化。
prometheus支持服務發現（也是運維最佳實踐經常采用的）：
文件服務發現
基于文件的服務發現方式不需要依賴其他平臺與第三方服務，用戶只需將 要新的target信息以yaml或json文件格式添加到target文件中 ，prometheus會定期從指定文件中讀取target信息并更新
好處：
（1）不需要一個一個的手工去添加到主配置文件，只需要提交到要加載目錄里邊的json或yaml文件就可以了；
（2）方便維護，且不需要每次都重啟prometheus服務端。
例子：
后期再有job_name或者target改動的時候，直接修改規則文件即可，不再需要重啟prometheus服務守護進程進行重載。
如果要使用pushgateway模塊提取監控數據，也是將信息配置在scrape_configs
使用pushgateway模塊及自定義監控
pushgateway可以安裝在任何機器上，使用這個模塊我們可以自定義監控數據，拿到我們想要監控的數據，但是pushgateway的缺點是，所有機器都會先pushgateway模塊push數據（export定義一個腳本，在將數據推送過去curl --data-binary），容易造成機器負擔過大，一旦宕機，數據將無法推送
# 修改prometheus.yml 加入如下片段 - job_name: "custom-memory-pushgateway"#honor_labels: truestatic_configs:- targets: ["192.168.100.11:9091"]一個自定義腳本
vim push_memory.sh #!/bin/bash # desc push memory info total_memory=$(free |awk '/Mem/{print $2}') used_memory=$(free |awk '/Mem/{print $3}')job_name="custom_memory" instance_name="192.168.100.12"cat <<EOF | curl --data-binary @- http://192.168.100.11:9091/metrics/job/$job_name/instance/$instance_name #TYPE custom_memory_total gauge custom_memory_total $total_memory #TYPE custom_memory_used gauge custom_memory_used $used_memory EOF我們監控數據的腳步需要反復執行，可以使用定時任務，但是定時任務最短一分鐘，如果我們要求小于一分鐘，可以使用sleep 20…
推送URL ：pushgateway默認采用9091端口，路徑： /metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>}
推送數據：http://192.168.100.11:9091/metrics/job/$ job_name/instance/$instance_name，意思是將數據推送給pushgateway的url，job/$job_name第一個標簽，推送到哪一個prometheus.yaml里面定義的job，$job_name/instance第二個標簽，推送后顯示的機器名叫什么，總而言之
總結
以上是生活随笔為你收集整理的prometheus--一些知识的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Drools（8）：WorkBench使
- 下一篇： 域渗透-委派攻击