Prometheus监控实战(txt+pdf+epub+mobi电子书下载)


发布时间:2020-07-25 17:50:33

点击下载

作者:(澳)詹姆斯·特恩布尔(James Turnbull)

出版社:机械工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

Prometheus监控实战

Prometheus监控实战试读:

前言

第1章 监控简介1.1 什么是监控1.1.1 技术作为客户1.1.2 业务作为客户1.2 监控基础知识1.2.1 事后监控1.2.2 机械式监控1.2.3 不够准确的监控1.2.4 静态监控1.2.5 不频繁的监控1.2.6 缺少自动化或自服务1.2.7 监控模式总结1.3 监控机制1.3.1 探针和内省1.3.2 拉取和推送1.3.3 监控数据的类型1.4 指标1.4.1 什么是指标1.4.2 指标类型1.4.3 指标摘要1.4.4 指标聚合1.5 监控方法论1.5.1 USE方法1.5.2 Google的四个黄金指标1.6 警报和通知1.7 可视化1.8 另一本关于监控的书1.9 本书内容1.10 小结

第2章 Prometheus简介2.1 Prometheus起源2.2 Prometheus架构2.2.1 指标收集2.2.2 服务发现2.2.3 聚合和警报2.2.4 查询数据2.2.5 自治2.2.6 冗余和高可用性2.2.7 可视化2.3 Prometheus数据模型2.3.1 指标名称2.3.2 标签2.3.3 采样数据2.3.4 符号表示2.3.5 保留时间2.4 安全模型2.5 Prometheus生态系统2.6 参考链接2.7 小结

第3章 安装和启动Prometheus3.1 安装Prometheus3.1.1 在Linux上安装Prometheus3.1.2 在Windows上安装Prometheus3.1.3 在Windows上安装Prometheus的其他方式3.1.4 在Mac OS X上安装Prometheus3.1.5 通过监控套件安装Prometheus3.1.6 通过配置管理工具安装Prometheus3.1.7 通过Kubernetes安装Prometheus3.2 配置Prometheus3.2.1 global3.2.2 alerting3.2.3 rule_files3.2.4 scrape_configs3.3 启动Prometheus3.4 第一个指标3.5 表达式浏览器3.6 聚合时间序列3.7 容量规划3.7.1 内存3.7.2 磁盘3.8 小结

第4章 监控主机和容器4.1 监控节点4.1.1 安装Node Exporter4.1.2 配置Node Exporter4.1.3 配置textfile收集器4.1.4 启用systemd收集器4.1.5 运行Node Exporter4.1.6 抓取Node Exporter4.1.7 过滤收集器4.2 监控Docker容器4.2.1 运行cAdvisor4.2.2 抓取cAdvisor4.3 抓取的生命周期4.4 标签4.4.1 标签分类4.4.2 重新标记4.5 Node Exporter和cAdvisor指标4.5.1 USE方法4.5.2 服务状态4.5.3 可用性和up指标4.5.4 metadata指标4.6 查询持久性4.6.1 记录规则4.6.2 配置记录规则4.6.3 添加记录规则4.7 可视化4.7.1 安装Grafana4.7.2 启动和配置Grafana4.7.3 配置Grafana Web界面4.7.4 第一个仪表板4.8 小结

第5章 服务发现5.1 静态配置的局限性5.2 基于文件的服务发现5.3 基于API的服务发现5.4 基于DNS的服务发现5.5 小结

第6章 警报管理6.1 警报6.2 Alertmanager如何工作6.3 安装Alertmanager6.3.1 在Linux上安装Alertmanager6.3.2 在Windows上安装Alertmanager6.3.3 通过监控套件安装Alertmanager6.3.4 通过配置管理工具安装Alertmanager6.4 配置Alertmanager6.5 运行Alertmanager6.6 为Prometheus配置Alertmanager6.6.1 Alertmanager服务发现6.6.2 监控Alertmanager6.7 添加警报规则6.7.1 添加第一条警报规则6.7.2 警报触发6.7.3 Alertmanager的警报6.7.4 添加新警报和模板6.8 路由6.9 接收器和通知模板6.10 silence和维护6.10.1 通过Alertmanager控制silence6.10.2 通过amtool控制silence6.11 小结

第7章 可靠性和可扩展性7.1 可靠性和容错性7.1.1 重复的Prometheus服务器7.1.2 设置Alertmanager集群7.1.3 为Prometheus配置Alertmanager集群7.2 可扩展性7.2.1 功能扩展7.2.2 水平分片7.3 远程存储7.4 第三方工具7.5 小结

第8章 监控应用程序8.1 应用程序监控入门8.1.1 从哪里开始8.1.2 监控分类8.2 指标8.2.1 应用程序指标8.2.2 业务指标8.2.3 放置指标8.2.4 实用程序模式8.2.5 外部模式8.2.6 监控应用程序示例8.3 小结

第9章 日志监控9.1 日志处理9.2 mtail简介9.2.1 安装mtail9.2.2 使用mtail9.2.3 运行mtail9.3 处理Web服务器访问日志9.4 解析Rails日志到直方图9.5 部署mtail9.6 抓取mtail端点9.7 小结

