本文将讨论可观察性和监控之间的区别,如何观察不同的系统,以及罗列一些能够提高可观察性的开源工具。
*本文来源于TARS Ambassador Isabella Ferreira文章:《The Future of Cloud-Native Observability and 5 Open Source Tools to Help You With Cloud-Native Observability》
由于云应用程序的复杂性和处理数据量的增加,监控和管理应用程序的传统方式变得不再高效。为了解决这个问题,可观察性(Observability)被引入到IT行业。可观察性是指根据系统展示的外部数据了解系统内部发生的事情的能力[1]。通过可观察性,软件开发工程师可以通过监控云中的服务器、容器和数据来发现出现问题的根本原因,并能及时分析和修复问题。
总的来说,可观察性是一种深入了解云环境性能的新方法。可观察性可以由不同的表层数据来推动,例如来自应用程序运行环境的软件和基础架构的日志、追踪和指标,以及来自 CI/CD 管道和帮助台等互补系统的数据[1]。当此类数据相互关联时,可观察性可以帮助发现商业洞察并满足业务目标。此外,当可观察性与 DevOps 文化相结合时,当今云应用程序中最棘手的问题也可以被解决。
根据前文的描述,可观察性与监控似乎是无区别。事实上,监控是推动可观察性的一个过程,但可观察性远不止于此。监控仅使用表面数据来传达问题表面上发生了什么。监控并不能帮助您了解系统的内部状态,但可观察性可以。
对于解决简单的问题,表面数据可能就足够了。例如,如果某个应用程序由于托管它的服务器完全失败而停止响应,那么只需要基本的表面数据即可找出问题所在 [1]。但是,假设有一个没有响应的应用程序并且托管该应用程序的服务器确实发生了故障,但编排器自动将该应用程序移动到集群中的另一台服务器。在这种情况下,发生故障的服务器不再是问题的根本原因。相反,这是应用程序本身的编码问题,它也许存在内存泄漏,最终会导致任何托管它的服务器出现故障。在这种情况下,软件工程师需要关联来自各种来源的数据来找出问题所在,例如应用程序日志、操作系统日志、CI/CD 管道数据等,然后找出哪个 CI/CD 部署引入了泄漏并追溯至导致问题的代码变动。
不同的系统需要不同的可观察性策略。本文将集中探索以下三种不同类型的系统 [1]:
可以帮助促进可观察性的工具包括:
不同的框架可以帮助集成上述工具。例如, TARS 微服务框架不仅可以帮助开发人员构建他们的微服务,还可以为微服务集成可观察性工具,大大提升应用程序的可观察性。其他框架,例如Istio服务网格。也能够集成不同的可观察性工具。
参考文献
[1] https://www.observeinc.com/resources/what-is-observability/
[2] https://newrelic.com/blog/best-practices/what-is-cloud-native-observability#:~:text=Observability%20is%20defined%20as%20your,data%20processes%2C%20and%20hardware%20processes
TARS基金会是Linux基金会下的非营利性、微服务基金会,致力于建设一个强大而灵活的微服务生态系统。无论你在哪个行业,无论你使用什么技术栈,这里能助你快速实现你的创意。