在 GlueCon 2015大会上的一场演讲中,Adrian Cockcroft为听众列举了如何对微服务与基于容器的应用进行监控的多条规则。除了这些指导方针之外,Cockcroft也着重强调了在监控cloud native并且基于容器的系统时所面临的一系列挑战,并介绍了一个由他设计的微服务模拟与可视化工具,名为“Spigo”,它能够帮助开发者对大规模微服务的监控进行测试。
Cockcroft 是来自于 Battery Ventures 的技术专家,他在演讲中首先列举了关于微服务与容器监控的一系列规则,这其实是于 Monitorama 2014大会上首次提出的规则的一个升级版本。
Cockcroft表示,这条新的规则,即“让指标与模型相一致”是必不可少的。因为基础设施、数据流以及自主权与组织结构等因素往往是互不相交的,只有将它们关联在一起,指标才能够表现出其意义。随后,Cockcroft将微服务定义为“一种由边界上下文组成的松耦合面向服务架构”,在此定义的基础上深入讨论了在监控微服务与容器技术(例如 Docker )时所面临的一系列挑战。
首先提出的一个挑战是“复杂性”,Cockcroft表示在一体性的应用程序内部的依赖是无限制的,比起具有明确的、可视的微服务依赖,其复杂性可能会高出许多,要检测出所有的外部依赖是一件非常困难的是。第二个挑战是“变更的速度”,它所表示的是在对基于容器的微服务应用进行持续部署时,可以实现的变更速率已经达到了相当的高度,这也带来了相应的问题:
对于容器应用来说,每分钟一次进行CPU占用率的检测已经失去意义了……从监控工具的角度来看,如何应对这种变更速率是一个巨大的挑战。
“大规模化”是第三个被提出的监控挑战,这里的规模不仅是指运行中的容器与机器的数量,还必需考虑到“ cloud native ”中的相关概念,例如 地区和可用性区域 。当然也要考虑服务本身的大规模化,以及可能会发生的多个版本的服务并行运行的情况。
Cockcroft还表示,“数据流”也是微服务架构中一种内在的挑战。虽然有某些工具能够跨多个服务展示请求流,例如Netflix的 Atlas (以及 相关的应用 )、AppDynamics的 应用性能管理工具 ,以及Twitter的 Zipkin ,但我们所关注的架构可能会包含多个微服务,这就意味着如何使这些服务做到可视化成为一个实在的挑战。
在微服务架构的应用程序中,产生“故障”的可能性是一个始终存在的挑战,而在云环境中,这一问题往往被进一步放大。举个例子,如果某个 可用性区域 出现了分区或故障,该如何在监控或分析平台中显示这一情况?按照设定,cloud native的应用在出现部分可用性区域故障时会继续运行,因此这种情况本身并不算是一种“故障”。但应将这一情况通知系统的运维人员,甚至可能需要停止应用的部署。
在这种情况下,如何理解、并且对微服务的故障模式进行交流,这一点正是挑战之所在。
对于大规模的微服务及容器监控工具进行测试的过程会很快造成高昂的代价,因此,对这一场景进行模拟是一种可行的方案。Cockcroft为听众介绍了他所设计的微服务模拟器 “Spigo”(又名“simianviz”) ,可以通过它对你所关注的微服务架构进行建模与可视化。
Spigo,或者说simianviz是一个基于Go与D3.js开发的应用程序,能够生成人为的测试微服务系统。它完全能够模拟大规模的系统配置,最终目标是能够支持对实际应用中的监控工具进行负载测试。此外,Cockcroft还计划让这套工具支持更多的特性,例如动态地变换代码提交以及配置的自动伸缩、支持Netflix用于处理区域及地区故障的 chaos gorilla 工具的建模,以及在Spigo(simianviz)的多个显示之间建立WebSocket连接。
这是我为你提出的挑战:用Spigo创建你的架构,让它对你的监控工具进行负载测试,并让它帮助你修复微服务的监控过程中的问题。
关于Adrian Cockcroft在GlueCon大会上所做的演讲,可以在 Cockcroft的SlideShare 帐号下找到更多的信息与幻灯片。此外还可以在GitHub上找到 Spigo或simianviz 的源代码。GlueCon是一个一年一度的开发者会议,它专注于云计算、DevOps、移动、API与大数据,可以在 GlueCon 网站上找到更多的信息。
查看英文原文: Monitoring Microservices and Containers: A Challenge by Adrian Cockcroft