30 - 有效的使用 Observability 的资料 (4) - 使用 Elastic Observability 追纵及观察问题的心得

有效的使用 Observability 的资料 系列文章

• (1/4) - 透过 Machine Learning 发现异常的问题
• (2/4) - 使用 Kibana Alerts 主动通知异常状况
• (3/4) - 资料的生命周期管理
• (4/4) - 使用 Elastic Observability 追纵及观察问题的心得

本篇学习重点

• 参加 ElasticOn Global 2021 Observability Workshop 的心得分享
• Elastic Observability 追纵及观察问题的心得

ElasticOn Global 2021 Observability Workshop

在参与这次第 13 届铁人赛的过程中，刚好遇到了 ElasticCon Global 2021 的活动 ( Oct 5-7, 2021 )，在最後一天的议程中，有 Workshop 可以参加，我自然就选了最近我投入最深的 Observability 这个主题 - Capture the Bug with Observability

很惊艳的一场活动，由 Elastic Global Solution Architect (SA) - Dave Moore 主讲，总共有 6位 Elastic SA 组成的团队，以竞赛的方式来进行，整场活动我整理成以下几个部份来描述为什麽我觉得惊艳：

有趣的竞赛 Workshop

出了十道题目，让大家来找碴，大家会被指派一名 SA 当作你的指导员，你的角色就是 SRE，要实际操作 Elastic Cloud 上的环境来找问题，当你找到问题时，你要透过 slack 和 SA 回报，并且透过清楚的说明回报，让 SA 能了解问题的真正原因甚至提出解决方法来得分，找到真正的 root cause 得 2 分，提供正确的 solution 可以再加 1分，最後排名前三的有小奖品。

贴近真实情境的出题

活动的环境是使用 GCP 环境，并且使用 GCP 自己提供的一个 demo project，在里面装了 Elastic APM Agents，来收集 Observability 相关的资讯，十道题目为了要模拟各种真实发生的情况，会修改原来的 source code 并且打包成不同的 build，再透过 python 控制环境及操作 GKE，要在活动进行的短短时间内快速准备好环境、模拟真实的各种状况，这部份的技术水准很高，也能真实的体验到被 Alert 通知有问题时，在摸不着头绪的情况下，每道题目只有十分钟的限时，要如何使用手边有的线索与工具来解决问题。

手把手的教学

每一道题目过後，Dave Moore 会一步一步的使用 Elastic Observability 的工具来分析问题的原因，并且说明如何抽丝剥茧的找到真正的 root cause，过程中也有安排杂讯的干扰，所以不是看到 error logs 就代表一定是 root cause，这样的以摸拟真实情境的环境加上手把手的教学，学习的效果非常的好。

竞赛时间压力造成拟真感

每一题的时间只有十分钟，而且还要等问题浮现，配合时间的压力，很有真实系统出问题的紧张感，透过这样的方式，也让我更真实的验证我自己对於 Elastic Observability 的熟悉程度与掌控度，有的题目甚至要看 code debug，有很多细节不容易在短时间查觉。

有一定难度的题目

有多难? 我举几个例子：

• js 写错，时间比对的部份，某个地方是文字+数字，型态错误，变成非预期的值，造成信用卡的有效时间总是被判定成过期 (对，你要找到 code 写错，在 Kibana 就能看到这段 code 哦!…)

• service publish host 设成 127.0.0.1 导入服务无法从外部存取

• capacity 不足，流量变大，某一台机器的 CPU loading 8x% 以上 ，导致某些服务开始会丢错，latency 变高

• 某个切换页面造成 302 redirect 无穷回圈，因为 query string 参数多了个 # (变成 fragment 的宣告…)

• 前端的 code 有 bug，把某个传入的参数少带，後端发生 nullPointException

不少都是要有一定的程序开发能力，才能解得出来啊...，如果解不出来，也无法说你找到了 root cause，例如…service publish 为 127.0.0.1，不能只说因为这台服务连不到，要说为什麽… (分数好难拿)

虽然最後没有拿到前三名的奖品，不过这场活动过後，我也对 Elastic Observability 有深层面应用上的掌握，觉得真的蛮不错的，也刚好在这次最後铁人赛的文章来分享我的心得。

Elastic Observability 追纵及观察问题的心得

以下几个方向是我在使用 Elastic Observability 得到的心得：

尽可能掌握全局的状态

当我们透过 slack 收到某一个 alert 时，我们可以直接点 link，就跳到 monitoring 的画面，直接带我们进入这个错误的地方，快速让我们进入细节，但很常一个地方丢出的错误，这个地方偏偏就不是问题造成的原因，因此可以透过 Service Map 掌握整体服务的运作状态，有没有哪段 server 与 server 之间、或是 server 与第三方服务之间的路径上，有出现异常，或是整条路上发生异常的有哪些，这部份就容易从 dependency map 来掌握上游的状态。

除此之外 Uptime、Traces、Metrics 也都有 summary 的画面，透过这些画面尽可能的掌握全局系统是否还有哪些被忽略的资讯。

观察影响的程度

系统常常会有些不重要的错误或警告的通知，有时问题发生时，这些资讯数量可能也不少，在盘查问题时，最好能先从对使用者影响的程度来快速的筛选这些资讯，例如 Boostrap 的 javascript 的错误，其实不会是 system down 的 root cuase，在快速判断後，就可以将这类的讯息设定过滤掉，让专注力能不要被这些次要的问题给影响。

时间的变化

为什麽 Summary 的图表，总是会使用 histogram 等方式，而 Elastic Observability 的不少 dashboard 上，都会有一个功能是与"前一段时间"的数据进行比对，例如前一天、或前一周的同时段，这样可以初步的让我们发现某一段 peak 是不是异常，因为或许每次这个时间点都会有 peak，那可能就只是常态。

另外如果在某个时间点之後，latency 大幅上升、或是 request 量有和先前发生较大的变化，可以切换时间筛选关注这段时间，在时间的前、後观察有哪些其他的变熟，针对这部份 Elastic Observability 在 APM Services 的 request histogram 画面上，也会标示出是否有版本的变化，让我们快速的可以看到，是不是因为更版後才造成的问题。

集中化并且结构化的 Log 真的非常重要

一个系统的 Logs 量非常的多，一但要盘查问题的时候，而且问题的方向还不够明确时，Log 量太大，会让我们很难的观察问题，首先是 Logs 没有收集在一起的话，盘查所花的时间肯定是集中化的数倍以上，集中化之後透过结构化及正规化後的 Log，我们在某些 filter 的条件就可以下得更有效率，例如直接 bypass 某一个 service 的 logs，或是专注在某种筛选条件的相关 logs，例如先专注在某一个有问题的 service 当中的某一台机器，但又可以快速的比对其他台机器，会对找问题非常有帮助。

Machine Learning 的协助

我先前并没有在实际专案上使用过 Elastic Stack 的 Machine Learning，在这次的 workshop 时，在盲目探查问题的时候，真的很有帮助，不过在问题浮现之後，倒是真的就比较没在用到，不过对於还没浮现的问题，能透过这样的机制，在问题更被放大、甚至产生连锁反应之前，就能被警示到，这部份就觉得蛮值得有一定规模的服务投资了。

透过以上我参加这次 ElasticOn Global 2021 的经验分享，以及整体使用 Elastic Observability 的心得来当作这次铁人赛的结尾。

(完全没想到这次有够累，比上一届参赛还累，之後有空再来补心得! 打完收工!)

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