[TOC]

大家好， 學點xx 系列也推出一段時間了。雖然 yann 能力有限，但還是收到了很多鼓勵與贊賞。對這個系列 yann 還是很喜歡的，特別是 Prometheus 篇，在期間經歷公眾號 100 篇文章紀念，和一次較大的改版。真的是很難忘的一個篇章，下面帶領大家回顧下。

第 1 部分 出發

部署

在之前的分享中 yann 說需要準備個配置文件，然后使用 docker 就可以把 Prometheus 啟動起來了，其實這是不完整的。起來的只是服務端，他還需要客戶端，或者說還需要幫它提供 metrics 的各種模塊。

讓我們依次來完成這個事情，首先完成一個 prometheus 的yml配置文件。這里, yann 從官網拿了一個實例的配置文件，雖然內容很多，但沒有做任何修改。同樣,你也可以直接用這個文件讓它跑起來，后面我們會有個篇章來分析配置文件的詳細內容。

prometheus.yml

global:scrape_interval:     15s # By default, scrape targets every 15 seconds. # Attach these labels to any time series or alerts when communicating with # external systems (federation, remote storage, Alertmanager).external_labels:  monitor: 'codelab-monitor'# A scrape configuration containing exactly one endpoint to scrape:# Here it's Prometheus itself.scrape_configs: # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.- job_name: 'prometheus'   # Override the global default and scrape targets from this job every 5 seconds.  scrape_interval: 5s  static_configs:    - targets: ['localhost:9090']

啟動服務端

準備好配置文件以后,你可以用 docker 命令，掛載上這個配置文件，把 Prometheus 啟動起來。

請注意一下配置文件的位置，yann 寫的是自己服務器的文件路徑，你需要改成自己的。

如果沒有報錯的話，服務端就起起來了，請用端口查看命令確認一下相應的端口有沒有起來。注意，不要使用 docker ps 來查看。原因 yann 后面會說。

docker run -d \   --net=host \   -v /home/data/prom/prometheus.yml:/etc/prometheus/prometheus.yml \  prom/prometheus

啟動客戶端

用同樣的方法把客戶端 node-exporter 也啟動起來，確認9090和9100端口是存在的。

docker run -d \ --net="host" \ --pid="host" \ -v "/:/host:ro,rslave" \quay.io/prometheus/node-exporter \ --path.rootfs=/host

以上兩組命令都來自官網的文檔。

初始界面

如果一切正常的話，我們可以來查看到下面的效果，截圖的IP地址是yann 服務器上面的，你可以換上自己的來試一下。

網址 http://10.10.13.15:9090/graph

輸入 IP 地址：9090 端口默認會到達這個網址。這個界面可以選擇相關項目進行一些查詢操作，也可以選擇查詢的項目的時間范圍。

metrics

部署好Node Exporte 后可以看到。

另外，http://10.10.13.15:9100/metrics 也可以看到相同的輸出。

targets界面

網址 http://10.10.13.15:9090/targets


這個頁面可以看到現在監控的目標。如圖，yann 現在監控了兩個項目：一個是自身的 9090，一個是客戶端 9100，狀態都是正常的。

避坑

在這個配置中 yann 遇到了兩個坑，現在也給大家分享出來，避免其他人也陷入進來。

端口消失

第一個坑準確來說也不算是坑，是 docker 的一個參數，只不過 yann 不是經常用。

--net=host

當配置了這個參數時, 表示直接打通容器網絡與本地網絡。相對的 docker ps 上看不到容器的端口，一定要用端口查看命令看才能看得到。

描述可能比較抽象，yann 放了一個截圖。可以看到查看狀態的時候完全看不到容器的端口。


端口沖突

另外一個坑和上一條問題相關，因為在 docker ps 命令下沒有過濾到端口。所以 yann 認為并沒有端口沖突。實際上它和 yann 前些天部署的 elasticsearch-head 是沖突的，大家都是9100。如果有近期內搞過 ES 的同學要特別注意這一點。

