助力降本增效, 新东方可观测体系标准化改造

如何获得讲师PPT：

扫码关注公众号，后台回复「0111」即可获得讲师PPT哟～

还能一键订阅后续精彩活动内容～

Q&A环节答疑：

1、业务信息如何告警关联？

我们的业务信息跟之前阐述的点紧密相关，主要围绕应用CMDB的属性。首先，这是一个前提和共识。这些数据涵盖了从业务线到最小单元的所有内容。在更高级别的业务线中，例如ERP服务、数据服务和具体的购物车应用，这些都构成了业务线、业务和应用的三级区分。应用CMDB的共识是，一个应用下联了哪些组件，包括DB和容器，这是基本前提。

关于如何告警关联，我们主要依据上述数据。比如，应用连接的主机或容器，它们拥有关联信息。完成关联信息后，报警项中会包括容器pod的信息。我们将这些pod信息与应用的关联信息进行映射。同理，其他信息如业务线、业务应用、运维人员、项目人员和邮箱等也可以进行类似处理。中间件也是如此，例如应用下的中间件与DB实例的关联。当报出应用实例的DB信息时，还会包含主机IP和库名等细节。

有了右侧的散点数据和从应用CMDB中关联的上层应用数据，我们就可以进行映射操作。这就是整个流程。

请问改造过程中的监控数据，是怎么处理的？完整性一致性这些会受影响吗？

从我个人的解读和解答来看，处理过程可以分为前期、中期和后期。前期主要是确定要收集哪些数据，比如我们需要丰富关于混合云的现状的数据。混合云的数据，我们会通过telegraph的方式，手动录入云上和云下的数据。云上的数据，我们可以直接从普罗斯的服务获取，而云下的数据，我们会通过原本的telegraph数据推送到指标存储里。

对于日志的处理，这些日志主要是业务研发的，我们会结合二开的日志采集方式进行整体汇聚，同时加上应用CMD的标签。在应用上线和标准化便利化的过程中，我们会做整个的汇聚展示。

基于trace的处理，我们结合了两点。一方面，我们通过trace获取了一些RED的关键性数据，然后通过接口生成指标并打上应用的标签，汇入到指标里。另一方面，基于traceID的方式，我们会进行trace和日志的联动展示。

中期的话，我们会做一些应用CMDB的加工。这些加工点很关键，主要围绕应用CMDB打标签。有些标签可能是自动的，但有些场景可能需要手动打标签。手动打标签可以由SRE或研发人员通过我们的平台进行增加。

后期的话，主要是对监控数据的处理，包括一些大的联动和报警。报警主要是做汇聚和展示。

关于完整性和一致性，从我们的角度来说，我们覆盖了能想到或应用角度能使用的完整数据。对于使用场景，我们结合了应用和DB，将其一致归为业务属性。

日志改造这块，会不会影响到原来的日志分析和可视化工具？

关于日志分析的影响，我分为两个环节来回答。首先，对于业务级的日志，我们使用ES进行处理。选择ES的原因在于大家对其的依赖程度和对其中功能的依赖。推动这一过程的前期，需要大量的投入，因为大家对ES的熟悉程度较高。我们通过标准化方式采集并录入ES，将原本的报警信息引导到我们的监控平台。监控平台与VC兼容，具有可观性和可配置性，无需编写复杂的watcher规则即可完成报警和钉钉的展示。这是我们在ES场景中的观点。

另外，对于一些业务研发背景或使用习惯，他们仍然需要在ES中使用。为了减少与业务可能无关的基础设施相关的日志，如卡夫卡等，我们将它们从PS汇聚到Locky中。使用Locky的优势在于其低的学习和使用成本。通过Locky的存储方式，我们减少了ES的使用量，实现了降本增效的目标。

ES和Loki之间的数据迁移或者同步，这个怎么兼顾？

关于ES和Locky之间的数据迁移和同步，我之前也稍微提到了。对于Locky的定位，一是作为我们原本通过SMP输入到文本方式的监控数据的接收器，以减少对ES的依赖。二是为了减轻ES的存储压力和性能问题，包括成本和人维护的压力。

对于Locky的使用，我们并不希望研发团队投入大量精力，因为相对于其使用成本来说，效益可能并不明显。此外，与ES相比，Locky主要用于处理轻量级日志。经过对比，它在处理业务日志方面不如ES强大。因此，我们将Locky定位为减少对ES日志量的依赖，并作为telegraph的输出源，收集和标准化一些基础硬件的监控数据。

至于ES，我们保留了之前的使用场景，尤其是在前置采集和处理lostash方面的工作。

thanos 和 vm切换 为什么需要切换，有压测对比过吗？

