可观测白皮书 part1/2

此文为中文翻译，原文地址https://github.com/cncf/tag-observability/blob/main/whitepaper.md#executive-summary 第二篇为https://blog.csdn.net/qq_27749613/article/details/124231911

摘要

随着软件的复杂性及所处理的数据量的持续增长，我们需要可观测性技术来了解工作负载的状况。软件工程师除了要了解可观测性工具外，还需要了解如何监控和观测程序成为了共识。随着对服务等级目标的更高要求，这就需要软件工程师能够更快的找到造成服务异常的原因。
本文旨在带你了解云原生的各种可观测性技术。

简介

随着云计算、微服务、分布式系统的盛行，上云成为了越来的越多的程序的选择。尽管这一变化使得系统更方便扩展，拥有更好的性能也更加安全，但同时也更难控制基础设施。系统负责人、开发人员和运维必须了解线上程序以及底层基础设施状况，这就要求程序能够不借助其他手段能够被观测到运行状态，例如在源代码中添加新的检测或设置断点。
为了能够让不同权限的人员能够观测到程序的状态，程序就需要设计之初考虑引入哪种观测工具，然而从市面上选择各种各样观测标准的工具本身就是一件很困难的事情
根据ClearPath Strategies和Honeycomb.io对于的社区的研究表明，“四分之三的团队还没有完成或者尚处于可观测性的初级阶段”，并且“朝着实现更多可观察系统的转变动力很足”。虽然刚开始时是困难的，但是一旦达到某种令人满意的可观测水品有很多的好处。文化的改变，不同的工具，不同的目标，不同的方法。 如此多的细节需要考虑，这会让这段旅程变得相当混乱和痛苦。 本文的目的让更多的软件和运营团队能够了解可观测，运用它并获得利益。

目标听众

本文的目标读者是：

• SRE
• DevOps 工程师
• 系统负责人
• 软件工程师
• 基础设施工程师
• 软件开发人员

本文对那些希望交付在可靠性、安全性和透明度能够达明显的等级，能够集成客户现有的观测系统的可观测性软件的人员有所帮助。可观察性是一个多学科主题，因此组织内其他人员，例如负责设计和实施此类软件的项目、产品、项目经理和架构师，也可能对本文感兴趣。计算机科学、信息系统、工程（或相关）学生和对可观察性领域感兴趣的人也可以在本文中找到有用的信息。

目标

云计算能够帮助科技公司优化成本、规模和设计更高效的产品，同时也引入了（结构的）复杂性。由于基础设施现远程、短暂和全球分布的特性，使得系统管理员曾经对数据中心拥有的控制权丢失了。曾经那些管理人员和开发人员拥有不同kpi的公司也必须转变为构建可靠软件而共同奋斗的文化。目前已经有一些工具能够通过观测云原生系统的状态提升系统的可靠性。
在可观察系统的设计和开发过程中，必须对其进行检测以向第三方发送或公开遥测数据，通常是一组工具，负责从公开的数据中提供有意义的信息。遥测数据经常以metrics、logs、traces、structured events、profiles和dumps的形式呈现。每种信号都有其目的和最佳实践，它们的滥用可能会在大规模运行软件时导致新的问题，例如“告警疲劳”和“过高的成本”。尽管存在一些新的挑战，例如文化变革、产能规划、法律问题等，但其中很多已经被早期入局的公司所解决。初学者可以从他们的总结和错误中学习，并遵循最佳实践来解决同样的问题。本文包括可观察性信号之间的区别以及应如何处理它们，列出解决常见问题时使用的几种不同方法的成功案例，并介绍了几种可观察性的工具以及如何实现自己的