433cab2b4724       mobz/elasticsearch-head:5                             "/bin/sh -c 'grunt s…"   11 days ago         Created                     9100/tcp  

當時 elasticsearch-head 因故又使用了安裝包部署，這次的容器用了 --net=host 的網絡設定，結果就在宿主機里杠上了。

第 2 部分 圖表

圖表

grafana 的部署相對簡單

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

一行命令搞定， 確認3000 端口存在以后，在瀏覽器上訪問就好。

例如：http://10.10.13.15:3000/

如果問 grafana 難不難？大多數人都會感覺挺簡單的：「不就是個可視化工具么，數據都有了，還怕表出不來？」。

其實還真有點難度， 主要原因就是找不到設置的地方；外加語言障礙（目前 yann 手里還沒有中文版，有的筒子千萬給我留言）。我們來一步一步看。

數據源

相比起來， 數據源還是比較好設置的， 如果是新部署向導程序還存在的話， 直接會引導過去。


如果是中途接手他人的項目的狀況，也不用擔心。yann 保證只拿到帳號密碼，沒人指導的情況下， 你也是可以把數據源配置出來的。


不過要注意下 Whitelisted Cookies ， 這個框以前版本是沒有的，yann 先填了個 none 跳過。

儀表盤

接下來是 dashboard，改配置儀表盤了。


很直觀，然后


（此處感謝小熊）

「是選 Visualization (可視化) 對吧， 我已經看到圖表的標志了。接著選擇 Graph ， 圖表我來了」。

^^ 是不是有點無從下手。

各位不要笑， yann 最早也是坑在這里的。

開啟圖表

娛樂節目結束， 現在開始設置一個圖表出來。

其實正確設置的位置是在上邊一個按鈕那里。

Metrics 欄目隨便選擇一個就可以了。


結果演示


還有另外兩個按鈕，是一些設置和告警， 自己看一下就好了。

最后， 設置需要保存一下，保存按鈕在這里。


補充一下。設置完成后， 后期想調整 dashboard 也是在這里。找不到設置按鈕，順著左上角 田字白方塊 點來點去的大有人在，笑。

第 3 部分 數據庫

冒煙部署

閑話就此打住，先來操作。昨天的時候，我們曾經在 grafana 上弄出圖表了。那么今天的任務。是產生很多的圖表來應付mysql的日常需要。

怎么樣產生大量的圖表呢？一個一個設定當然是很累的，于是我們就想到了模板，先去官方的網站上先下套模板回來。


就你了。

導入模板，配置數據源。很順利的圖表就出來了，唉，好像少點什么，先不管他。

？為什么我的圖表一直都是異常狀態呢？設置數據源的時候，數據庫連接測試也通過了，難道是權限不足讓我們看看日志。


果然是權限不足，讓我們加權限，還不行？我再加，我用root訪問總可以了吧，什么，居然還不行。


撞墻之后開始反思。日志給出的信息比較有限，沒有權限訪問，不一定是賬號沒權限，先看看有沒有這個庫，果然沒有？再分析一下搜索語句，終于發現了。原來這個模板是比較特殊的一個，它需要導入一個數據庫進去。嘗試操作了一下。終于不報異常了。

# 下載 https://github.com/john1337/my2Collectormysql --user=root -p < my2.sql# 賦權  CREATE USER 'grafanaReader' IDENTIFIED BY 'Abcd1234';  GRANT SELECT ON my2.* TO 'grafanaReader'@'172.17.%.%' IDENTIFIED BY 'Abcd1234';


這是我很早以前部署 prometheus 時候犯的一個錯誤。當時也沒有那么意識到 exporter 的作用。找到一個包，下載下來就開始使用。

這個模板雖然和平常的不太一樣，但并不是完全沒有用處。如果有些環境，不是那么方便安裝插件，反而容許導入表的話，是可以使用這種方法的。

正常部署

現在，我們來使用比較常規一些的方法部署 Mysql的圖表。

更新用戶權限：

GRANT SELECT ON performance_schema.* TO 'yann'@'%' IDENTIFIED BY 'Abcd1234';