第10章 探针监控10.1 探针架构10.2 Blackbox exporter10.3 安装exporter10.3.1 在Linux上安装exporter10.3.2 在Windows上安装exporter10.3.3 通过配置管理工具安装exporter10.4 配置exporter10.4.1 HTTP检查10.4.2 ICMP检查10.4.3 DNS检查10.5 启动exporter10.6 创建Prometheus作业10.7 小结

第11章 推送指标和Pushgateway11.1 Pushgateway11.1.1 Pushgateway使用场景11.1.2 安装Pushgateway11.1.3 在Linux上安装Pushgateway11.1.4 在Windows上安装Pushgateway11.1.5 通过配置管理工具安装Pushgateway11.1.6 配置和运行Pushgateway11.1.7 向Pushgateway发送指标11.1.8 在Pushgateway上查看指标11.1.9 删除Pushgateway中的指标11.1.10 从客户端发送指标11.2 抓取Pushgateway11.3 小结

第12章 监控Kubernetes12.1 Kubernetes集群12.2 在Kubernetes上运行Prometheus12.3 监控Kubernetes12.4 监控Kubernetes节点12.4.1 Node Exporter DaemonSet12.4.2 Node Exporter服务12.4.3 部署Node Exporter12.4.4 Node Exporter作业12.4.5 Node Exporter规则12.5 Kubernetes12.5.1 Kube-state-metrics12.5.2 Kube API12.5.3 cAdvisor和节点12.6 小结

第13章 监控Tornado13.1 边车模式13.2 MySQL13.3 Redis13.4 Tornado13.4.1 添加Clojure包装器13.4.2 添加注册表13.4.3 添加指标13.4.4 导出指标13.4.5 Tornado监控配置13.5 小结译者序

监控无处不在。

任何服务都离不开监控系统,对于管理维护服务的组织来说,监控是必备技能之一。近几年来,容器化、微服务、云原生等方式成为流行的现代架构思想,这给监控系统带来了不小的挑战。具体来说,监控系统需要在动态的云环境或者基于容器的微服务中快速、自动地识别对象的生命周期,并持续地提供近实时的监控检测。

Prometheus可以帮助你应对这些挑战。Prometheus开源项目孵化于云原生计算基金会(Cloud Native Computing Foundation,CNCF),并在2018年的PromCon会议上宣布正式从CNCF毕业,这是继Kubernetes之后的第二个CNCF毕业项目。如今,Prometheus已被全球众多企业广泛使用,以满足上面提到的复杂的监控需求,同时它也可以用来监控属于传统架构的资源。目前,Prometheus已成为构建现代云原生架构的企业的首选开源监控工具。

本书由浅入深地对Prometheus进行了全方位的介绍,内容通俗易懂,理论与实践相结合。首先从监控体系讲起,介绍了关于监控的各种经典理论和方法。然后循序渐进地介绍了Prometheus的各个功能组件和配置方法,包括监控主机和容器、服务发现、警报管理,以及Kubernetes和运行其上的应用程序的监控。本书覆盖了目前的一些主流云技术(比如AWS),但同样适用于各种其他环境和技术栈。读过本书后,相信你可以设计并构建出一个优秀的监控系统。

这里要感谢肖总,无论是曾经共事的阶段还是在工作之外他都给了我很多的鼓励与支持,很开心也很幸运可以再一次共同完成翻译工作。另外,感谢各位编辑的悉心指导,他们不辞辛苦地对本书进行了大量的校对和编辑工作,最终确保了本书的顺利出版。

最后,感谢爱人和我一起牺牲掉很多休息时间,共同投入到本书的翻译工作中,同时这也是人生一次难得的体验。

由于本人水平有限,书中难免会出现错误或者不妥之处,欢迎批评指正。史天2019年5月

前言

本书面向的读者

本书是一本基于Prometheus的监控指南。

大多数示例都基于Ubuntu Linux,所以读者最好具备基本的UNIX/Linux技能,并熟悉命令行、文件编辑、软件安装、服务管理和基础网络知识。

Prometheus正在迅速发展,这意味着你需要注意本书中提及和使用的工具版本。

本书旨在支持Prometheus 2.3.2或更高版本,内容可能不适用于早期版本。致谢

感谢露丝·布朗(Ruth Brown)帮助本书变得有趣,让我可以坚持写到深夜。

感谢西德·奥兰多(Sid Orlando)让本书的措辞变得更加得体。

感谢布莱恩·布雷泽(Bryan Brazil)出色的Prometheus博客,他同时也在做Prometheus的相关培训。

感谢戴维·卡尔森(David Karlsen)的技术评审工作。技术评审人员

感谢那些帮助本书变得更加准确和有价值的技术评审!

杰米·威尔金森(Jamie Wilkinson)是Google存储基础设施团队的SRE(网站可靠性工程师)。他拥有计算机科学学士学位,有充足的计算理论知识,于1999年开始从事Linux系统管理工作。他为Google SRE手册贡献了关于监控的章节。杰米与他的家人住在澳大利亚的悉尼。

保罗·吉尔(Paul Gier)作为一个在专有软件流行时期成长的“好奇宝宝”,对缺乏资金和许可证感到沮丧。在了解了一个名为Linux的新操作系统后,保罗开始沉迷于提供自由软件的想法——这一想法最终使他成了Red Hat的首席软件工程师,在那里他做了10多年自由软件的开发工作。保罗对基于容器的新基础设施及其带来的所有解决方案和问题非常着迷。他和他的妻子、三个孩子,以及两只狗和一只淘气的猫住在得克萨斯州的奥斯汀。编辑

