Prometheus学习记录【一】
1 写在前面
1.1 缘起何处？
从去年的今天来到新公司开始，便在寻找适合大集群的监控手段，原先有前辈搭建的zabbix做部分服务器的监控，但是能满足的需求非常之少，而且自己本身只踏入职场一年多，各方面技能都很欠缺，系统监控方面的知识更是浅陋，想着无论用哪种监控工具都是从头开始学，不如学一个前沿的，于是选择了Prometheus。
在公司给的高压下，也算是整出了一些东西，做出了点成绩满足了运维人员的日常需求，但是打心底觉得学的东西过于繁杂，没有形成体系，今天正好来到新公司整整一周年，计划着今天开始好好系统学习下Prometheus吧，争取将现有的监控体系继续完善。
文笔不行，全当过程的记录了，尽量做到不零碎吧。
整个学习过程基于以下渠道和资料：
- 官方：Prometheus官方文档
- 书本：Prometheus监控实战（作者：詹姆斯·特恩布尔）
- 书本：Prometheus云原生监控：运维与开发实战（作者：朱政科）
1.2 现有技能
学习前，先简单思考下我会什么，围绕着监控来说应该有这些：
- Prometheus的联邦架构和部署；
- Prometheus的基本配置，标签注入；
- 基本的一些PromQL，太复杂就写不好；
- 使用Python自定义exporter等待Prometheus采集；
- 通过Grafana进行大屏展示，目前会使用mysql数据源、prometheus数据源等，自己也进行了部分Grafana的汉化；
- 通过AlertManager进行告警的配置，并通过python脚本对告警结果做二次处理，传给内网的专用接口，进行短信告警（webhook）；
- 其他零碎的一些东西，就不列了。
1.3 学习目标
这次的学习+记录，还是要有相应的目标才行，先定几个，过程中随着工作的需要可能继续增加吧：
- 深入学习一下Prometheus的相关知识，尤其是PromQL的使用；
- 结合现有的技能，对公司的监控体系做一部分优化，完善现有的监控系统；
- 对整个数据、任务的生命周期做梳理，至少形成一个故障判断、处理的基本流程。
废话说完，开始干了！
2 正文
2.1 从了解监控开始
刚开始做运维的时候，只是把这个当成一个解决问题的工作而已，随着接触的集群从6台增加到50台，再从50台增加到200台，再到目前已经面临着最大集群2000台的多集群环境时，如果还只是以解决问题为追求做运维工作就已经力不从心了。
总的来说，做运维一定要从一个解决问题的人转变为一个发现问题，然后避免问题的，当然再高端点就是能够让问题处理也自动化了，可惜我现在还不会，等以后自己的能力足够了，在尝试这部分内容。
2.1.1 监控的目的
就我学到的和用到的监控来说，监控的目的大概包含如下几点：
- 使用部分指标进行趋势分析，比如资源测算，监控提供的数据可以为未来一年的平台资源测算提供数据支撑，从价值来说就是可以向甲方爸爸申请更多资源；
- 使用部分指标进行对照分析，比如比对DataX的近几日数据同步量，分析是否有省份数据量出现异常或者察觉别的问题；
- 依赖监控的指标进行告警规则制定，从而对隐患进行告警，这个不用多说，目前我也在用Alertmanger做一些简单告警；
- 故障分析和原因定位，这个也是监控的基本目的，当出现故障时，有足够的指标支撑可以定位到具体的问题时间点；
- 基于监控数据的可视化，这部分可能炫耀成分大于实用成分，毕竟领导就喜欢看大屏啊。
2.1.2 MDD理念
MDD(Metrics-Driven Development)，指标驱动开发，借用网上对它的定义就是“通过实时指标来驱动快速、精确和细粒度的软件迭代”，就是要在设计初期就将Metrics设计包括起来，我对他笼统的理解就是做一个东西前，就考虑好这个东西的整个生命周期中有哪些东西需要关注，并作为指标暴露出去，这些暴露出来的指标之后可以方便开发人员的bug排查，也可以方便建转运以后运维人员对问题的定位。
之前还没有了解MDD理念，当时接触到公司的现网环境，真的是被监控的事情搞疯了，完全是烂摊子，很多应用根本没有指标项能够衡量其健康状态，运维也没法做二次改造设置锚点，而且上线流程非常不完善，项目上又天天急着满足客户，新上线的应用暴露各种问题都甩锅给运维人员，反正项目经理只管客户开心，最后就是运维出力不讨好。以致于后面了解到MDD简直不要太同意。
MDD理念的监控分层有三种：
- Infrastructure/System Metrics：一些基础监控项，在我们的系统中大概就是磁盘容量、CPU利用率、内存使用率等；
- Service/Application Metrics：中间件，组件的监控项，在我们的系统中包含HDFS、YARN组件的健康度等；
- Business Metrics：偏运营和业务的数据，关系到一些数据质量，在我们系统中指用户数、定位数据等。
2.1.3 三大监控方法论
太多的书本和资料介绍了，我也是看了好多遍，就简单概括下就好，感兴趣的话可以直接百度或者谷歌搜一下：
- Google的四大黄金指标——主要针对应用程序和用户部分，包含延迟、流量、错误、饱和度，比如公司的对外官网，去关注用户访问的网络延迟、Web服务器和数据库服务器处理的相关请求量、失败的请求数量、以及各项系统指标的使用饱和度是否能满足当下的业务量；
- Netflix的USE方法——适用于分析系统性能的方法论，包含Utilization（使用率）、Saturation（饱和度）、Error（错误），比如关注集群内服务器的各项资源使用率，各项资源的饱和度以及一些系统级别的错误，比如网络丢包，内核OOM等；
-
Weave Cloud的RED方法——基于四大黄金指标结合Prometheus及K8s容器时间得出的方法论，使用云原生应用，因为还没接触云，就不多言了。
引用朱政科老师在书中的一句话概括就是：
一般来说，上述三大监控理论的最佳实践是：在遵循Google四大黄金指标的前提下，对于在线系统，结合RED方法和缓存命中率方式进行监测；对于离线系统或者主机监控，以USE方法为主进行监测；对于批处理系统，可以采用类似Pushgateway的形式进行监控。
2.1.4 其他杂七杂八的知识点
还有一些我不知道怎么分类但是感觉做监控有必要了解一下的东西，这里列一下：
- 黑盒监控和白盒监控，即探针和内省，前者的实例有ping、telnet这种，查看端口或者IP是否通，并不知道应用内部是否正常；后者是应用内部各种情况对外暴露出来，比如node-exporter，会把服务器上的各种指标暴露出来；
- 监控模式有拉取和推送两种模式，Prometheus主要是拉模式，数据的拉取间隔由Prometheus服务控制，由于间隔的存在可能存在时效性的问题；推模式的实例有CDH的server-agent这种模式，从节点都要有agent定时发送信息给主节点，触发事件也会发送相应幸好，时效性好一些，缺点是各种重复数据的影响。
- 常见监控系统有：Nagios、Zabbix、Ganglia、Open-Falcon、ZMon
- Go和Python都是运维非常适合学习的语言，在云环境下，Go的应用面可能更广
2.2 认识Prometheus
2.2.1 Prometheus介绍
Prometheus是什么？以我的感觉来说就是一个开源易用的、支持水平拓展的、可自定义exporter的、以拉取模式为主推送模式为辅的监控解决方案（以下架构图来源于《Prometheus云原生监控：运维与开发实战》）。
这个我的理解是这样的：
- Pushgateway满足推送模式的指标；
- Job/Exporter是我们所说的实际采集器，Prometheus提供了丰富API支持，满足自定义需求；
- Prometheus Server即实际的Prometheus服务，进行指标的抓取，存储，查询，联邦架构下，多个Prometheus可以负责不通部分的指标采集，最终再由一个Prometheus进行指标汇聚；
- Service Discovery即服务发现，满足对新增服务的动态发现；
- Alertmanger提供告警支持，自定义配置告警规则；
- Web UI是为了进行数据可视化，大部分使用Grafana进行可视化，也可以自己编写程序进行可视化。
2.2.2 Prometheus的安装
可以说Prometheus的安装相当之简单，在官网下载程序包后放在Linux服务器上解压就可以用，即开即用；
tar -zxvf prometheus.tar.gz
若要启动，直接运行二进制文件prometheus即可，也可以添加自己需要的启动参数，使用prometheus --help可以看到全部支持参数：
./prometheus --web.enable-lifecycle --web.enable-admin-api --storage.tsdb.path="/data1/prometheus_data"
2.2.3 Prometheus的控制台
默认端口不变的情况下可以直接通过http://ip:9090/targets查看targets列表：
在Graph中可以使用PromQL进行查询的预览
如果配置了告警，可以在Alerts中查看，具体的规则可以通过Status->Rules查看