mysqld-exporter 部署：

# docker network create my-mysql-networkdocker run -d \ --net="host" \-e DATA_SOURCE_NAME="yann:Abcd1234@(10.10.13.15:3306)/" \prom/mysqld-exporter

注意：

mysql 數據庫一般有單獨的容器網絡。yann 之前選擇了與宿主機互通， 現在也不方便改回來了。自己部署的話， 注意注釋掉的語句，當然docker 命令也需要調整。

prometheus.yml 也調整一下， 這里先給出調整內容。整體配置后面會說明。

- job_name: linux_mysql  static_configs:    - targets: ['10.10.13.15:9104']      labels:        instance: yanns_mysql

添加了一個 job，修改后重新部署 prometheus 容器。

查看：

再次訪問 targets 網頁，已經有新內容出現了。

http://10.10.13.15:9090/targets

開啟圖表

使用 mysqld-exporter 之后， 開啟的數據源就是 prometheus 了。這一點請切記，很多同學因為是 Mysql 的監控， 就直接去添加了 Mysql 的數據源，然后奇怪為什么一直沒有輸出。

另外，圖表的模板，也使用導入的方式，文件在這里：

git clone https://github.com/percona/grafana-dashboards.git  # 倉庫                  ls grafana-dashboards/dashboards

PMM

最后， 再奉送一個我司在正使用的 PMM 的部署說明。

Percona監控和管理（PMM）是一個用于管理和監控MySQL和MongoDB性能的開源平臺，其他詳細介紹請自行百度。

部署：

docker run -d \  -p 8089:80 \  -v pmm-data \  --name pmm-server \  --restart always \  percona/pmm-server

除了監控平臺以外， 數據庫服務器上還要安裝 Client 并配置。當然，這不是今天的主題所以略過。

第 4 部分 服務器

監控

系統的 Agent 其實之前就部署好了。前兩天 Prometheus 配置時候 啟用的兩個端口 9090 和 9100 ，其中9100 就是系統 Agent的端口，另外 提一下 9104 是Mysql的。

這里簡單介紹一下配置文件：

# 全局global: # 默認抓取周期scrape_interval: 5s  # 規則的默認周期，比如持續30秒則匹配evaluation_interval: 30s # 規則文件，先不涉及# rule_files:# 抓取配置scrape_configs:   - job_name: "node"  static_configs:   - targets:       - "localhost:9100"# Alertmanager 告警相關配置alerting:alertmanagers: - scheme: https  static_configs:   - targets:     - "localhost:9093"

這是一個比較精簡的配置文件，可以參考一下。另外注意，配置文件是 yaml 格式，需要注意對齊。

我們添加一下操作系統的監控配置。

- job_name: linux01  static_configs:    - targets: ['10.10.13.15:9100']      labels:        instance: yanns_linux

job 和 instance 的區別是，一個job 可以包含多個不同 IP 不同端口下的進程。

添加完成


查詢

現在我們來演示一些數據的查詢 ：

文件系統可用字節數：

node_filesystem_avail_bytes

效果如圖：


顯示了各個分區的可能空間， 當然純數字是比較難以閱讀的， 可以加上一些處理

常用的一些性能指標：

下面是一些常用的查詢語句， 大家可以自己試一下：

# cpu100 - (avg by (instance) (irate(node_cpu_seconds_total{job="linux01",mode="idle"}[5m])) * 100)# memnode_memory_MemFree_bytes{job='linux01'}# diskrate(node_disk_read_time_seconds_total{job='linux01', device='sda' }[5m]) * 512# networkrate(node_network_receive_bytes_total{job='linux', device!='lo'}[5m])

注意：exporter 對應字段的名字，根據版本不同會有所改變，如果查詢沒有結果，請自行調整。

告警

告警的配置略為繁瑣， 我們從頭開始梳理。

更新prometheus.yml

# 增加alerting:alertmanagers:- static_configs:  - targets:      - 10.10.13.15:9093rule_files:- '/etc/prometheus/alert.rules'

