[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 服务器上面的，你可以换上自己的来试一下。
输入 IP 地址：9090 端口默认会到达这个网址。这个界面可以选择相关项目进行一些查询操作，也可以选择查询的项目的时间范围。
metrics
部署好Node Exporte 后可以看到。
另外，http://10.10.13.15:9100/metrics 也可以看到相同的输出。
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 端口存在以后，在浏览器上访问就好。
如果问 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 网页，已经有新内容出现了。
开启图表
使用 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 的页面，内容偏重组件自身的状态
关掉 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 也可以做到类似的效果，这里就不给出事例了。
今天是总集篇，只是把之前笔记回顾一下。居然有这么多细节，再一次感慨，分享东西出来，对自己提升真的挺大的。
随时随地看视频
