作者：沐泽、晟柏
本文根据沐泽、晟柏的直播整理汇总整理，课程地址：https://developer.aliyun.com/learning/course/900
基于Elasticsearch的日志全观测最佳实践文档地址：https://bp.aliyun.com/detail/237
运维这个话题已经不陌生了，在运维的过程中，一方面会面临大量系统的数据，这些数据分散在很多系统和部门，甚至包括系统中的各个模块，对这些繁杂的数据进行统一的运维和分析，是相对困难的。
在整个开源的生态中，做运维和可视化分析会用到多个厂商的工具，将多个工具之间进行打通，再进行统一分析是相对比较难的，还需要去做比较多的自行开发和配置。
另一方面是有很多的数据需要做日志的分析，也需要很多的指标数据来告知系统中哪一些指标出现了一些异常和问题，但这个时候很多数据（日志和指标）表现的问题都是比较片面的，而故障却是相对立体的，所以运维需要的是能够去通过某一个时间点的一些日志和指标数据进行关联的分析，去发现问题。
如果只是对数据进行收集，没有进行真正的深入分析，那么传统运维能够发挥的价值是比较小的，整个运维的带来的一些收益也是相对比较低的。
那么什么是全观测呢？全观测是对传统运维的一个改进，它将日志指标APM等数据汇总到统一的平台上，让研发、运维、业务人员等在上面对所有的数据用一个统一的视角去做一个综合的分析，来看看整体有什么样的问题。
这样的好处是什么呢？
第一，有一个统一的可视化的报表，能够对所有日志的时间做一个对齐，能对所有日志设置一个相同的过滤条件。来看看那时刻到底发生了什么。
第二，所有的数据在统一平台后可以基于所有的数据设置统一的报警规则和监控。
第三，可以进一步的对数据进行尝试。因为数据量足够多，足够丰富，因此可以利用这些日志数据来做相应的机器学习方面的尝试，利用机器学习的能力来实现智能告警智能监控的能力。
下面主要讲下如果要实现整个全链路全观测，会有哪些技术难点，以及云上是如何解决这些问题的。
第一个难点是指标和日志获取比较难。
因为企业的机器、业务系统、网络环境等都有可能不同，并且分布在不同的云厂商下，甚至有的客户可能是在自己的IDC 里还有一部分数据。这样会存在多种指标，每个日志的采集手段又是不一致的，很难用一个统一的平台把它落地下来。
云上提供的Elasticsearch+Flink的全观测能力解决方案，可以完美的解决这个问题。主要是有Beats这样一个这样一个agent， 区别于开源的这个agent有很多的商业增值在里面，可以很轻量的去获取到各类的metic、logs、APM数据采集能力。
第二难点在自建系统中，如何对日志、指标等做出相应的规格归一化和格式化。
在统一的平台上做数据分析，肯定是希望所有的数据是规整的，这样更方便获得比较好的分析结果。因此需要上下游链路整体要做相应的配合，然后能从海量的数据中把有效的数据打捞上来。
企业在线下操作统一是比较困难的。在云上的话，可以依托于实时计算Flink版这样一个流式计算的能力，把上游的所有数据统一送到实时计算Flink版里面，在利用实时计算Flink版 本身的SQL 能力，因为Flink SQL 能力更适合于ELK的场景，对数据做一些简单的transform 和一些转换的时候，会更好用。
一般BI 的同学可以直接用Flink SQL来对数据做相应的清洗工作，那么基于Flink SQL这种完善的流式处理语义，可以支持各类网络格式日志数据采集到的数据的归一化，整体会非常的轻便。
在完成了整体的日志，包括指标数据等的采集和格式化后，可以将数据整体写入到存储引擎和计算引擎中。一方面日志的流量，包括数据的流量是非常高的，这时候高并发的写入往往会给整个系统带来比较大的压力，对整个业务系统，包括整个日志系统的稳定性来说，也是相对会比较差的。如果是在自建的过程中面对这样一些稳定性的问题，往往需要付出大量的人力或者是系统的运维成本去解决。
目前在阿里云提供一套基于Indexing service这样的自研ES 写入托管服务，可以更好的依托云上海量的计算资源，解决高并发写入的峰值流量的问题，从而来保证整个系统的一些稳定性。
与此同时阿里云还有很多云上托管ES 的一些跨机房部署、同城容灾、场景内核优化等功能，以及一些包括限流的插件来去保证整个这样一个系统的稳定性，提供整体的全观测服务的服务的能力。
在整个日志场景下面，会有面对海量的数据的存储问题，数据会有比如长短期存储等为了审计的数据存储需求，数据量往往都是TB ，甚至是PB 以上的，而面对这样一些海量数据存储的需求，在阿里云上能够有比较好的支持。
阿里云ES提供冷热分离数据存储方式，可以对相对一些短时间的数据去进行热规格的配置，然后去对一些长期的数据去使用自研存储引擎，包括Openstore存储能力来去提供更低成本的数据存储，这样的一些数据存储还是surveillance 化的，完全去按照实际存储量收费，不需要去提前购买一些磁盘空间和容量。阿里云还有很多包括存储的压缩算法来提供整个日志场景更高的一些压缩比，从而进一步降低整体的存储成本。
除了在做一些日志数据分析之外，整个全观测场景下面也会有很多的指标数据需要去进行监控。这种时候，需要在整个时序系统中能够较好的去完成数据的监控。日志的分析又需要更多的查询和关联的关系，即关联分析的能力。这种情况对整个统一的平台的挑战是比较大的。
阿里云ElastiStack全托管的解决方案可以提供不管是指数据，还是APM，Tracing数据的一站式的采集和分析。还有一些日志的分析，持续数据的一些监控，都会有很多内核引擎的性能优化来保证。可以提高时序日志的监控分析的性能，从而带来更好的一些运维的效果和运维的性能提升。
第六点就是整个系统的可观测性、可扩展性的要求是比较高的。
因为现在的业务分析方案并不一定适合于将来的场景，将来可能会有新技术的引进或者新组建的引进。业务调整会有非常快速的变化，需要这套系统要有很强的可扩展性。
云上ELK加全观测的方案，可以提供这种可能性。这两者都是基于分布式架构的，都会有自己非常灵活的这种API ，以及其他的整个框架结构，也是整个Plugin进来的，会支持用户在上面做各种各样的扩展能力。这样在新的业务场景到来的时候，是很容易在已有的场景上做相应的这种扩展。
下面一个具体的场景介绍。
比如在时序日志场景下，看看全观测是如何解决，首先讲一下时序日志整体的痛点在哪里。
如图所示，这是符合大部分用户的实际的业务场景图。正常情况下，大家早上8点钟到晚上的零点之前，可能都会是数据的高峰期。一般零点到第二天晚上的8点，就是一个数据的低峰期，所以它有很明显的这种高低峰的效应。在高峰期的时候，日志往ES集群里写的时候，有很大的写入压力。在高峰期场景下就需要去扩容增加机器数，但是相应的到达业务低谷的时候可以看到有相对于高峰期的资源，在低谷期已经有相当大程度的浪费。从成本角度看，就需要人工进行缩减，因此整体的成本会是一个很大的问题。同时需要运维组建一整套集群，因为不光要做上面业务开发，还需要去运维自己集群的稳定性。这对整体的业务也是一个比较大的挑战。
总结下来看，会有以下四大问题
第一个是在高频发写入场景下，日志场景往往和伴随着业务和流量的抖动，高峰写入时，很容易把ES集群打爆。
第二个就是存储整体存储成本会比较高，因为日志场景下的数据一般都是TB 到PB级，某些情况下日志为了满足比如审计安全的要求，可能要以年为单位去做存储，这样会使得整体的存储成本比较高。
第三是业务整体利用自建体系的话，持续分析能力是比较差的。因为开源的ES内核会有相应的局限性，在持续日志的查询下，是会很容易发生查询的时间较慢或者是没有结果返回等类似这样的一个结果的。
第四点就是整体的可扩展性和运维的要求会比较高。因为日志的峰值均值差距是比较巨大的。整个大规模的集群这种运维压在技术身上，实现比较困难。
因此需要切换到全观测体系中来，针对方案选型，首先是用的 Apache Flink + ES ，这两款产品是完全百分之百兼容开源的，同时与开源的各种组件是可以做到无缝对接的，可以支持整个跨云多云，甚至IEC 和云上的这么一种打通的这种相关的日志收集和运维能力的。
阿里云整体在开源的基础上都有自己更优势的内核。相应的一般这种计算和写入的性能都达到开源的数倍以上。而且依靠云上的云原生和全托管的能力会给用户一个更高的弹性和更低的成本。
相应的数据，包括外部的数据，外部的日志，APP 的日志，用户的行为数据，以及埋点的指标等，这些数据会通过日志采集器，包括像log stash 、frame 这些采集到kafka里做一层的汇聚。汇聚之后日志数据数据可以用flink 做相应的轻量级的计算，把数据做相应的规划。
规划好的数据可以存储到云上的ES中。在ES 上可以搭建自己的kibana，做相应报表的可视化，以及做规则监控号监控告警以及关联分析，在云上将整套全观测的方案来做一个实现。
接下来介绍下实时计算Flink版在整个ERK全观测方案中，优势在哪里？
优势主要体现在3点，第一点是流式SQL。
实时计算Flink版百分之百兼容开源的Flink 同时有自己的一站式开发平台，方便用户在上面利用SQL去开发各种数据规划脚本，在这种EPL的场景下非常好用的，因为有大量离线计算已经用到了这种SQL，同时对比开源实时计算Flink版核心的算法能力是能达到2倍以上的。
第二个是Serverless服务，整体集群的运维全部托管上云。
用户无需关心如何运维，资源预留高峰低谷等情况如何处理，这样整体都是可以使用一个按量的方式来运作的，用户可以集中精力关注自己实际的这种业务开发中去。
第三部分其实就是更适合时序数据变换的 Autopilot 能力。
如上图，数据的流量基本上是以黄色的部分来展示的，会有峰值和谷值。那么在波峰波谷下，根据理想中匹配的算力应该是图中绿色的部分，就是在数据较少的时候给这个作业分配较少的资源，让它能够正常的运作，当波峰到来的时候，需要加大相应作业的资源，使它不要延时反压或者是丢数据。
那么在这种场景下，如果是开源的这么一个方案的话，只能有一个固定分配算力的这么一个方案。也就是说只能提前设计好计算资源提，就是如图中蓝色的部分，当数据流量处于低谷的时候，会有资源浪费情况，那么数据流量处于高峰的时候，就会发现自己的作业可能会有一些延迟和反压。
那么云上的实时计算Flink版其实是提供Autopilot 能力，它可以根据所有算子的流量变化自动的重新分配资源，来做到一个智能的削峰填谷的能力，有效的应对持续日志场景下数据的波峰波谷的这种变化。
除了实时计算Flink版在云上有很多增强特性和功能之外，其实阿里云ES就是在日志场景下面也有很多提高性能和降低成本的一些特性。首先在数据从Flink去往ES 的时候，会在ES 上遇到很大的一些写入的索引，构建的一些计算的压力。
大部分在日常场景下这样写多读少的集群用户的主要资源预留都是为了整个ES 写入的这一部分所预留的。在云上我们提供了日增强版IndexingServerless这样一套写入托管的服务。
可以在架构图中看到，在数据写入到用户的本地ES 后会转发到云端的这样一个IndexingServerless的写入托管服务来做整体的一个写入加速，这样就是解除托管服务背后是海量的一些计算能力，从而可以去打破本地集群的一些物理资源的限制，去实现了整体这样的一个ES 的读写分离。而同时在整个云端这样一套IndexingServerless的写入，阿里云也是做了很多内核性能上的优化，去满足整个高并发的输入写入要求，并且能够比开源达到更高的一些写入性能。
最值得关注的一个点就是这一部分写入资源，在云端托管的时候，完全是按量去做付费的，也就是说大家平时去使用ES集群，大多都是去买多少个数据节点来去扛这样的一个高并发的写入。但是在这样一个写入托管服务下面，用户是可以完全按照写入流量去进行付费，不需要去提前预留太多的一些集群资源来去满足整个集群的并发写入要求。
从下面这张表里可以看到，按相同的一些ES 集群规模来去跟开源做对比，在三个数据节点的这样的一个集群规模下面，开源只能承载2万多的TPS 这样的一个写入能力。
而这样一个IndexingServerless ，可以通过日志写入的托管和日志增强的能力，有将近20万也就是10倍的一个写入能力，同时在完成了这样的一个高并发的一些扛高峰的能力扩展之外，对原来开源自建20个高配节点这样的一个场景，完全可以去根据流量去满足这样的一个写入流量的计付费方式。也就是在本地只需要去保留将近可能10个节点以下的这样的一个ES 节点规格来去保证整个集群的存储数据。
除此之外，在整个数据的写入完全是按高峰和低峰实际流量去做计费。拿一个实际的业务场景的集群来举例子的话，每天12TB这样的一个日志增量写入，完全是可以达到整体的计算成本70%以上的降低。而将日志数据写到ES后，数据可能会在ES 去长期的存储，可能是7天，也可能一个月甚至半年或者一年这样的日志数据，就有很多用户会去关心如何进一步的降低在存储这一部分的成本。
目前在云上阿里推出了一自研的日志存储引擎Openstore实现了整个在日志数据的计算和存储分离。
整个方案的底层都是使用自研的存储引擎去存储日志数据。然后Openstore的存储类型其实成本相对于比如说高效云盘或者本地下榻盘，是降低了60%到70以上的。
另外最关键的一个点就是说当大家购买ES集群的时候，大部分是固定容量购买，比如固定的单节点60GB的这样60T或者6T这样左右的一些数据容量，但当数据没有写满，或者说数据还没有达到这么高容量的时候，这些存储资源也是相对浪费的。
而存储引擎Openstore完全是按实际用量去付费的，它背后可以支撑海量的数据存储。搭配存储的Serverless化，能更好降低存储成本。另外整套自研存储引擎会通过底层的存储服务和能力去保证整体的一个数据的高可用，能够提供将近99.9999999999% 的这样一个数据持久性来满足整个日志场景的一些海量存储的需求。
介绍完整个日志全观测的方案和云上的产品能力之后，可以看下这样的一套全观测的方案目前在什么样的一些行业和客户中已经去投入使用
好未来是大家比较熟悉的教育公司，主要是提供教育新模式的平台，目前基于这样一套全观测的方案，实现他们整体系统的包括日志查询和指标监控的服务。对于整体日志监控平台来说，目前企业整个数据流程在数据采集和集中这部分会通过整个彼此开源的托管的组件去实现整体的设备和网络上多方的日志数据的采集和集中。
再将整个数据去通过kafka写到实时计算Flink版版 里面去，基于Flink 的一些流式计算能力去做数据的处理和格式化，最后再将数据去投递到存储阿里云LINUX search 的这样的一个集群里面去，这样一个集群和他们原来最开始的自建服务相比，云上的平滑扩缩容的能力更强势。可以不管是高低峰的时候都能更好的完成平滑的重启和平滑的变更，并且对业务来说相对0影响，有比较高的稳定性保障的。
这套体系不但可以提供面对流量激增的平滑扩容的能力更能提供上层所需的可视化分析任务，包括基于X - pack里面的一些高级特性来去支撑上层数百个企业级客户的权限分配管理，通过数据时效性的查询能力，去完善整个日志观察的监控分析里的务诉求。
除了教育行业之外，在游戏行业里面，日志全观测场景，也是比较常用到的。
对于很多游戏公司来说，他们会有大量的游戏数据，包括很多游戏内的用户行为日志，底层服务器等数据及整个系统链路中的一些日志数据，需要对这样的繁杂的日志数据进行采集和格式化，最终存到阿里云Elasticsearch里面。
这也会用到日志增强版的一些日志场景的特性，即能够通过冷热数据的分离架构，实现整体低成本和高性能的存储和查询要求，又可以通过实时计算Flink版和ES来提供整个系统稳定性保障和SLA 的支持。
目前企业的这套日志全检测方案已经存储了将近几PB 的日志数据。弹性的写入和弹性流式计算能力，能够支撑企业比如新游戏上线产生、游戏开服的时候产生的峰值数据，可以给游戏用户带来更好的服务保障。
随着企业后续的业务扩展，一套基于ELK+Flink的开源方案，能够更好的跟上下游的业务实现对接，同时也能够在业务的不断发展过程中，带来更多的业务后续上层的查询能力，包括时效性的保障和扩展的支持。
更多 Flink 相关技术问题，可扫码加入社区钉钉交流群
第一时间获取最新技术文章和社区动态，请关注公众号～
活动推荐
阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动：
99 元试用 实时计算Flink版（包年包月、10CU）即有机会获得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
了解活动详情：https://www.aliyun.com/product/bigdata/sc