映射 alert.rules 文件

docker run -d --net=host \-v /home/data/prom/prometheus.yml:/etc/prometheus/prometheus.yml \-v /home/data/prom/alert.rules:/etc/prometheus/alert.rules \--name prometheus-server6 prom/prometheus

alert.rules 的內容

groups:- name: examplerules: # Alert for any instance that is unreachable for >5 minutes.- alert: InstanceDown  expr: up == 0  for: 5m  labels:    severity: page  annotations:    summary: "Instance {{ $labels.instance }} down"    description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.groups:

Alertmanager配置文件

global:  resolve_timeout: 5mroute:  receiver: 'default-receiver'  group_wait: 30s  group_interval: 1m  repeat_interval: 1m  group_by: ['alertname']  routes:  - match:      severity: critical    receiver: email-mereceivers:- name: email-meemail_configs:- to: GMAIL_ACCOUNT  from: GMAIL_ACCOUNT  smarthost: smtp.gmail.com:587  html: '{{ template "email.default.html" . }}'  auth_username: "GMAIL_ACCOUNT"  auth_identity: "GMAIL_ACCOUNT"  auth_password: "GMAIL_AUTH_TOKEN"   - name: 'default-receiver'    webhook_configs:    - url: http://webhook-dingtalk/dingtalk/send/      send_resolved: true

部署Alertmanager

docker run -d  --net="host" -v /home/data/prom/config.yml:/etc/alertmanager/config.yml  --name alertmanager prom/alertmanager

簡單說明一下， alert.rules 負責定義 哪種情況觸發報警。而 Alertmanager 定義檢查報警的情況以及告警媒介，例如郵件，釘釘等。

以下是一些配置截圖展示：

更新配置后， 規則已經顯示出來了


alertmanager 的頁面，內容偏重組件自身的狀態

訪問 http://10.10.13.15:9093/#/alerts


關掉 mysqld_exporter 后產生的告警

第 5 部分 容器

部署

監控 Docker 需要 Prometheus、cAdvisor 和 Grafana。另外兩個之前已經部署過， 我們來看一下 cAdvisor。

cAdvisor 可以對節點機器上的資源及容器進行實時監控和性能數據采集，包括CPU使用情況、內存使用情況、網絡吞吐量及文件系統使用情況。

部署

這個軟件屬于開箱即用類型， 部署方便，以下為官方示例。

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

已經部署完畢


配置

Prometheus 的配置文件也需要更新一下，給 prometheus.yml 追加 job：

 - job_name: cadvisor  static_configs:     - targets: ['10.10.13.15:8081']      labels:        instance: yanns_docker

啟動

再次啟動 Prometheus ：

docker run -d --net=host \-v /home/data/prom/prometheus.yml:/etc/prometheus/prometheus.yml \-v /home/data/prom/alert.rules:/etc/prometheus/alert.rules \--name prometheus-server7 prom/prometheus

效果

添加完成，cadvisor 的管理界面如下，一只可愛的貓頭鷹。


Docker

可愛的貓頭鷹召喚出來了，讓我們再來配置一下相關的圖表。第一步還是添加數據源，這個操作我們應該已經輕車熟路。

數據源

提供一張圖片供大家參考，具體操作就省略了。


導入模版

數據源配置置好后，再來導入模板，在 Grafana 中有一個非常簡單的方式，就是把模板的序號輸進去就可以進行導入。如圖，本次需要用到的模板是193號。


效果

最后就是監控效果了。如圖，配置好模板就會出現本機所有 Docker 的相關信息，請大家自行嘗試。


Etcd

我們先來介紹下這個軟件 ,Etcd 是CoreOS開發的一個分布式一致性鍵值存儲系統。作為 Kubernetes 的默認數據庫為人熟知。

因為 yann 的環境以前部署過k8s，所以已經有etcd組件了，這次我們不從頭開始部署 Etcd ，只是簡單演示一下 Etcd 的使用。

命令

