可观察性发展背景
可观察性的概念起源于工业领域,在该领域中,可观察性被定义为从系统外部输出推断系统内部健康状态的能力。
随着软件架构的巨大变化(主机模式 → C/S架构 → J2EE → SOA → 微服务 → 基于容器的服务 → 容器编排),开发、迭代、交付的效率得到了很大提升,同时系统的监控和排障越发困难。当系统环境像当下一样复杂时,仅监视已知问题已经无法解决不断增加的新问题。这些新问题是“未知的未知数”,没有人知道导致问题出现的原因,也没有标准化的起点或图表来帮助查找,即使是经验丰富的驻地运维专家也无法每一次都精准预测和解决在现代生产软件系统中可能出现的紧急故障。
Twitter工程师 Cindy Sridharan 在2017年发表的《Monitoring and Observability》一文中,首次将 Observability 一词带入开发者的视野。在Cindy Sridharan 提出可观察性之前,谷歌著名的 SRE 体系就已经为可观察性奠定了理论基础,也就是说在微服务、可观察性等概念出现以前,业内通常称之为监控。其中, Google SRE 特别强调白盒监控的重要性,而将当时技术圈常用的黑盒监控放在了相对次要的位置,而白盒监控正应和了可观察性中“主动”的概念。
在软件产品和服务领域,可观察性是指在不部署新代码的情况下,能够理解和解释系统可能进入的任何状态的能力,企业需要能够提供可观察性能力的产品,因为系统的复杂性已经超出了人为可预测的范围。
简单地说,可观察性就是从应用系统中收集尽可能多的遥测数据,以便可以调查和解决新出现的复杂问题,确保企业能够主动观察系统,在影响客户体验之前解决故障及问题,安全地进行测试并实施优化,更好地管理和控制业务风险。
可观察性可以被视为系统的一个属性,与功能性、安全性相似。
可观察性与监控
可观察性与监控经常被混淆或互换,因此有必要比较两者的异同。
监控接收告警,同时反馈系统的正常工作的部分。
可观察性则是更侧重于系统停止或减慢工作的原因。
如上图所示,传统的运维可能只能展示最顶层的“告警”和“概况”,当应用系统宕机时,运维需要更深层次的错误信息排错,则需要收集更多信息,利用动态分析手段去查明服务状态及之间的关联关系。
可观察性三大支柱
可观察性是由日志、指标和链路跟踪三大支柱构建的,即遥测数据可以精简为日志,指标和链路追踪。
以上三种形式的组合使用将会产生丰富的观察数据,日志易由此推出了国产可观察性监控平台——观察易。
观察易,日志易可观察性监控平台
观察易是一个基于日志易平台,从业务-服务-接口-设备四层维度对应用系统进行分析的可观察性监控平台,接入基础监控指标和业务分析日志数据后,通过梳理业务层面的依赖关系,展现出全面准确的可观察性内容,帮助客户了解并实时监控应用系统运行状态。
观察易加强了日志、链路、指标的三大可观察性支柱间的关联,从而缩短了发现并解决问题的时间。
应用场景:
在“业务至上”的互联网时代,DevOps需要持续监控业务状态,当故障发生时需要快速找到根因并进行修复。观察易能够从业务维度对业务的平均耗时、请求量、错误数、成功率四个黄金指标进行监控,也可以从服务和接口维度对业务的整体状态进行分析。另外,观察易也提供和业务无关的服务监控、接口分析和设备监控,实现更全面的系统可观察性。
伴随企业IT由传统架构向分布式微服务架构转型,复杂单体应用被拆分为多个轻量级服务。由于服务间的独立性,一笔业务会涉及到多个微服务系统。观察易可对接trace日志,实现业务链路追踪,通过观察易的拓扑图、历史回溯和指标趋势图了解业务详情,快速定位故障,让IT运维人员更准确、高效地掌握微服务环境下业务的运行状态。
从业务、服务、设备角度来说,侧重的是黄金指标可观察性,如果需要关联黄金指标对比观察或需要关注黄金指标以外的其他指标时,运维人员可以使用观察易的指标探索功能对时序数据进行单指标多维度(平均值、最大值、最小值等)或多指标多维度查询、分析并实现可视化。
观察易能够提供标准的起点或图表来帮助运维人员查找问题,分别从业务-服务-设备的概览追踪到其详情,进而结合调用链的span信息或其他日志信息定位到故障原因。
实现价值:
l 更快地发现问题,以便尽早控制并发出警告
l 更好地追溯问题根源,从源头保证系统可观察性
l 更实时的反馈,以便更快采取措施进行修复
l 更准确、更紧密的事后审查和检查,便于制定更全面的应急预案
l 更智能的数据分析和机器学习,更高效地预测并阻止问题发生
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。