寫在前面

現每個后端的同學的日常都在跟服務(接口)打交道，維護老的比較大單體應用、按業務拆得相對比較細的新服務、無論企業內部用的，面向用戶的前端的服務。流量大的有流量小的，有重要的有不那么重要的。

但是，不管怎樣的服務，我們總思考過這樣的問題：我能不能實時監控/查看服務的運行情況呢，服務一掛掉我馬上能收到預警呢？這個問題的答案就是：服務監控。

服務監控一般包括兩部分：

服務運行環境的監控。畢竟現在云環境所占比例越來越多不能單純叫服務器（硬件）監控了。我們日常遇到的服務掛掉多少是運行環境出問題，宕機啊，網絡，磁盤故障等。（本篇先聊聊這個）；

服務本身的監控，也就是web應用的監控。下一篇再聊。

Prometheus簡介

現在我們做監控一般是這樣的：

• 先搭個監控服務端

• 各被監控客戶端往服務端push數據(或服務端定時主動去客戶端pull，我們現在就是這種模式)

• 服務端把pull的數據存到時序數據庫中

• 再搭建一個圖形面板Grafana展示收集的監控數據

我們現在用的監控服務端是prometheus

　Prometheus官網地址：https://prometheus.io/

　Prometheus GitHub：https://github.com/prometheus/prometheus/

? ?Grafana Github: https://github.com/grafana/grafana

其實以上搭配幾乎已經成業界標準(個人角度)

prometheus的架構

上一張prometheus架構圖

大家可以花點時間看一下

其中

• Exporter：負責收集目標對象（如Host或Container）的性能數據，并通過HTTP接口供Prometheus Server獲取。每一個客戶端都會提供一個 /metrics 的get接口

• Prometheus Server：負責從客戶端(Exporters)拉取和存儲監控數據，并給用戶通過PromQL查詢。

• 可視化組件 Grafana：獲取Prometheus Server提供的監控數據并通過Web UI的方式展現數據的儀表盤。

• AlertManager：負責根據告警規則和預定義的告警方式發出例如Email、Webhook之類的告警。

prometheus存儲數據結構

我先貼個示例：

# HELP process_virtual_memory_bytes Virtual memory size in bytes. # TYPE process_virtual_memory_bytes gauge process_virtual_memory_bytes 3109478400 # HELP dotnet_total_memory_bytes Total known allocated memory # TYPE dotnet_total_memory_bytes gauge dotnet_total_memory_bytes 4289400 # HELP process_cpu_seconds_total Total user and system CPU time spent in seconds. # TYPE process_cpu_seconds_total counter process_cpu_seconds_total 4.01 # HELP http_requests_in_progress The number of requests currently in progress in the ASP.NET Core pipeline. One series without controller/action label values counts all in-progress requests, with separate series existing for each controller-action pair. # TYPE http_requests_in_progress gauge http_requests_in_progress{method="GET",controller="",action=""} 1 # HELP process_num_threads Total number of threads # TYPE process_num_threads gauge process_num_threads 19

#HELP 是對監控指標(Metric)的注釋說明

#TYPE 監控字段的類型 ，比如process_virtual_memory_bytes 是 gauge類型的監控(具體可看這里)

在形式上，所有的指標(Metric)都通過如下格式標示：

<metric name>{<label name>=<label value>, ...}

指標的名稱(metric name)可以反映被監控樣本的含義（比如，http_request_total - 表示當前系統接收到的HTTP請求總量）。指標名稱只能由ASCII字符、數字、下劃線以及冒號組成并必須符合正則表達式[a-zA-Z_:][a-zA-Z0-9_:]*。

標簽(label)反映了當前樣本的特征維度，通過這些維度Prometheus可以對樣本數據進行過濾，聚合等。標簽的名稱只能由ASCII字符、數字以及下劃線組成并滿足正則表達式[a-zA-Z_][a-zA-Z0-9_]*。

例如：

api_http_requests_total{method="POST", handler="/messages"}

也可以這樣寫（比較少見大家看第一種寫法就好）：

{__name__="api_http_requests_total"，method="POST", handler="/messages"}

Prometheus Server環境搭建

運行環境：

我這里有兩臺測試的虛擬機 192.168.43.215，192.168.43.216