Etcd 比較特殊的部分就是經常需要帶著版本標識和證書來執行命令。否則的話會報錯或有相當的功能限制。詳情請看下面的命令舉例。

   ETCDCTL_API=3 /opt/k8s/bin/etcdctl \   --endpoints=https://10.10.13.15:2379 \   --cacert=/etc/kubernetes/cert/ca.pem \   --cert=/etc/etcd/cert/etcd.pem \   --key=/etc/etcd/cert/etcd-key.pem endpoint health

添加 Job

在了解基本的情況以后，讓我們來監控etcd。首先，在 Prometheus 的配置文件上新加一個 job 任務。注意，這次與往常不同，Ca 證書和 Etcd 自身的證書也寫入了配置文件之中。

prometheus.yml 追加部分：

- job_name: 'etcd'  scheme: 'https'  tls_config:    cert_file: '/etc/ssl/etcd.pem'    key_file: '/etc/ssl/etcd-key.pem'    ca_file: '/etc/ssl/ca.pem'  static_configs:  - targets: ['10.10.13.15:2379']

啟動應用

既然配置中有相關內容，自然也需要提供文件。我們重新撰寫了啟動命令，把三個證書文件掛載到了容器里面，如下：

  docker run -d --net=host \-v /home/data/prom/prometheus.yml:/etc/prometheus/prometheus.yml \-v /home/data/prom/alert.rules:/etc/prometheus/alert.rules \-v /etc/etcd/cert/etcd.pem:/etc/ssl/etcd.pem \-v /etc/etcd/cert/etcd-key.pem:/etc/ssl/etcd-key.pem \-v /etc/kubernetes/cert/ca.pem:/etc/ssl/ca.pem \--name prometheus-server8 prom/prometheus

Docker 的啟動命令是越來越長了。把證書掛到容器里面，確實不是一個很合理的操作。不過我們現在僅僅作為演示，并不作為實際的解決方案。同時，prometheus 有對應開發 Kubernetes 專用的版本 kube-prometheus。里面有完善的相關解決方案，后面有機會可以給大家分享。

掛載好文件后，啟動 Docker，同時打開普羅米修斯的控制頁面，就看到了新的 Target 掛載成功了。


之后同樣是導入模板，這次的模板號是3070，下面兩幅截圖是Etcd監控的截圖，供大家參考。



第 6 部分 延伸

權限

在前面的介紹中， yann 有意回避了一些復雜的問題。比如說每次下載的模板不可能完美匹配，我們需要一些自己定制的圖表；或者模板太多了，我們需要精減一些項目；要么干脆需要特定的圖表只給特定的人看。林林總總， 現實中都會遇到的， 今天來梳理一下。

組織

Orgs 是一個比較神奇的功能。不同組織之間， 數據源獨立， 儀表版也獨立，甚至彼此之間不能共享。比較推薦的方法是建立多個組織，按部門或業務線來劃分，然后組合起來賦權給用戶。

純語言描述比較抽象， 我們來演示一下，這是該功能的位置。


建立一個組織，yann fans 俱樂部 （害羞）


檢查數據源和儀表板


不同的組織，數據源也不一樣。如圖，Grafana 中之前設定好的數據源全部消失了，同樣儀表版也沒了，說明組織是隔離性比較強的。這個分隔方式有點類似 Docker 。

api

既然提到組織，我們再了解一下相關的賦權功能 API。這個功能有點像阿里云上的 AccessKey，持 Key 的人可以做權限內的操作，比如說瀏覽、修改甚至管理整個 Ggrafana。這個API的具體用法，請看下面截圖演示。

演示一下

生成的 API key

除了 key 之外， 截圖里面，靠下部分舉例的就是操作方式，下面還會有相關討論。

模板變量

除了 Orgs “組織”，Grafana 還有另一個很特色的功能：模板變量。

說到這里，讓我們來思考一個問題：一組應用或多臺服務器之間，監控項目的區別到底在哪里呢？

答案是 IP、端口、應用的名稱或標簽不一樣。根據這個特點，我們可以把這些不一樣的部分做成變量，然后就可以使用一套模板對應一組同類型應用及服務器的監控。

