Skywalking 可扩展的观测
原文地址
http://skywalking.apache.org/blog/2020-08-11-observability-at-scale/
SkyWalking不断发展以解决观测的可扩展性问题，并从纯跟踪系统发展为功能丰富的观测平台，该平台现已用于分析每天收集数百亿次跟踪的大型系统。
SkyWalking，Apache的顶级项目，是用来解决21世纪那些增长迅速、分布式、异构化系统的问题的开源APM和观测分析平台。为了解决当前系统管理员碰到的问题：在大量相互依赖的服务中识别和定位针，在多语言应用程序之间获取“Apples to Apples”指标，以及获得完整而有意义的性能视图。
译者注：apples to apples 意思是有意义地比较，比如将HBase和Sqllite进行比较，几乎没有意义
SkyWalking是一个整体平台，可以观察网格上或网格外的微服务，并可以使用轻量级负载提供一致的监视。
设计可扩展
当SkyWalking于2015年首次初始化时，其主要用例是监视中国顶尖电信公司，中国联通和中国移动的第一代分布式核心系统。 在2013-2014年间，电信公司计划用分布式系统替换其旧的传统单体应用程序。 从第一天起，支持超大型分布式系统和可扩展性便是高优先级的设计目标。 那么，可扩展设计中的核心是什么？
推还是拉
推模型或者拉模型跟数据流相关。如果agent收集数据并且将数据推送到后端进行后续分析处理，我们叫做推模型。关于推模型和拉模型的争论已经持续了很长时间。对观测系统来说，重要的是最小化agent的消耗，可适配不同类型的观测数据。
收集数据后，Agent会在短时间内将数据发送出去。这样，我们就不必担心本地缓存过载。一种典型的情况是Endpoint（HTTP的URI，gRPC的服务）的metrics。任何服务都可以轻松拥有数百个甚至数千个Endpoint。 APM系统必须具有这些指标分析功能。
此外，metrics并不是观测领域中唯一的事物。 跟踪和日志也很重要。 SkyWalking旨在在生产环境中提供100％的采样率跟踪功能。 显然，推送模式是唯一的解决方案。
同时，本机使用推模式并不意味着SkyWalking不能进行数据提取。 在最新的8.x版本中，SkyWalking支持从Prometheus仪表支持的服务中获取数据，以减少最终用户的非重复工程。 同样，拉模式在基于MQ的传输中很流行，通常作为Kafka consumer。 SkyWalking agent 使用推模式，而OAP服务器使用拉模式。
结论：推模式是原生方式，但是拉模式在某些特殊情况下也适用。
译者注：推拉模型还跟您的网络规划息息相关，如果您的Skywalking服务器没有和服务面对面网络打通，那么拉模型几乎不可能实现
监控指标分析不仅仅只是数学计算
度量标准依赖于数学理论和计算。 百分位数是识别长尾问题的好方法，合理的平均响应时间和成功率是良好的SLO。 但是，这些还不是全部。 分布式跟踪不仅提供具有详细信息的跟踪，而且还提供可以分析的高价值指标。
Ops和SRE团队需要提供服务拓扑图，以用于NOC仪表板和确认系统数据流。 SkyWalking使用STAM（流拓扑分析方法）从跟踪分析拓扑，或者在服务网格环境中基于ALS（Envoy 访问日志服务）进行分析。 无法从简单的指标SDK提取节点（服务）和线路（服务关系）的拓扑和指标
与解决Endpoint metics收集的限制一样，SkyWalking也需要从跟踪数据中进行端点依赖关系分析。 端点依赖性分析提供了更重要和更具体的信息，包括上游和下游。 这些依赖关系和度量标准可帮助开发人员团队将性能问题的边界定位到特定的代码块。
预计算还是查询阶段计算？
查询阶段计算更加灵活。在分析阶段进行预计算，提供了更好更稳定的性能。再次申明一下设计原则：Skywalking面向大型分布式系统。查询阶段的计算范围非常有限，并且大多数指标计算都需要预先定义和预先计算。 支持大型数据集的关键是在设计级别缩小数据集的大小。 预先计算允许将原始数据合并到下游的汇总结果中，以用于查询甚至进行警报检查。
指标的TTL是另一个重要的业务推动因素。 由于预计算可以使查询提供近乎线性的性能，并且使用类似的查询基础结构，组织可以提供更高的TTL，从而提供了扩展的性能可视性。
说到警报，查询阶段的计算也意味着警报查询需要基于查询引擎。 但是在这种情况下，当数据集增加时，查询性能可能会不一致。 进行指标查询也是一样的（也会不一致）。
今天的案例
如今，SkyWalking正在监控许多大型企业中的超大规模分布式系统，其中包括阿里巴巴，华为，腾讯，百度，中国电信以及各种银行和保险公司。在线服务公司的流量比传统公司（如银行和电信供应商）更多。
SkyWalking是可观察性平台，用于分布式系统的各种用例，这些用例在许多方面(注：如规模，语言等)都非常大：
- 拉勾网，在线求职平台
- SkyWalking监控超过100个微服务，500多个jvm实例
- SkyWalking每天收集和分析四十亿条跟踪，以分析性能数据，包括30万多个端点和依赖项的指标
- 整个集群超过50000消息每秒
- 永辉超市，在线服务
- SkyWalking每天使用指标来分析至少百亿+（3B）跟踪
- SkyWalking的第二个较小的部署，每天分析2亿+条跟踪
- 百度，互联网AI公司，k8部署
- SkyWalking每天从提供120多种服务的1,400多个Pod中收集1T +跟踪
- 随着更多服务的添加，规模继续扩大
- 贝壳找房
- 从一开始就使用SkyWalking，并且在PMC团队中有两名成员。
- 部署每天收集16+亿条跟踪
- 阿里云霄（Ali Yunxiao），阿里云上的DevOps服务
- SkyWalking每天收集和分析数十亿个Spans
- SkyWalking使AliCloud的45个服务和约300个实例保持稳定
- 最大的企业对消费者在线零售商之一阿里巴巴天猫的一个部门，从淘宝网分拆出来
- 定制版本的SkyWalking每天监控数十亿次跟踪
- 同时，他们正在利用SkyWalking的代理技术堆栈构建负载测试平台，并利用其跟踪和上下文传播功能
总结
SkyWalking的观测方法遵循以下原则：
- 理解逻辑模型：不要将可观察性视为数学工具。
- 首先确定依赖性，然后确定其指标。
- 扩展应该轻松而原生地完成。
- 保持不同体系结构之间以及APM本身性能的一致性。