希德·奥兰多(Sid Orlando)是一位编辑和作家,还做着其他一些有趣的事情。她目前正在制作Stripe的软件工程技术杂志《Increment》,吸引了一大批粉丝,并且她在自己纽约的公寓里养了大量的植物。作者

詹姆斯·特恩布尔(James Turnbull)是一位作家和工程师。他最近出版的书包括《The Packer Book》《The Terraform Book》和《The Art of Monitoring》,以及关于开源容器虚拟化技术的《The Docker Book》,还有关于开源日志工具的《The Logstash Book》。詹姆斯还撰写了两本关于Puppet的书:《Pro Puppet》和《Pulling Strings with Puppet》。同时他还是另外三本书的作者:《Pro Linux System Administration》《Pro Nagios 2.0》和《Hardening Linux》。

他目前是Empatico公司的首席技术官,并且曾担任过Kickstarter公司的首席技术官、Docker公司服务和支持副总裁、Venmo公司工程副总裁以及Puppet公司技术运营副总裁。他喜欢品尝美食、喝酒、读书、摄影和养猫。代码约定

这是一个内联代码语句。一个代码块如下所示:代码清单1 示例代码

较长的代码会被换行。如果你在代码块中看到...,则表示为简洁起见,输出被缩减了。代码和示例

本书中包含的代码和示例可从GitHub上获得:https://github.com/turnbullpress/prometheusbook-code。勘误

请发送电子邮件至james+errata@lovedthanlost.net。声明

本书仅供学习使用。作者未将其作为法律、会计或其他专业服务建议提供。尽管在编写本书时已尽最大努力,但作者不做任何形式的陈述或保证,并且不对内容的准确性或完整性承担任何责任,并特别声明对用于特定目的的适销性或适用性不做任何默认保证。对于因本书所含信息或程序直接或间接造成(或声称是由此造成)的任何损失,或偶然或间接损失,作者不对任何个人或实体承担任何责任或义务。每家公司情况都不同,此处包含的建议和策略可能不适合你的情况。在开始任何基础设施项目之前,你应该寻求专业人士的服务。第1章 监控简介

本书的核心是Prometheus,一个开源的监控系统,它从应用程序中实时获取时间序列数据,然后通过功能强大的规则引擎,帮助你识别监控环境所需的信息。在下一章中,我们将介绍Prometheus及其架构和组件。本书将指导你使用Prometheus来构建监控系统,重点将放在动态云环境、Kubernetes环境和容器环境的监控。同时,我们还将研究如何从应用程序获取数据并将这些数据用于警报和可视化。

与此同时,这也是一本关于监控的书,所以在介绍Prometheus之前,本章将带你了解一些监控的基础知识。我们会循序渐进地介绍什么是监控,以及通用的监控方法,并会解释一些将在本书后面章节提到的术语和概念。1.1 什么是监控

从技术角度来看,监控(monitoring)是衡量和管理技术系统的工具和流程。但监控远不止于此,监控将系统和应用程序生成的指标转换为对应的业务价值。你的监控系统会将这些指标转换为衡量用户体验的依据,该依据为业务提供反馈,以确保为客户提供了所需的产品。同时该依据还提供了对技术的反馈,指出哪些组件不起作用或者导致服务质量下降。

实际上,监控系统有以下两个“客户”:

·技术

·业务1.1.1 技术作为客户

监控系统的第一个客户是技术,这是你、你的团队以及其他管理和维护技术环境的同事(可能被称为运维工程师、DevOps或是SRE)需要面对的。你可以通过监控来了解技术环境状况,还可以帮助检测、诊断和解决技术环境中的故障和问题(尤其是在影响用户之前)。监控提供了大量的数据,帮助洞察关键的产品和技术决策,并衡量这些项目是否成功。监控也是产品管理生命周期以及与内部客户关系的基础,有助于验证项目资金是否得到充分利用。如果没有监控,那么最好的情况是没有问题发生,最糟糕的情况则是问题发生了但没有被发现。

Google SRE手册中有一个很棒的图表,显示了监控是构建和管理应用程序层次结构的基础。1.1.2 业务作为客户

业务是监控系统的第二个客户。监控系统是为了支持业务,并确保业务持续开展。监控可以提供报告,使企业能够进行良好的产品和技术投资,还有助于企业衡量技术带来的价值。1.2 监控基础知识

监控是管理基础设施和业务的核心工具。监控也是必需的,应该和应用程序一起构建和部署。没有监控,你将无法了解你的系统环境、进行诊断故障、制定容量计划,也无法向组织提供系统的性能、成本和状态等信息。[1]

关于监控,我们前面提到的Google服务层次结构图就是一个很好的阐述(如图1-1所示)。

但是监控没有那么容易实施,如果你监控了错误的东西或者使用了错误的方式,那么监控系统的价值将大大降低,这里列举了一些关于监控的反模式和解决方案。[1] Site Reliability Engineering,由Betsy Beyer、Chris Jones、Jennifer Petoff和Niall Richard Murphy(O’Reilly)编辑。版权归2016 Google, Inc.所有,978-1-491-92912-4。1.2.1 事后监控

