寫在前面

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

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

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

服務執行環境的監控。畢竟現在雲環境所佔比例越來越多不能單純叫伺服器（硬體）監控了。我們日常遇到的服務掛掉多少是執行環境出問題，宕機啊，網路，磁碟故障等。（本篇先聊聊這個）；
服務本身的監控，也就是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: 15s

  evaluation_interval: 15s

  external_labels:

    monitor: 'edc-lab-monitor'

alerting:

  alertmanagers:

  - static_configs:

    - targets:

      # - alertmanager:9093

rule_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服務環境監控

Prometheus(一)：Web服務環境監控

寫在前面

Prometheus簡介

prometheus的架構

prometheus儲存資料結構

Prometheus Server環境搭建

節點資料收集--主機資料收集

節點資料收集--docker容器資料收集

整合Grafana儀表盤

總結

參考

Prometheus(一)：Web服務環境監控

Prometheus(一)：Web服務環境監控

寫在前面

Prometheus簡介

prometheus的架構

prometheus儲存資料結構

Prometheus Server環境搭建

節點資料收集--主機資料收集

節點資料收集--docker容器資料收集

整合Grafana儀表盤

總結

參考

最新文章