iT邦幫忙

2021 iThome 鐵人賽

DAY 30
1
DevOps

喬叔帶你上手 Elastic Stack - 探索與實踐 Observability系列 第 30

30 - 有效的使用 Observability 的資料 (4) - 使用 Elastic Observability 追縱及觀察問題的心得

有效的使用 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

30-elasticon-workshop

很驚豔的一場活動,由 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 的心得來當作這次鐵人賽的結尾。

(完全沒想到這次有夠累,比上一屆參賽還累,之後有空再來補心得! 打完收工!)


上一篇
29 - 有效的使用 Observability 的資料 (3) - 資料的生命週期管理
下一篇
喬叔帶你上手 Elastic Stack - 探索與實踐 Observability 系列 - 文章總覽與心得
系列文
喬叔帶你上手 Elastic Stack - 探索與實踐 Observability31

1 則留言

1
熟女卡卡
iT邦新手 5 級 ‧ 2021-10-19 16:17:09

恭喜完賽 最厲害的壓線團長讚讚 /images/emoticon/emoticon08.gif

喬叔 iT邦新手 4 級 ‧ 2021-10-19 22:50:42 檢舉

有壓線獎的話我應該有潛力得前三吧! XD~

我要留言

立即登入留言