因為這里是測試只用docker啟動一臺在215即可；

先準備配置文件：/etc/prometheus/prometheus.yml

global:scrape_interval: 15sevaluation_interval: 15sexternal_labels:monitor: 'edc-lab-monitor'alerting:alertmanagers:- static_configs:- targets:# - alertmanager:9093rule_files:# - "first.rules"# - "second.rules"scrape_configs:- job_name: 'prometheus_server'static_configs:- targets: ['192.168.43.215:9090']#主機數據收集- job_name: 'node-exporter'static_configs:- targets: ['192.168.43.215:9100','192.168.43.216:9100']#容器數據收集- job_name: 'cAdvisor'static_configs:- targets: ['192.168.43.215:9101','192.168.43.216:9101']

docker：

docker run -d -p 9090:9090 \-v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \--name prometheus \prom/prometheus

跑起來了

http://192.168.43.215:9090/targets

前面四個State=DOWN表示該數據收集節點掛了，這里因為我們還沒運行起來

順便說一下正式環境一般用集群，但是其實prometheus單機也有非常不錯的性能。足以滿足很多吞吐量不是非常夸張的監控需求。

節點數據收集--主機數據收集

來，開始收集主機數據了，用的是：node_exporter

215,216 都給安排上

docker run

docker run -d -p 9100:9100 \ -v "/proc:/host/proc" \ -v "/sys:/host/sys" \ -v "/:/rootfs" \ --name node-exporter \ prom/node-exporter \ --path.procfs /host/proc \ --path.sysfs /host/sys \ --collector.filesystem.ignored-mount-points "^/(sys|proc|dev|host|etc)($|/)"

跑起來了

節點數據收集--docker容器數據收集

docker容器數據的收集用的是：cAdvisor

同樣的，215,216 都給安排上

docker run

docker run \--volume=/:/rootfs:ro \--volume=/var/run:/var/run:rw \--volume=/sys:/sys:ro \--volume=/var/lib/docker/:/var/lib/docker:ro \--volume=/dev/disk/:/dev/disk:ro \--publish=9101:8080 \--detach=true \--name=cadvisor \google/cadvisor:latest

跑起來了

再看看prometheus server

http://192.168.43.215:9090/targets

可以看到之前State=DOWN的紅色節點都綠油油起來了

數據都準備好了，來看看我們美美的儀表盤吧~

集成Grafana儀表盤

安裝，只安裝一個215就好了

依舊是 docker run

docker run -d --name=grafana -p 3000:3000 grafana/grafana

首次登錄賬戶密碼都是：admin 并會要求你重置

重置密碼后進去主頁

初始化數據源

點擊“Add data source”，選擇 Prometheus

注意填對 prometheus server 地址，點擊底部的“保存 & 測試” 按鈕

出現這個表示數據源添加成功

數據源添加好了，準備分別為主機監控和容器監控添加儀表盤；

選個合適的儀表盤

https://grafana.com/grafana/dashboards?search=docker 可以在這里順便搜，選個合適自己的（當然也可以自己構建）

我為node_exporter選擇id=8919,cadvisor選了id=11558，大佬們做好的儀表盤

import儀表盤

點擊這個import

填入8919，后點擊load

加載成功后繼續點import

美滋滋

同樣流程把cadvisor的11558也給安排上：

爽歪歪~~，當然還有更多選擇，這里只是拋磚引玉，大家可以慢慢找個符合自己需求的儀表盤，實在找不到自己繪制也行。

總結

因為硬件、服務環境監控這些主要是運維的業務范疇，我就寫簡單帶過。

下篇講講怎么在Asp.Net Core WebApi中集成。有時間也會多寫寫Alert預警等，先挖坑。

參考

主要還是跟隨龍哥(Edison Zhou)步伐

https://www.cnblogs.com/edisonchou/p/docker_monitor_introduction_part3.html

https://www.cnblogs.com/edisonchou/p/docker_monitor_introduction_part2.html

https://yunlzheng.gitbook.io/prometheus-book/

https://www.cnblogs.com/catcher1994/p/13513184.html

總結

以上是生活随笔為你收集整理的Prometheus(一)：Web服务环境监控的全部內容，希望文章能夠幫你解決所遇到的問題。

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