0基础入门 docker 部署 各种 Prometheus 案例 - 程序员学点xx 总集篇

[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=` 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 也可以做到类似的效果，这里就不给出事例了。

今天是总集篇，只是把之前笔记回顾一下。居然有这么多细节，再一次感慨，分享东西出来，对自己提升真的挺大的。

这最近不方便？ 那还可以分享我们的文章嘛~~

网站其他文章

深度科普 （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 | Go语言 （go web）网站 | Request | Response| 模板| 数据存储 | 处理 JSON （go docker）冒烟| 限制资源| Python 期末总结 | ELK 任务 | 部署ES | 最小模式 | 集群 | Logstash | 中转 | 输出 | kafka | 消息定制 | 过滤 | geoip | grok | kibana | es head | 使用 | CURD | 指引 Redis 集群 | 脚本 |迁移 | 加固 | 持久化 | 性能 | 缓存思考 | Kafka 集群 | 故障排查 | 命令行 | 术语 | 集群原理 | 近期文章 寂寞的时候, Siri在帮我数羊 - 100期纪念

本文由博客一文多发平台 OpenWrite 发布！

发布在平台的文章, 和原文存在格式差异, 阅读不便请见谅

最新内容欢迎关注公众号: