《Prometheus 云原生监控：运维与开发实战》阅读笔记 一、二章

《Prometheus 云原生监控运维与开发实战》阅读笔记 一、二章一、 参考资料二、笔记总结前言为什么要写这本书Prometheus是由SoundCloud开源的监控系统是Google BorgMon监控系统的开源版本。Prometheus开源项目是继Kubernetes后第二个正式加入CNCFCloud Native Computing Foundation云原生计算基金会的项目也是继Kubernetes之后第二个正式“毕业”的CNCF项目是容器和云原生领域事实上的监控标准解决方案。2019年我主导的项目KubernetesPrometheus一举拿下了公司年度最佳产研类项目有10余人参与到这个项目中通过项目室闭关的形式用了半年多的时间将全公司的应用全部迁移到了Kubernetes集群上并接入了Prometheus监控。如何阅读本书本书共分为11章。第1章最后介绍了常见的监控系统Nagios、Zabbix、Ganglia、Open-Falcon、ZMon以及进行监控系统选型时应该考虑的维度及误区。第7章介绍了Prometheus中与Exporter相关的概念。为了帮助读者提高编码水平和真正写好Exporter本章还给出了写好Exporter的建议并结合Node Exporter、Redis Exporter、MySQL Exporter、RocketMQ Exporter等的原理进行分析讲解。通过对本章的学习读者可以掌握使用和定制Exporter的方法。第1章 监控之美阿里云在上万个Kubernetes简称K8S集群大规模实践中保证了全球跨数据中心的可观测性这正是基于Prometheus Federation的全球多级别监控架构实现的。1.1 监控把握应用的脉搏监控系统可以贯穿于移动端、前端、业务服务端、中间件、应用层、操作系统等渗透到IT系统的各个环节。如图1-1所示通常情况下监控系统分为端监控、业务层监控、应用层监控、中间件监控、系统层监控这5层。市面上的监控系统可以说是五花八门Apache的SkyWalking、百度的DP、美团的CAT、蚂蚁金服的九色鹿、宜信的UAVstack、滴滴的Omega、360和头条的Sentry、腾讯的badjs、阿里云的arms以及已经商业化的Fundbug、听云和神策等都是很知名的监控系统。每种监控系统都有各自的价值通常来说Zabbix是针对系统层的监控系统ELKElasticsearchLogstashKibana主要是做日志监控的而Prometheus和Grafana可以实现对端、业务层、应用层、中间件、系统层进行监控因此Prometheus是打造一站式通用监控架构的最佳方案之一。1.2 监控架构分类成熟的分布式软件系统在使用过程中可以分为监控告警、问题排查和稳定性保障这3个部分。1.3 MDD思想从指标到洞察力1.3.1 MDD理念综述MDDMetrics-Driven Development主张整个应用开发过程由指标驱动通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念不但可以让程序员实时感知生产状态及时定位并终结问题而且可以帮助产品经理和运维人员一起关注相关的业务指标。其实技术领域有很多驱动开发的理念如表1-2所示。MDD可使所有可以测量的东西都得到量化和优化进而为整个开发过程带来可见性帮助相关人员快速、准确地做出决策并在发生错误时立即发现问题并修复。1.3.2 指导实践的3大监控方法论1.Google的四大黄金指标延迟例如HTTP请求平均延迟。流量例如每秒处理的HTTP请求数。错误例如HTTP 500错误数。饱和度例如内存、CPU、I/O、磁盘使用量。2.Netflix的USE方法使用率例如 CPU、内存、网络、磁盘等的资源使用率。饱和度例如CPU的平均运行排队长度。错误例如网卡在数据包传输过程中检测到以太网络冲突了14次。3.Weave Cloud的RED方法Rate每秒接收的请求数Errors每秒失败的请求数。Duration每个请求所花费的时间用时间间隔表示。一般来说上述三大监控理论的最佳实践是在遵循Google四大黄金指标的前提下对于在线系统结合RED方法和缓存命中率方式进行监测对于离线系统或者主机监控以USE方法为主进行监测对于批处理系统可以采用类似Pushgateway的形式进行监控。1.4 监控系统选型分析及误区探讨1.4.1 黑盒监控和白盒监控黑盒监控探针位于应用程序的外部通过监听端口是否有响应且返回正确的数据或状态码等外部特征来监控应用程序。白盒监控白盒监控可以直接将事件、日志和指标发送到监控工具它具有比黑盒监控更丰富的应用程序上下文信息。1.4.2 监控检查的两种模式—拉取和推送拉模式在云原生环境中有比较大的优势原因是在分布式系统中一定是有中心节点知道整个集群信息的那么通过中心节点就可以完成对所有要监控节点的服务发现此时直接去拉取需要的数据就好了推模式虽然可以省去服务发现的步骤但每个被监控的服务都需要内置客户端还需要配置监控服务端的信息这无形中加大了部署的难度。推模式在OpenStack和Kubernetes等环境中使用比较少。1.4.3 其它 5 种常见的监控系统1.Nagios2.Zabbix3.Ganglia4.Open-Falcon5.ZMon1.4.4 监控系统的选型分析及误区探讨1.功能能否实现开箱即用从而缩短项目周期、降低成本等。2.性能阿里的Prometheus从容应对了2019年“双十一”巨大流量带来的性能挑战。3.数据存储Zabbix采用关系数据库保存这极大限制了Zabbix采集的性能。4.服务发现Prometheus的动态发现机制不仅支持swarm原生集群还支持Kubernetes容器集群的监控它是目前容器监控最好的解决方案。5.运维管理Prometheus虽然本身的画图展示功能非常一般但是它借用了开源的产品Grafana结合Grafana后Prometheus的画图功能实现了质的突破。6.开发语言控系统的开发语言已经从C语言、C语言、Java语言转移到了Go语言阵营以Open-Falcon和Prometheus为代表。7.社区力度及生态发展尤其是Prometheus作为CNCF第二个毕业的作品其Google搜索量和GitHub活跃度非常高。Prometheus也是直接对接K8S环境的非常适合云上使用。8.误区探讨很多人面对监控系统时会有一种自研的冲动自研会有交接问题、KPI问题。如果之前自研的人不对监控系统进行维护了会有什么问题这些自研系统的交接会不会给新人挖坑般的噩梦体验是否真的有自研的必要如果不是KPI的压迫可以考虑如下问题目前市面上的监控系统是否真的都无法满足目前业务需求团队的核心竞争力真的就是监控系统吗是否有足够的能力、人力、财力、精力来支持自研1.5 本章小结本章介绍了监控的概念、监控的分类、MDD理念、Google四大黄金指标、USE方法、RED方法等监控理论也总结了监控应用程序的两种方法—探针和内省以及执行监控检查的两种方式—拉取和推送还介绍了常见的监控系统Nagios、Zabbix、Ganglia、Open-Falcon、ZMon以及监控系统选型时应该考虑的维度和避免的误区。相信通过对本章的学习大家会对监控系统有较深入的认识并初步具备自主选型和设计监控系统架构的能力。第2章 Prometheus入门Prometheus既是一个时序数据库又是一个监控系统更是一套完备的监控生态解决方案。作为监控系统2018年8月9日CNCF[2]在PromCon年度Prometheus会议上宣布Prome-theus是继Kubernetes之后的第二个CNCF“毕业”项目。仅仅是Prometheus的Exporter就已经支持了对官方收录和未收录的上千种常见软件、中间件、系统等的监控。2.1 Prometheus发展简史现在最常见的Kubernetes容器调度管理系统中通常会搭配Prometheus进行监控。2016年5月继Kubernetes之后Prometheus成为第二个正式加入CNCF的项目同年6月正式发布1.0版本。2017年年底发布了基于全新存储层的2.0版本该版本能更好地与容器平台、云平台兼容。2.2 Prometheus的主要特点通过PromQL实现多维度数据模型的灵活查询。二进制文件直接启动也支持容器化部署镜像。Prometheus认为最有用的数据是最近的数据监控数据默认保留15天。本地存储有限存储大量的历史数据需要对接第三方远程存储。Prometheus默认是拉模型建议合理规划网络尽量不要转发。2.3 Prometheus架构剖析Prometheus主要由Prometheus Server、Pushgateway、Job/Exporter、Service Discovery、Alertmanager、Dashboard[1]这6个核心模块构成。1.Job/ExporterJob分为长时间执行和短时间执行两种。对于长时间执行的Job可以使用Prometheus Client集成进行监控对于短时间执行的Job可以将监控数据推送到Pushgateway中缓存。2.PushgatewayPrometheus是拉模式为主的监控系统它的推模式就是通过Pushgateway组件实现的。Pushgateway是支持临时性Job主动推送指标的中间网关它本质上是一种用于监控Prometheus服务器无法抓取的资源的解决方案。它也是用Go语言编写的在Apache 2.0许可证下开源。Pushgateway作为一个独立的服务位于被采集监控指标的应用程序和Prometheus服务器之间。应用程序主动推送指标到PushgatewayPushgateway接收指标然后Pushgateway也作为target被Prometheus服务器抓取。它的使用场景主要有如下几种。临时/短作业。批处理作业。应用程序与Prometheus服务器之间有网络隔离如安全性防火墙​、连接性不在一个网段服务器或应用程序仅允许特定端口或路径访问​。3.服务发现Service Discovery作为下一代监控系统的首选解决方案Prometheus通过服务发现机制对云以及容器环境下的监控场景提供了完善的支持。例如Prometheus可以使用Kubernetes的API获取容器信息的变化如容器的创建和删除来动态更新监控对象。4.Prometheus服务器Prometheus ServerPrometheus服务器是Prometheus最核心的模块。它主要包含抓取、存储和查询这3个功能。5.DashboardPrometheus服务器除了内置查询语言PromQL以外还支持表达式浏览器及表达式浏览器上的数据图形界面。6.AlertmanagerAlertmanager是独立于Prometheus的一个告警组件需要单独安装部署。2.4 Prometheus的3大局限性首先Prometheus作为一个基于度量的系统不适合存储事件或者日志等它更多地展示的是趋势性的监控。如果用户需要数据的精准性可以考虑ELK或其他日志架构。另外APM更适用于链路追踪的场景。其次Prometheus认为只有最近的监控数据才有查询的需要所有Prometheus本地存储的设计初衷只是保存短期如一个月的数据不会针对大量的历史数据进行存储。如果需要历史数据则建议使用Prometheus的远端存储如OpenTSDB、M3DB等。最后集群上究竟采用Prometheus还是直接使用InfluxDB需要结合实际场景来选择这部分内容在第9章将详细介绍。2.5 快速安装并启动Prometheus以下是prometheus.yml文件配置各个部分的含义和功能的注释。# global模块是全局配置信息它定义的内容会被scrape_configs模块中的每个Job单独覆盖global:scrape_interval:15s# 抓取target的时间间隔设置为15秒默认值为1分钟。经验值为1060sevaluation_interval:15s#Prometheus计算一条规则配置的时间间隔设置为15秒#默认值为1分钟# scrape_timeout # 抓取target的超时事件默认值为10秒# external_labels # 与外部系统通信时添加到任意时间序列或告警所用的外部标签# 告警模块Prometheus Server发送请求给Alertmanager之前也会触发一次relabel操作# aler子模块下也可以配置alert_relabel_configsalerting:alertmanagers:-static_configs:# 静态配置Alertmanager的地址也可以依赖服务发现动态识别-targets:# 可以配置多个IP地址-localhost:9093# Prometheus自定义的rule主要分为Recording rule和Alerting rule两类rule_files:-alertmanager_rules.yml-prometheus_rules.ymlscrape_configs:# Job名称很重要Prometheus会将该名称作为Label追加到抓取的每条时序中-job_name:prometheus# metrics_path defaults to /metrics # metrics_path默认值是/metrics# 可以自定义表示抓取时序的http path# scheme defaults to http. # scheme默认是http表示抓取时序数据时使用的网络协议# param 抓取时序的相关参数可以自定义static_configs:# 静态方式-targets:[localhost:9090]-job_name:springboot-demo# 第二个微服务Spring Boot作业metrics_path:/actuator/prometheusstatic_configs:-targets:[localhost:8080]通过上述注释可知scrape_configs主要用于配置采集数据节点的操作它和global重合的配置部分会覆盖global部分每一个采集配置的具体参数及说明如表2-3所示。2.6 本章小结本章的最后还介绍了Prometheus的安装方法并解释了prometheus.yml配置文件中的核心配置项。