对于任何应用程序开发方法,在构建之前确定要构建的内容都是个好主意。遗憾的是,有一种常见的反模式,即将监控和其他运维工作(比如安全性)视为应用程序的增值组件而非核心功能。与安全性一样,监控也应该是应用程序的核心功能。如果你要为应用程序构建规范或用户故事,那么务必先把应用程序每个组件的监控指标考虑进来,千万不要等到项目结束或部署之前再做这件事情。我保证你会错过一些需要监控的东西。图1-1 服务层级有关如何简化此过程的建议,请参阅下面关于自动化和自服务的讨论。1.2.2 机械式监控[1]

许多环境都会为所有应用程序建立货物崇拜(Cargo Cult)式的监控系统。团队始终复用他们过去使用的检查机制,而不会为新系统或应用程序进行更新。一个常见的例子是监控每台主机上的CPU、内存和磁盘,但不监控可以指示主机上应用程序是否正常运行的关键服务。如果应用程序在你没有注意到的情况下发生故障,那么即使进行了监控,你也需要重新考虑正在监控的内容是否合理。

根据服务价值设计自上而下的监控系统是一个很好的方式(如图1-2所示),这会帮助明确应用程序中更有价值的部分,并优先监控这些内容,再从技术堆栈中依次向下推进。图1-2 监控设计

从业务逻辑和业务输出开始,向下到应用程序逻辑,最后到基础设施。这并不意味着你不需要收集基础设施或操作系统指标——它们在诊断和容量规划中很有帮助——但你不太可能使用这些来报告应用程序的价值。

如果无法从业务指标开始,则可试着从靠近用户侧的地方开始监控。因为他们才是最终的客户,他们的体验是推动业务发展的动力,了解他们的体验并发现他们何时遇到问题本身就很有价值。[1] 参考维基百科https://en.wikipedia.org/wiki/Cargo_cult_programming。货物崇拜编程(Cargo Cult Programming)是一种计算机程序设计中的反模式,其特征为不明就里地、仪式性地使用代码或程序架构。货物崇拜编程通常是程序员既没理解他要解决的bug、也没理解表面上的解决方案的典型表现。—译者注1.2.3 不够准确的监控

这个反模式的一个常见形式是虽然监控了主机上的服务状态,但不够准确。例如,通过检查HTTP 200状态码可以监控Web应用程序是否正常运行,它会告诉你应用程序正在响应请求,但并不会反映出是否返回了正确的数据。

因此需要找准服务监控的内容——例如,监控业务事务的内容或速率,而不是监控它运行的Web服务器的运行时间。你会获得两种好处:如果服务因配置错误、程序bug或受损而导致内容不正确,你会及时查看到;而如果内容因底层Web服务而出现错误,你同样也会知道。1.2.4 静态监控

另一种反模式是使用静态阈值——例如,如果主机的CPU使用率超过80%就发出警报。这种检查通常是不灵活的布尔逻辑或者一段时间内的静态阈值,它们通常会匹配特定的结果或范围,这种模式没有考虑到大多数复杂系统的动态性。阈值的匹配或许很重要,但它可能由异常事件触发,甚至可能是自然增长的结果。

静态阈值几乎总是错误的。数据库性能分析供应商VividCortex的[1]首席执行官Baron Schwartz对此评论道:它们比一个停摆的时钟更[2]糟糕,至少时钟每天还会有两次准的时候。任何给定系统的阈值都是错误的,因为所有系统都略有不同,并且在任何给定时刻也都是错误的,因为系统在经历不断变化的负载和其他情况。

为了更好地监控,我们需要查看数据窗口,而不是静态的时间点,需要使用更智能的技术来分析指标和阈值。[1] https://www.vividcortex.com/blog/2013/04/10/2-reasons-why-threshold-based-monitoring-is-hopelessly-broken/。[2] 英语谚语。一只坏了的钟,指针会停在一个固定的时刻不动,当正确的时间恰巧与钟面显示的时间一致时,这只坏钟在不明就里的人眼中就是准的。又因为一天有24个小时,而钟面显示的是12个小时,也就是说钟表走两圈才走完一天,所以说它每天也有两次准的时候。比喻通常不可靠的人或事物偶尔可以提供正确的信息,即使只是偶然。—译者注1.2.5 不频繁的监控

对于许多监控工具来说,设定监控周期都是一项挑战,一般默认检查周期设置了一个较大的值——例如,每隔5~15分钟仅检查一次应用程序。这通常会导致检查之间发生的关键事件丢失。你应该频繁地监控应用程序,以获得以下好处:

·识别故障或异常。

·满足响应时间预期——你绝对希望在用户报告故障之前找到问题。

·提供更细颗粒度的数据,以识别性能的问题和趋势。

始终记住存储足够多的历史数据可以有效地帮助识别性能的问题和趋势。在很多情况下,这可能只需要数天或数周的数据——但如果丢弃了这些数据,则可能无法识别出趋势或发现重复出现的问题。1.2.6 缺少自动化或自服务

监控系统很差或者没能正确实施的常见原因是它很难实现。如果你让应用程序开发人员觉得监测应用程序、收集数据或可视化很难完成,那么他们可能就不会去做这些事。如果监控的基础设施是手动维护的,或者过于复杂,那么由此产生的问题将导致监控系统落后或者发生故障,然后你会花费更多的时间来修复和维护监控系统,而不是监控这件事本身。