我们之前做过几个性能对比的测试。首先，在存储效率方面，VM有自己的数据压缩算法，从而减少了数据存储量。相对于S来说，VM的日志使用量减少了四分之一，因此VM在存储效率上比S表现得更好。

其次，从查询效率上看，VM因为采用本地存储的方式，比远程加载的网关方式更快。对于常见的查询模式，我们也进行了一些优化。

第三，考虑到人维护的成本，VM的组件相对较少，而在onK八S场景中，需要安装多个组件和虚机，这增加了维护的复杂性。相比之下，VM提供了简单的二进制文件，部署和维护相对简单。在压力测试中，VM的系统表现得更加稳定，部署架构也相对简单。

最后，关于拓展性，我们认为VM的设计更偏向于系统级的拓展。对于横向扩展的能力，VM的可扩展性直接且快速。

综上所述，基于存储效率、查询效率、组件复杂性以及拓展性等方面的考虑，我们认为使用VM取代S是一个更好的选择。

指标采集数据量和搭配VM的资源配置使用占比是大概是多少？1T的采集数据对比VM使用的CPU和内存。

对于VM的使用情况，需要根据具体场景进行分析。从现有的指标采集数量来看，我们目前存储了400天的数据，并采用滚动删除的方式。VM目前使用的存储空间大约为20T，这是基于我们现有的数据体量。

由于我们使用的是共享存储，VM的部署架构也涉及到三节点资源的使用，这些资源包括物理机。根据对比，如果我们使用三台32和64G的服务器存储数据，采用safeFS文件存储方式，400天的数据量大约需要20T的空间。

关于VM的CPU和内存使用情况，我们没有详细对比过一个T的数据。但就20T的使用场景而言，常规情况下高峰期和低峰期并存。高峰期主要在白天，因为涉及到ruler规则的查询和一些写入操作。随着数据量的增加，写入操作也会增加。查询效率方面，白天的使用量会更多。根据我们的计算，CPU在查询20T数据时大约占用20%左右。内存方面，由于VM使用的是二进制文件，其内存使用量大约在60%左右。

目前的使用场景是，我们之前做过一次迁移，原本使用VM虚拟化，分配了32和32G的服务资源，但由于共享存储涉及到CPU征用问题，后续我们计划将其迁移至物理机上。

vm有遇到merge场景吗？以及有涉及vm冷热分层？

我们目前有20T的数据量，使用场景主要包括merge。到目前为止，我们尚未遇到merge场景的问题。然而，之前我们遇到了CPU使用不足的问题，因此决定将其迁移至物理机。至于冷热分层，我们目前是基于safeFS进行存储，使用的是其本身的性能，因此并未遇到相关情况。

老师，请问一下业务监控大盘涉及到项目组改造吗？如何实现业务监控大盘这块的一些内容？

在之前的分享中，我提到不需要业务改造的原因在于我所分享的大部分内容都是关于基础设施和SRE层的改造。在我们公司，让研发过度参与可能导致项目难以推进和落地。因此，我们目前对监控大盘的改造并不涉及研发的投入。我们主要处理前期数据和应用CMDB的加工，然后根据需要将大盘分为几个级别，其中一些大盘涉及应用健康评分的规定。这些东西的协调和联动需要与研发部门合作，确保他们使用这些工具和数据。一旦应用CMDB和数据被打通，出单和报告就会很快完成。许多标准化的数据都是基于json格式。例如，面向业务线的健康评分或属性大盘，我们都有模板化的内容，基于业务线和人员，可以自动生成图表。每个人基本上只能看到自己业务线和索塔管辖的内容。

改造过程中，对已有服务的代码改动大吗？怎么评估这些改造对性能的影响？

在我们的改造过程中，我认为有两个方面需要考虑：一是我们自己整个监控平台体系的改造成本，二是研发部门在接入时的改造成本。

首先，对于我们自己的监控平台体系，改造成本主要来自于两个方面：一是采集端的代码改动，二是报警或监控平台的配置和告警管理。在采集端，我们需要结合三个场景进行开发，如针对SMP的采集、组件采集等。虽然改动量较大，但性能影响并不明显，因为这是从零到一的开发过程。在报警或监控平台的配置和告警管理方面，我们结合夜鹰进行改造，主要涉及登录安全、日志告警和ES告警等能力的开发。此外，还需要考虑如何将配置与一些transforming tag结合使用。

其次，对于研发部门的接入，改造成本也主要来自于两个方面：一是D的展示和开发，二是已有服务的代码改动。对于D的展示和开发，我们基于应用CMDB的场景和标签进行改造，如将其打造成具有业务属性的数据。然后基于模板进行创建和维护，包括从零到一或从一到二的后期维护，以便更好地进行开发定制。对于已有服务的代码改动，我们认为改动量不大。这是因为我们很多工作都是无侵入性的，不会对研发部门的使用习惯和采集造成影响。

