02 - Elastic 的 Observability 解决方案

本篇学习重点

• 了解 Elastic 针对 observability 的观点
• 初探 Elastic Observability 的解决方案

Elastic Observability 的观点

前一篇我稍微浅谈了自己对 Observability 的解读，至於 Elastic 针对 Observability 的观点，我蛮推荐 Elastic Observability 的 Product VP - Tanya Bragin 在 Observability with the Elastic Stack [1] 的这篇文章，里面有提到二个看待 Observability 的面向，分别是：

1. 检测服务品质的管理面向：透过定义好的 SLIs (Service Level Indicators) 及 SLOs (Service Level Objectives) 来当作服务品质指标的标准，例如一般会使用系统的 uptime (正常运行的时间) 当作 SLI 的这个指标，进而定义可能是 6 个 9 (99.9999%) 的 SLO 这个目标，并且可以将这两个定义转换成为 SLAs (Service Level Agreements) 提供给客户当作服务的保障范围的依据，这通常会是 observability 的起步，其实也就是以终为始的重要的目的 - 提升客户的满意度，而执行的方式其实就是大家都已经有在做的 Monitoring。
2. 提升解决问题效率的方法：如何让开发、运维的人员，在遇到系统发生问题时，能因为系统具有良好的 Observability，能更有效率的快速发现原因及解决问题，甚至在异常的徵兆发生时，就能观察到异状并且避免更大灾情的发生。

Observability 三本柱

针对 Observability 的三个主要的重点支柱，就是 Logs、Metrics、Traces，这个在所有谈 Observability 的讨论上，已经都成熟的归纳成这三个面向的资讯了，Elastic Observability 也就直接针对这三个面项定义在产品的功能之中。

Logs

日志是掌握系统内部发生什麽事情最重要的资讯，而日志的重点，是从一开始程序开发时日志如何撰写，就已经事关一半的成败，如果源头的资讯不够详细，後续就只能用猜测、或是灾情发生後再去埋 Log，这样就又错过了救援的黄金时刻，再来就会是如何收集散落各地、各种格式的日志，以及如何将这麽大量的资料进行有效的分析及使用，最後是如何管理这些资料的生命周期。

Metrics

Metrics 是以数字化的方式来有效率的解读系统运作状态的重要资讯，举凡 CPU loading, Memory, Disk I/O, Disk free space, Network bandwidth, DB metrics, ... 等各种数字化的指标资讯，透过这些指标能做到最基本的异常的判断，而这些 Metrics 也会是资料量极多的资讯，如何更有效的保留这些资料也会是管理上的重点。

Traces (APM, Application Performance Monitoring)

一个交易在系统处理时，经过了哪些环节、哪些子系统、当中做了什麽事、在哪个地方会产生效能的瓶颈、在哪个服务元件之中有发生异常，能够在复杂的系统架构中协助开发运维的人员一目了然的掌握交易运作的细节。

Elastic Observability 要解决的问题

• 各种装置、系统、服务的 Metrics 资料如何轻松且有效的收集？
• 随着时间不断增长的资料，如何在能保留使用价值的情况下，能在储存效率、使用时的运算效率上，能被最佳化？
• 各种格式的日志与资料，如何能更容易的分析及解读？灾情发生时有效的减少 MTTR (Mean Time To Recovery)？
• 避免没有收集到足够能分析问题的资讯，又要避免收集太多的资讯而造成这些资讯被破碎化的解读，无法有效的分析及使用。
• 分析後的资料，如何能有效的透过视觉化的方式呈现，协助有价值的资讯能有效的被吸收。
• 主动发现异常的状态，提早发现问题及减少灾情的影响范围。

为什麽是 Elastic Stack？

首先因为『Elasticsearch』，整体 observability 的资料应该要能聚集在同一个地方，在分析及使用上才容易发挥最大效益，举例来说 Traces 的资料要能进一步和 Logs 串接，追查问题时能一路接起来，甚至在透过 Machine Learning 分析时，能够将各种资料一并来学习，绝对会比分散在各种不同系统的效果要来得好。

另外要针对巨量非结构化资料进行搜寻，这不只是使用 Apache Lucene 或建个 inverted index 就能处理掉全文检索的工作，Elasticsearch 使用 Columnar store 方式储存文字类型的资料、透过 BKD tree, document store, term vectors…等不断优化 metrics 及 logs 资料分析及汇总的运算能力，资料生命周期的管理机制、分散式架构的扩展能力…这些 Elasticsearch 核心的能力，已经是目前日志储存分析的首选工具。

最後是统一的环境，Elastic Stack 产品之间本身的高度整合，这样高度整合完成的生态圈会让许多後续维护上较於便利，学习门槛也降低，这部份会是很大的一个好处。

Elastic Stack for Observability

• Elasticsearch: 是个 NoSQL DB + 搜寻引擎 + Time-series DB，整体资料分析与运算处理的核心。
• Kibana: 整体方案统一的 UI，不论是 APM, Logs, Metrics, 以及这些 Stack 的管理功能，都可以透过这个入口来进行操作。
• APM: 负责收集 Traces 的资料，包含交易的追纵、分散式架构资讯的追纵、也包含透过网页端收集 User experience data。
• Beats: 协助收集各种 Logs data, Metrics data, Uptime data, Synthetic data。
• Elastic Agent: 新一代将取代 Beats 收集 Logs, Metrics 的工具。

并透过以上的这些产品及工具，能够建构出如下图 Elastic Observability 所提供整体的服务。

参考资料

1. Observability with the Elastic Stack

查看最新 Elasticsearch 或是 Elastic Stack 教育训练资讯: https://training.onedoggo.com
欢迎追踪我的 FB 粉丝页: 乔叔 - Elastic Stack 技术交流
不论是技术分享的文章、公开线上分享、或是实体课程资讯，都会在粉丝页通知大家哦！