应尽可能使监控系统的实施和部署自动化:

·应该由配置管理进行部署。

·主机和服务的配置应该通过自动发现或自助提交来进行,这样可以自动监控新的应用程序,而不需要人为添加。

·添加检测应该很简单,并且是基于插件模式,开发人员应该能够把它放置到库中,而不必自己配置它。

·数据和可视化应该是自服务的。每个需要查看监控输出的人都应该能够查询和可视化这些内容。(这并不是说你不应该为人们构建仪表板,而是如果他们想要更多,他们就不应该问你。)1.2.7 监控模式总结

一个良好的监控系统应该能提供以下内容:

·全局视角,从最高层(业务)依次展开。

·协助故障诊断。

·作为基础设施、应用程序开发和业务人员的信息源。

同时它也应该是:

·内置于应用程序设计、开发和部署的生命周期中。

·尽可能自动化,并提供自服务。

这种对监控系统“良好”的定义与另一个新出现的术语“可观察性”是交叉重叠的。你可以在Cindy Sridharan的精彩博客文章中看到更多相关信息,了解两者之间的差异。1.3 监控机制

监控的方法是多种多样的,实际上,你可以说从单元测试到检查清单(checklist)的所有事情都是监控的某种形式。

Lindsay Holmwood对测试驱动的监控有一个很好的介绍,讨论了测试和监控之间的联系。此外,Cindy Sridharan关于微服务测试的文章也介绍了一些有趣的测试和监控的相似之处。

但是传统上,监控的定义侧重于检查和测量应用程序的状态。1.3.1 探针和内省

监控应用程序主要有两种方法:探针(probing)和内省[1](introspection)。探针监控是在应用程序的外部,它查询应用程序的外部特征:监听端口是否有响应并返回正确的数据或状态码。探针监控的一个例子是执行ICMP检查并确认可以收到响应。Nagios就是一个主要基于探针监控的监控系统。

内省监控主要查看应用程序内部的内容。应用程序经过检测,并返回其状态、内部组件,或者事务和事件性能的度量。这些数据可准确显示应用程序的运行方式,而不仅是其可用性或其表面行为。内省监控可以直接将事件、日志和指标发送到监控工具,也可以将信息发送给状态或健康检查接口,然后由监控工具收集。

内省方法提供了应用程序实际运行的状态,它允许你传达比探针监控更丰富且更多的有关应用程序状态上下文的信息,是能提供你和业务所需的监控信息的更好方式。

这并不是说探针监控没有作用了,了解应用程序的外部状态通常很有用,特别是如果应用程序由第三方提供,并且你没有深入了解其内部操作的时候。从外部查看应用程序以了解某些网络、安全性或可用性问题通常也很有帮助。通常建议对安全网络进行探针监控以发现问题,然后使用内省监控进行报告和诊断。我们将在第10章更多地介绍探针监控。[1] 另一种说法是黑盒监控与白盒监控。1.3.2 拉取和推送

目前有两种执行监控检查的方式,分别是拉取(pull)和推送(push),这里我们简单讨论一下。

基于拉取的监控方式会提取或检查远程应用程序——例如包含指标的端点,或是探针监控中使用ICMP进行的检查。在基于推送的监控方式中,应用程序发送事件给监控系统接收。

这两种方法都有利有弊。关于这些优点和缺点,监控领域内部存在相当大的争议,但就许多用户而言,这些辩论没有实际意义。Prometheus主要是一个基于拉取的系统,但它也支持接收推送到网关的事件,我们将在本书中展示如何使用这两种方法。1.3.3 监控数据的类型

监控工具可以收集各种不同类型的数据,这些数据主要有两种形式:

·指标:大多数现代监控工具都非常依赖指标来帮助我们了解系统的情况。指标存储为时间序列数据,用于记录应用程序度量的状态,我们很快就会看到更多相关内容。

·日志:日志是从应用程序发出的(通常是文本的)事件。虽然有助于让你知道发生了什么,但它们通常对故障诊断和调查最有帮助。我们不会在本书中详细介绍日志,但是有很多可用的工具(如ELK堆栈)可用于收集和管理日志事件。[1]我写了一本关于你可能感兴趣的ELK堆栈的书。

由于Prometheus主要关注收集时间序列数据,因此接下来让我们更深入地了解指标。[1] https://www.logstashbook.com/。1.4 指标

指标似乎始终是任何监控体系结构中最直接的部分。然而,有时候我们并没有投入足够的时间来理解我们正在收集的内容,为什么要收集它们,以及我们对这些指标做了些什么。

许多监控框架的重点都是故障检测,即检测是否发生了特定的系统事件或处于什么状态(这是Nagios的风格)。当收到有关特定系统事件的通知时,我们通常会查看收集到的任何指标,以找出发生的确切情况及其原因。在这个思路下,指标被视为故障检测的副产品或者补充。请参阅本章后面有关通知设计的讨论,以了解为什么这是一个具有挑战性的问题。

Prometheus改变了“指标作为补充”的观念,指标变成了监控工作流程中最重要的部分。Prometheus颠覆了以故障检测为中心的模型,指标用来反映环境的状态、可用性以及性能。

