开发者学堂课程【大数据知识图谱系列—基于ELK+Flink日志全观测最佳实践：基于 Elasticsearch+Flink 的日志全观测最佳实践（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/900/detail/14322
基于 Elasticsearch+Flink 的日志全观测最佳实践（一）
目录：
一、什么是全观测
二、观测场景技术难点和解决方案
三、时序日志场景痛点分析
四、全链路日志分析与监控ELK技术难点
五、全观测解决方案实现日志监控/运维/分析
六、实时计算 Flink 版
一、 什么是全观测
在运维的过程中，一方面会面临大量系统的数据，这些数据分散在很多系统和部门，甚至包括系统中的各个模块，对这些繁杂的数据进行统一的运维和分析，是相对困难的。
在整个开源的生态中，做运维和可视化分析会用到多个厂商的工具，将多个工具之间进行打通，再进行统一分析是比较难的，还需要去做自行开发和配置。
有很多的数据需要做日志的分析，也需要很多的指标数据来告知系统中指标出现了一些异常和问题，很多数据（日志和指标）表现的问题都是比较片面的，而故障却是相对立体的，所以运维需要的是能够去通过某一个时间点的一些日志和指标数据进行关联的分析，去发现问题。
全观测是对传统运维的一个改进，它将日志指标 APM 等数据汇总到统一的平台上，让研发、运维、业务人员等在上面对所有的数据用一个统一的视角去做一个综合的分析，发现整体有什么类型的问题。
1）、传统运维存在哪些问题?
数据孤岛，分散在不同部门,分析排查故障困难
多个厂商的多种工具，无法自动化统-分析
故障是立体的，日志、指标等都只能看到一方面的可观察性
只进行收集，没有真正深入分析，不能发挥大数据的价值
好处：
1. 有一个统一的可视化的报表，能够对所有日志的时间做一个对齐，能对所有日志设置一个相同的过滤条件。
2. 所有的数据在统一平台后可以基于所有的数据设置统一的报警规则和监控。
3. 可以进一步的对数据进行尝试。因为数据量足够多，足够丰富，可以利用这些日志数据来做相应的机器学习方面的尝试，利用机器学习的能力来实现智能告警智能监控的能力。
2）、全观测的定义
全观测是对传统运维的改进将日志、指标、APM 数据,汇总在一个平台让运维、开发、业务人员对所有的数据从统一视角进行观察分析
建立统一的可视化视图、对齐时间、过滤条件
建立统一的基于规则的监控和告警
建立统-的机器学习的智能监控和告警
二、全观测场景技术难点和解决方案
难点：
1. 指标和日志获取比较难。
企业的机器、业务系统、网络环境等都有可能不同，并且分布在不同的云厂商下，有的客户是在自己的 IDC 里还有一部分数据。会存在多种指标，每个日志的采集手段是不一致的，很难使用一个统一的平台把它落实。
2. 在自建系统中，如何对日志、指标等做出相应的规格归一化和格式化。
企业在线下操作统一是比较困难的。在云上的话，可以依托于实时计算 Flink 版这样一个流式计算的能力，把上游的所有数据统一送到实时计算 Flink 版里面，在利用实时计算 Flink 版 本身的SQL 能力，因为 Flink SQL 能力更适合于 ELK 的场景，对数据做一些简单的 transform 和一些转换的时候，会更加方便。
1)、全观测场景面临哪些痛点
● 日志/指标获取难
机器、业务系统、网络链路、操作系统，诸多指标及日志获取手段不一, 落地过程复杂
● 日志/指标规格化要求高
上下游链路配合衔接过程中，如何将有效信息从海量日志中获取
● 高并发写入、系统稳定性差
业务/流量抖动，日志写入峰值往往会很高，旁路系统稳定性受到很大的排战
● 海量数据存储成本高
日志场景涉及海量数据，TB 级别起步，甚至 PB 级
● 日志分析和指标监控统-难
借助时序系统可以很好的完成监控，但异常分析困难相反，如何在统一平台完成
● 系统可扩展性要求高
业务调整带来的技术演进一直在发生， 技术组件更新快,运维框架需要有强大的兼容性
二)、云上 ELK+ Flink 全观测解决方案能力
● Beats 获取日志/指标
轻量化的提供各 类 metic、Logs、 APM 数据采集能力
● 数据清洗 SQL 化更简易
支持各类网络格式的日志/指标采模板，实时计算 Fink 提供完整流式 SQL 能力
● 云上 ES 写入托管及超强稳定性
提供 Indexing serice 自 研 ES 写入托管服务，及跨机房部署、同城容灾。场最内核优
● 低成本数据存储
阿里云 ES 提供冷热分离数据存储方式，及自研存储引学 Openstore 优化存储压缩算法
● 日志分析、指标监控、APM能力齐全
阿里云 Elastistack 全托管，提供日志分析、监控 Tracing 一站式能力针对时序场景，针对性优化引擎，保证时序日志监控和分析的性能
● 开源生态具备强大的可扩展性
基于分布式架构，以及灵活开放的 RestAPI 和 Plugin 框架，支持各种扩展能力
三、时序日志场景痛点分析
一）、写多读少的日志场景下会遇到什么问题
1、高峰期写入压力大、弹性扩展难以有效实施
2、海量计算+存储资源成本高、低峰期资源闲置
3、为保证系统稳定性、集群运维管理复杂
四、全链路日志分析与监控 ELK 技术难点
1)、日志分析场景系统搭建会遇到哪些问题?
01、高并发写入
●日志场景往往面临业务/流量抖动
●日志写入峰值往往会很高
●ES 集群容易被打爆
02、存储成本高
●日志场景涉及海量数据
●TB级别起步， 甚至 PB 级
●部分场景(如:审计)长周期存储
03、时序分析性能差
●ES 内核技术局限性
●日志场景中的时序查询性能差
●复杂聚合、Range 等查询性能瓶颈明显
04可伸缩性及运维要求高
●日志峰值/均值/谷值差异巨大
●集群规模大管理运维复杂
需要切换到全观测体系中，首先使用的是 Apache Flink + ES ，这两款产品是完全百分之百兼容开源的，同时与开源的各种组件是可以做到无缝对接，可以支持整个跨云多云，IEC 和云上有打通这种相关的日志收集和运维能力。
