使用 Elastic Observability 追縱及觀察問題的心得
Last updated
Last updated
參加 ElasticOn Global 2021 Observability Workshop 的心得分享
Elastic Observability 追縱及觀察問題的心得
在參與這次第 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 組成的團隊，以競賽的方式來進行，整場活動我整理成以下幾個部份來描述為什麼我覺得驚豔：
出了十道題目，讓大家來找碴，大家會被指派一名 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 得到的心得：
當我們透過 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 畫面上，也會標示出是否有版本的變化，讓我們快速的可以看到，是不是因為更版後才造成的問題。
一個系統的 Logs 量非常的多，一但要盤查問題的時候，而且問題的方向還不夠明確時，Log 量太大，會讓我們很難的觀察問題，首先是 Logs 沒有收集在一起的話，盤查所花的時間肯定是集中化的數倍以上，集中化之後透過結構化及正規化後的 Log，我們在某些 filter 的條件就可以下得更有效率，例如直接 bypass 某一個 service 的 logs，或是專注在某種篩選條件的相關 logs，例如先專注在某一個有問題的 service 當中的某一台機器，但又可以快速的比對其他台機器，會對找問題非常有幫助。
我先前並沒有在實際專案上使用過 Elastic Stack 的 Machine Learning，在這次的 workshop 時，在盲目探查問題的時候，真的很有幫助，不過在問題浮現之後，倒是真的就比較沒在用到，不過對於還沒浮現的問題，能透過這樣的機制，在問題更被放大、甚至產生連鎖反應之前，就能被警示到，這部份就覺得蠻值得有一定規模的服務投資了。
透過以上我參加這次 ElasticOn Global 2021 的經驗分享，以及整體使用 Elastic Observability 的心得來當作這次鐵人賽的結尾。
(完全沒想到這次有夠累，比上一屆參賽還累，之後有空再來補心得! 打完收工!)
