[关闭]
@lsmn 2017-11-21T09:12:36.000000Z 字数 1498 阅读 2376

可观测性与原生云监控

云计算 Kubernetes 容器 服务网格


摘要

在近日发表的一篇文章中,Cindy Sridharan概括介绍了可观测性及其与原生云应用程序监控的关系。可观测性是一种理念,包括监控、日志聚合、指标和分布式跟踪,可以实时更深入地观察系统。

正文

在近日发表的一篇文章中,Cindy Sridharan概括介绍了可观测性及其与原生云应用程序监控的关系。可观测性是一种理念,包括监控、日志聚合、指标和分布式跟踪,可以实时更深入地观察系统。

Sridharan的文章基于她就同一个主题所做的Velocity演讲。随着微服务、云和容器化架构的出现,我们构建系统的方式变了。在后一种情况下,应用程序是分布式的,而且瞬息万变。底层的基础设施和网络服务愈加健壮,应用程序层需要跟上技术的发展步伐。将来,大多数的故障都将来自应用程序层或者是不同应用程序之间的复杂交互。

这种复杂性增加了把系统状态可视化的难度。虽然出现了新的工具,但尚处于发展阶段。Sridharan探讨了可观测性的概念以及如何选择恰当的工具洞察现如今的系统。

可观测性是一个最近几年开始在监控社区流行的术语,然而,它并不是一个新事物,而且似乎和它真正的意思有些出入。据Sridharan之前的文章,可以将可观测性视为监控的超集。Twitter工程团队的文章将可观测性总结为监控、预警/可视化、分布式系统跟踪、日志聚合和分析。谷歌致力于简化工具,降低数据聚合成本,标准化整个栈的格式和框架,从而便于跟踪。谷歌最上层的抽象是上下文传播,他们针对每一种语言提供了一个库,或者使用该语言的内置特性。上下文用于在整个栈中传播被称为标签的键-值对,后续可以把它们用于过滤特定的请求。

预警和统一管理面板是监控的组成部分。按照Sridharan的说法,可观测性是所有这些再加上(应用程序)性能分析、调试和依赖分析。与监控不同,可观测性和数据挖掘有关,是为了寻找问题的答案,简化信息的访问。监控和故障检测有关,有定义好的故障路径。随着故障模式的增加,确定真正的原因变得非常困难,这是由日益复杂的架构所导致的。而后者已成常态。定义可观测性有不同的方法。例如,白盒监控是指,有一个数据源,可观测性可以视为从数据中挖掘相关信息的能力。

日志、指标和请求跟踪是可观测性的基础。日志为数据(如指标)提供额外的上下文。不过,日志对性能的影响也很大。相比之下,指标的开销是不变的,而且有利于预警。总而言之,日志和指标可以为观察单独的系统提供方便,但是对于穿过多个系统的请求,很难提供其生命周期的信息。跟踪提供了跟踪在各个系统之间传递的请求的能力。后者很难实施,一个原因是应用程序使用的第三方库也需要检测。抽样被用于减少跟踪的开销和存储成本。这里的抽样是指减少收集的信息的数量。其中,磁盘配额及动态调整日志生成速度就是日志记录的一些最佳实践。

关于跟踪技术的发展近况。谷歌发布了Dapper论文,Open Zipkin是以此为基础的开源实现,并导致OpenTracing标准的产生。如果应用程序使用了类似Envoy项目这样的网格技术,跟踪就简单些。服务网格是一个位于TCP/IP层之上的网络基础设施层,可以处理可靠请求交付,有时候也实现为一系列网络代理。它简化了动态环境中的服务通信,如使用Kubernetes编排的容器集群。

在原生云环境中,软件开发和交付可以从采用类似预生产测试、生产测试、有效监控、原始数据(如指标和日志事件)挖掘和动态检测这样的实践收益。

查看英文原文:Observability and the Monitoring of Cloud-Native Applications

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注