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

寫在前面

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

可是，無論怎樣的服務，咱們總思考過這樣的問題：我能不能實時監控/查看服務的運行狀況呢，服務一掛掉我立刻能收到預警呢？這個問題的答案就是：服務監控。

服務監控通常包括兩部分：

1. 服務運行環境的監控。畢竟如今雲環境所佔比例愈來愈多不能單純叫服務器（硬件）監控了。咱們平常遇到的服務掛掉多少是運行環境出問題，宕機啊，網絡，磁盤故障等。 （本篇先聊聊這個）；
2. 服務自己的監控，也就是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預警等，先挖坑。