当指标可以提供有关状态和性能的信息时,本书通常避免重复布尔状态检查。

正确使用指标可以提供基础设施的动态实时信息,帮助你管理和做出有关系统的最佳决策。此外,通过异常检测和模式分析,指标有可能在故障或问题发生之前,或者是在特定系统事件导致系统瘫痪之前就有所察觉。1.4.1 什么是指标

由于指标和度量对监控框架至关重要,因此我们将帮助你了解到底什么是指标以及如何使用这些指标。这里我们以一个通俗易懂的方式,让你了解不同类型的指标、数据和可视化对我们的监控框架有何贡献。

指标是软件或硬件组件属性的度量。为了使指标有价值,我们会跟踪其状态,通常记录一段时间内的数据点。这些数据点称为观察点(observation),观察点通常包括值、时间戳,有时也涵盖描述观察点的一系列属性(如源或标签)。观察的集合称为时间序列。

时间序列数据的典型示例是网站访问或点击。我们定期收集有关网站点击量的观察点,记录点击次数和查看次数。我们还可能收集诸如访问来源、被访问到的服务器或其他各种信息等的属性。

我们通常以固定的时间间隔收集数据,该时间间隔被称为颗粒度(granularity)或分辨率(resolution),取值可以从1秒到5分钟,甚至到60分钟或更长。正确地选择指标的颗粒度至关重要,若选择得太粗糙,则很容易错过某些细节。例如,以5分钟为间隔对CPU或内存使用情况进行采样,几乎不可能识别出数据中的异常情况。另外,如果颗粒度过于精细,则需要存储和分析大量数据。

时间序列数据是这些观察点按时间顺序排列的集合。时间序列指标通常被可视化为二维图形,其中x轴是时间,y轴是具体的数据值(如图1-3所示)。通常,你会在y轴上看到多个数据值——例如,来自多个主机的CPU使用率值,或者成功和失败的事务。

这些图形非常有用,它们提供了相对容易理解的关键数据的直观展示,比使用列表形式的相同数据更加有效。图形还向我们展示了正在监控的任何历史节点,包括发生变化的内容和时间。我们可以使用这些功能来了解系统中发生的事情及其对应的时间。图1-3 图形示例1.4.2 指标类型

监控指标包含多种类型。

测量型

第一种指标类型是测量型(gauge),这种类型是上下增减的数字,本质上是特定度量的快照。常见的监控指标如CPU、内存和磁盘使用率等都属于这个类型。对于业务指标来说,指标可能是网站上的客户数量(如图1-4所示)。图1-4 测量型指标示例

计数型

第二种类型是计数型(counter),这种类型是随着时间增加而不会减少的数字。虽然它们永远不会减少,但有时可以将其重置为零并再次开始递增。应用程序和基础设施的计数型示例包括系统正常运行时间、设备收发包的字节数或登录次数。业务方便的示例可能是一个月内的销售数量或应用程序收到的订单数量(如图1-5所示)。

在图1-5的示例中,有一个计数型指标在一段时间内递增。

计数型指标的一个优势在于它们可以让你计算变化率。每个观察到的数值都是在一个时刻:t,你可以使用t+1处的值减去t处的值,以获得两个值之间的变化率。通过了解两个值之间的变化率,可以理解许多有用的信息。例如登录次数指标,你可以通过计算变化率来查看每秒的登录次数,这有助于确定网站这段时间的受欢迎程度。图1-5 计数型指标示例

直方图

直方图(histogram)是对观察点进行采样的指标类型,可以展现数据集的频率分布。将数据分组在一起并以这样的方式显示,这个被称为“分箱”(binning)的过程可以直观地查看数值的相对大小。统计每个观察点并将其放入不同的桶中,这样可以产生多个指标:每个桶一个,加上所有值的总和以及计数。

通常,频率分布直方图看起来像条形图(如图1-6所示)。图1-6 直方图指标示例

示例是身高频率分布的样本直方图。x轴是身高的分布,y轴是对应的频率值,例如可以看到身高160~165cm对应的值是2。

还有另一种指标类型,称为“摘要型”(summary),类似于直方图,但它还会计算百分位数。更多信息请参考https://prometheus.io/docs/practices/histograms/。

直方图可以很好地展现时间序列数据,尤其适用于数据的可视化(如应用程序延迟等)。1.4.3 指标摘要

通常来说,单个指标对我们价值很小,往往需要联合并可视化多个指标,这其中需要应用一些数学变换。例如,我们可能会将统计函数应用于指标或指标组,一些可能应用的常见函数包括:

·计数:计算特定时间间隔内的观察点数。

·求和:将特定时间间隔内所有观察点的值累计相加。

·平均值:提供特定时间间隔内所有值的平均值。

·中间数:数值的几何中点,正好50%的数值位于它前面,而另外50%则位于它后面。

·百分位数:度量占总数特定百分比的观察点的值。

·标准差:显示指标分布中与平均值的标准差,这可以测量出数据集的差异程度。标准差为0表示数据都等于平均值,较高的标准差意味着数据分布的范围很广。

·变化率:显示时间序列中数据之间的变化程度。以上是摘要方法的简要介绍,我们将在本书后面的章节中更为详细地介绍此部分内容。1.4.4 指标聚合