综上所述，我们的改造过程主要关注于我们自己的监控平台体系和研发部门的接入成本。在改造成本方面，我们注重无侵入性的开发和后置运维层面的工作，以减少对性能的影响。

灭火健康度这块儿，你们重点关注的关键性指标有哪些？

对于整个可观测性的问题，我想简单概括一下。提升可观测性相当于给我们的系统装上了“眼睛”，监控和可观测特性能够展示MTTR的显示时间和处理时间。目前，我们的响应时间已经做到了三分钟内，但还未达到“1-5-10”的标准。为了实现有效报警，我们结合了服务拨测的电话报警，确保报出的信息是有效的，并完成整个链条的处理。

与之前相比，MTTR的响应和处理时间的提升在SRE管理过程中明显反映出来，特别是SRA的提升。原先的TOB场景SRA是99.90，而TOC场景是99.93。经过一两年的努力，我们现在TOB场景的SRA提升到了99.95，TOC场景更是达到了99.97。这充分体现了我们效果的体现。

接下来是第二个问题，关于灭火健康图的关键指标。我们主要关心的指标是RED指标，包括requesterror和延迟等，这些代表了应用的属性。结合不同服务和场景，我们将不同的应用进行关联性评估。在评估过程中，我们关注模板化的东西，按照水桶效应的最低评分原则，即一个服务内的应用最低评分代表该服务的健康状况。此外，针对不同场景，我们配置了不同的百分比，关注服务前置和后置，以及一些熔断场景的配置。

在决策灭火图中，可以根据健康度数据进行问题排查和定位问题影响的具体服务吗？具体怎么操作？

关于灭火决策的问题，SRE场景和业务场景的处理能力和关注点确实存在差异。首先，我们需要实现监控数据的标准化，然后通过灭火图来定位问题和影响。例如，在PPT中展示的ERP服务得分为75分，虽然它被认为是可用的，但我们需要追踪并发现其中的痛点问题，进行具体的排查。具体来说，如果某个应用得分较低，如75分，我们可以追踪并找到具体是哪个应用影响了整体得分。通过这种方式，我们可以了解常规请求的显示时间、延迟、吞吐率等指标，然后进行具体的排查。

从研发的角度来看，他们通常会从一个服务的角度或应用的角度去排查问题。而从运维的角度来看，我们可能知道某个服务出了问题，然后跳转到trace或日志进行具体的排查，确定是单个问题还是服务本身的后端问题。

此外，结合关键性指标和报警能力，我们只关注关键性报警，并不会报出一些后置的DML操作或变更操作。我们会结合事件管理的能力，通过上层的关键性报警和灭火，进行具体的渗漏排查。这样，我们可以了解这段时间内发生了什么事情，并进行具体的排查。

哪些日志数据适合入loki？哪些适合入ES？

关于Locky的使用，在上一页的回答中已经提到了一些信息。Locky是一个轻量级的日志查询工具，如果业务量不大，可以考虑使用Locky。从技术角度来看，Locky适用于批量级日志查询。在使用场景上，它通常基于专建或中文件，以及我们的访问日志。

然而，对于我们的大部分业务场景来说，问题主要在于业务对ES的依赖和习惯性操作。长时间以来，他们已经习惯了使用ES，如果要引入一个新的查询方式，如Locky，他们可能不太适应。这是基于我们当前场景的现状来考虑的。

loki查询性能好吗？做过哪些优化？日志体量大性能会跟不上吧

确实会。Locky是一个轻量级的日志工具，采集方式是通过prompt来完成。它主要将数据存储在S3对象存储中。与ES相比，Locky在性能方面相对较慢，无论是从采集还是处理能力上来说。对于水平扩展能力，需要增加多个节点来提高性能。

对于主要业务场景，我们不建议使用Locky。Locky的使用场景主要结合了运维监控日志的能力，虽然它提供了一个高效的日志查询方案，但仍然受到数据规模、查询复杂性、硬件等因素的影响。因此，需要根据自己的业务场景进行选择，辨别是否适合使用Locky或ES。

针对 告警 分级通知，老师有没有什么实践的经验可以分享?

PPT中提到的告警和分级通知，我认为可以分为两个方面。首先，我们需要结合告警本身的能力，对一些关键性信息进行降噪处理。这可能涉及到基于原有标签打的一些标签项。其次，我们需要将不同的告警信息分发给不同的人员，这是第一个方面。

第二个方面是结合告警能力，将一些告警信息转化为电话、短信、钉钉消息等不同的通知方式，以便及时呼出一些体制。

总的来说，告警和分级通知的目的是确保关键性信息的准确传递和及时响应，以便更好地管理服务和应用程序。