變量舉例：


變量的制作方法如下：需要提供變量名稱、獲取類型、標簽及是是否隱藏。然后在查詢框 Query Options ，選擇數據源并填寫查詢語句。通過查詢的方式從數據源里取出一系列值，有必要的話，還可以用正則表達式來進一步獲得準確的輸出。

這樣做出來的變量，就可以在儀表板上使用了。需要注意的是 Grafana 是一個前端項目，變量操作需要建立在已有數據的基礎上，如果數據源 Prometheus 里面沒有相關數據相匹配的記錄，生成再多變量也是無可奈何的。

文件格式

最后，我們來了解一下 Json 的數據結構。如圖所示，圖表及儀表板都可以導出為 Json 格式。也就是說我們之前玩的不亦樂乎的導入功能，其實就是廠家或第三方做好并導出來的儀表板的 Json格式。


對比導出的 Json 文件，就會發現大部分內容都是相同的，替換 認證字段、data和儀表板名稱就可以生成對應組織的儀表板。

基于這個特點，我同事有了一個想法：“說我們去寫一些前端頁面，然后讓其他部門同事使用不同 API 發起 POST 的請求，然后再把拼接好的命令及 Json 文本打進去，是否就可以做成自定義提交，按個人需求自助生成圖表呢？這樣運維同事就解放了。

然后把這個需求和前端同事一說，人家說「你 Grafana 就是個前端項目，你用另寫一套前端去修改一個前端的提交文件，不覺得很二么? 」 ,無言以對。

以上為自產小段子，不必當真。這個話題涉及到了HTTP網頁的 POST 提交過程，有興趣的同學可以嘗試一下。不一定要寫代碼，使用一些測試工具，比如 POSTMAN 也可以做到類似的效果，這里就不給出事例了。

今天是總集篇，只是把之前筆記回顧一下。居然有這么多細節，再一次感慨，分享東西出來，對自己提升真的挺大的。

<center>這最近不方便？</center>
<center>那還可以分享我們的文章嘛~~</center>

<center><font color=Red face="黑體"><B>網站其他文章</B></font></center>

<font color=OrangeRed face="黑體">深度科普</font> （CNCF→） 畢業項目 | 生態 | Ansible | Chef | Puppet | VMware | OpenStack | registry | Harbor| Docker | Containerd | RKT | ROOK | Calico | Flannel | Open vSwitch | Kubernetes | Zookeeper | Consul | Etcd | GRPC | thrift | MySQL | Spark | Storm | RocketMQ | kafka| RabbitMQ | Helm | Docker Composer | Packer | Jenkins | Bamboo | （Prometheus→） 構建 | DBA | 系統 | Grafana | Zabbix | Fluentd | ElasticSearch | Logstash | Jaeger | <font color=OrangeRed face="黑體">Go語言</font> （go web）網站 | Request | Response| 模板| 數據存儲 | 處理 JSON （go docker）冒煙| 限制資源| <font color=OrangeRed face="黑體">Python</font> 期末總結 | <font color=OrangeRed face="黑體">ELK</font> 任務 | 部署ES | 最小模式 | 集群 | Logstash | 中轉 | 輸出 | kafka | 消息定制 | 過濾 | geoip | grok | kibana | es head | 使用 | CURD | 指引 <font color=OrangeRed face="黑體">Redis</font> 集群 | 腳本 |遷移 | 加固 | 持久化 | 性能 | 緩存思考 | <font color=OrangeRed face="黑體">Kafka</font> 集群 | 故障排查 | 命令行 | 術語 | 集群原理 | <font color=OrangeRed face="黑體">近期文章</font> 寂寞的時候, Siri在幫我數羊 - 100期紀念

本文由博客一文多發平臺 OpenWrite 發布！
發布在平臺的文章, 和原文存在格式差異, 閱讀不便請見諒
最新內容歡迎關注公眾號:

https://upload-images.jianshu.io/upload_images/20093046-6aedbee22292c842.jpeg