除了上述的指标摘要外,你可能经常希望能看到来自多个源的指标的聚合视图,例如所有应用程序服务器的磁盘空间使用情况。指标聚合最典型的样式就是在一张图上显示多个指标,这有助于你识别环境的发展趋势(如图1-7所示)。例如,负载均衡器中的间歇性故障可能导致多个服务器的Web流量下降,这通常比通过查看每个单独的指标更容易发现。图1-7 指标聚合示例

从图中可以看到30天内多个主机的磁盘使用情况,它为我们提供了一种快速确定某组主机的当前状态(和变化率)的方法。

最终,你会发现单一指标和聚合指标的组合可以提供最佳的健康视图:前者可深入到某个特定问题,而后者可以查看更高阶的状态。

接下来让我们更深入地了解指标摘要:使用(或者不使用)这些摘要的原因,以及如何使用平均值、中间数、标准差、百分位数和其他统计计算。

这是对某些统计技术的概述,而不是对主题的深入研究。对于具有较强的统计学或数学背景的人来说,对这些主题的探索可能显得过于简单。

平均值

平均值是标准的指标分析方法。实际上,几乎所有曾经监控或分析过网站及应用程序的人都会使用平均值。

例如,在网站运营领域,许多公司的生死存亡都取决于其网站或API的平均响应时间。

平均值很有吸引力,因为它们很容易计算。假设现在我们有一个包含七个时间序列值的列表:12、22、15、3、7、94和39。为了计算平均值,我们将值列表相加求和然后除以列表值的数量。

(12+22+15+3+7+94+39)/7=27.428 571 428 571

首先将七个值相加得到总和192,然后我们将总和除以值的数量,这里是7,以返回平均值:27.428 571 428 571。看起来很简单,对吧?但是,“魔鬼”都隐藏在细节中。

平均值假设事件都是正常的或者说你的数据是正态(或高斯)分布的——例如,在我们的平均响应时间中,假设所有事件以相同的速度运行或响应时间分布大致为钟形曲线,但应用程序很少出现这种情况。事实上,有个古老的统计学笑话(如图1-8所示),一位统计学家跳进平均深度只有10英寸(约25厘米)的湖中,然后差点被淹死……

为什么他差点会被淹死?因为湖中有大面积的浅水区和一部分深水区,由于浅水区面积较大,因此导致平均深度总体较低。同样的原则也适用于监控领域:高峰或低谷可能被平均值掩盖了。这些隐藏的异常值可能意味着,当我们认为大多数用户都享受着高质量的服务体验时,实际上很可能并非如此。

让我们看一个使用网站请求平均响应时间的示例(如图1-9所示)。

这里我们有一个图表显示了许多请求的响应时间,计算平均响应时间为4.1秒,这意味着绝大多数用户将体验到(可能)正常的4.1秒响应时间。但是,许多用户的响应时间要比这个时间长,甚至达到12秒,这是很难接受的。

让我们再看一个值分布更为广泛的例子(如图1-10所示)。图1-8 平均值的缺陷(版权归Jeff Danziger所有)图1-9 平均响应时间示例1图1-10 平均响应时间示例2

这次我们的平均值将是一个不那么理想的6.8秒。但更糟糕的是,这个平均值比大多数用户收到的响应时间要好得多,因为请求时间大约分布在为9秒、10秒和11秒。如果我们仅依靠平均值,则可能会认为应用程序的性能比真实情况要好得多。

中间数

那什么是中间数呢?中间数处在所有数值的正中心:正好50%的数值位于它前面,而另外50%则位于它后面。如果有奇数项个值,则处于中间位置的值即为中间数。对于前面提到的数据集(12、22、15、3、7、94和39)来说,中间数为3。如果存在偶数项个值,则中间数将是中间两个值的平均值。因此,如果我们从数据集中删除39让数值变成偶数个,则中间数将变为9。

我们将它应用于之前的两张图(如图1-11所示)。

我们可以看到第一个示例中的中间数为3,为数据提供了更乐观的表示。而在第二个示例中,中间数是8,稍微好一点但足够接近平均值以使其无效(如图1-12所示)。

你可能又发现这里的问题了,就像平均值一样,当数据分布呈钟形曲线时,中间数效果最好,但在真实环境中这是不现实的。

识别性能问题的另一种常用技术是根据平均值来计算指标的标准差。图1-11 响应时间的平均值和中间数示例1图1-12 响应时间的平均值和中间数示例2

标准差

正如我们在本章前面所学到的,标准差衡量数据集的变化或分布。标准差为0表示大部分数据接近平均值,标准差越大意味着数据越分散。标准差由正或负加上sigma符号表示,例如,1 sigma表示与平均值有一个标准差。

然而,与平均值和中间数一样,当数据呈正态分布时,标准差最有效。在正态分布中,有一种简单的方式来阐明分布:经验法则,也称为68-95-99.7法则或3 sigma法则(如图1-13所示)。法则指出,一个标准差或1到–1代表平均值两边68.27%的数据,两个标准差或2到–2代表95.45%,而三个标准差则代表99.73%。图1-13 经验法则

许多监控方法都会利用经验法则,当出现超过平均值两个标准差的事务或事件时触发警报,以捕获性能的异常值。然而,在之前的两个例子中,标准差并没有太大帮助。如果数据不是正态分布的,那么最终的标准差可能会误导你。

到目前为止,上述方法在识别异常数据方面没有提供很大帮助,但我们没有失去希望!下一个统计方法(百分位数)让我们看到了一丝曙光。

百分位数

百分位数度量的是占总数特定百分比的观察点的值。从本质上讲,它们会展示数据集的分布。例如,我们在上面看到的中间数是50百分位数(或p50)。对于中间数(已排好序的数据)来说,50%的值低于它,50%高于它。对于指标而言,百分位数很有意义,因为它们可以清晰地展现数值的分布。例如,一个事务的99百分位数为10毫秒,这很容易理解:99%的事务在10毫秒或更短时间内完成,1%的事务处理时间超过10毫秒。百分位数是分位数的一种。

百分位数是识别异常值的理想选择。如果响应时间小于10毫秒表示你网站上的一个良好体验,那么99%的用户都是这样的——但其中1%的用户没有。一旦意识到这一点,你就可以专注于解决造成那1%的性能问题。

让我们将其应用到之前的请求和响应时间图表,看看会发生什么。将75和99百分位数应用于第一个示例数据集,如图1-14所示。图1-14 响应时间的平均值、中间数和百分位数示例1

我们看到p75是5.5秒,这表明75%的请求在5.5秒内完成,25%比这个要慢,这与之前的分析基本相符。另一方面,p99为10.74秒,意味着99%的用户的请求响应时间少于10.74秒,剩余1%则超过10.74秒。百分位数展现了应用程序运行的真实情况。此外,我们还可以分析p75和p99的分布。如果我们很满意99%的用户获得10.74秒或更快的响应时间,而1%的用户比这更慢,那么我们就不需要考虑任何进一步的调整。而如果我们想要一致的响应时间,或者想要所有数据都低于10.74秒,那么现在便已经明确了可以跟踪、分析和改进的事务。在调整性能时,也能够看到p99响应时间的改善。

通过第二组数据可以看得更加清晰,如图1-15所示。图1-15 响应时间的平均值、中间数和百分位数示例2

从图中可以看出p75为10秒,p99为12秒,其中p99清晰地显示了响应时间的广泛分布,这更准确地反映了网站的运行情况。我们现在了解到(与平均响应时间相反)并非所有用户都感受到了优质的体验。我们可以使用此数据来识别可能需要改进的应用程序模块。

然而,百分位数并不是完美的。我们建议绘制几种指标组合,以获得更清晰的数据图。例如,在测量延迟时,最好可以展示以下几项内容:

·50百分位数(或中间数)

·99百分位数

·最大值

添加最大值有助于可视化所测量指标的边界,虽然它也不完美:一个较高的最大值可以使图中的其他值显得渺小。

当开始构建检查和收集指标时,我们会应用百分位数和其他聚合指标,这会在后续章节进行介绍。1.5 监控方法论

我们将在指标和指标聚合之上结合使用多种监控方法,以帮助加强监控。我们将结合以下两种监控方法:

·Brendan Gregg的USE(Utilization、Saturation和Error)方法[1],侧重于主机级监控。

·Google的四个黄金指标,专注于应用程序级监控。

监控方法提供的指导原则可以让你缩小范围并专注于所收集的海量时间序列中的特定指标。上述两个监控框架,一个侧重于主机级性能,一个侧重于应用程序级性能,结合使用可以获得一个相当全面的环境视图,帮助你解决任何问题。[1] http://www.brendangregg.com/usemethod.html。1.5.1 USE方法

USE是使用率(Utilization)、饱和度(Saturation)和错误(Error)的缩写,该方法是由Netflix的内核和性能工程师Brendan Gregg开发的。USE方法建议创建服务器分析清单,以便快速识别问题。

可以利用从你的环境中收集的数据,对照清单来确定常见的性能问题。

USE方法可以概括为:针对每个资源,检查使用率、饱和度和错误。该方法对于监控那些受高使用率或饱和度的性能问题影响的资源来说是最有效的。让我们快速查看每个术语的定义以帮助理解。

·资源:系统的一个组件。在Gregg对模型的定义中,它是一个传统意义上的物理服务器组件,如CPU、磁盘等,但许多人也将软件资源包含在定义中。

·使用率:资源忙于工作的平均时间。它通常用随时间变化的百分比表示。

·饱和度:资源排队工作的指标,无法再处理额外的工作。通常用队列长度表示。

·错误:资源错误事件的计数。

我们将这些定义结合起来创建一份资源清单,并采用一种方法来监控每个要素:使用率、饱和度和错误。它们是如何起作用的呢?假设我们有一个严重的性能问题,想深入了解以便诊断。参考我们的清单并检查每个被监控组件的各个要素。在这个示例中,我们将从CPU开始:

·CPU使用率随时间的百分比。

·CPU饱和度,等待CPU的进程数。

·错误,通常对CPU资源不太有影响。

然后是内存:

·内存使用率随时间的百分比。

·内存饱和度,通过监控swap测量。

·错误,通常不太关键,但也可以捕获。

其他组件以此类推,直到我们找到了问题的瓶颈或信号。

我们将在第4章看到更多关于系统级别的指标介绍。[1]你可以查看Brendan Gregg提供的Linux系统的参考示例清单。[1] http://www.brendangregg.com/USEmethod/use-linux.html。

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载