# 使用 Elastic Observability 追縱及觀察問題的心得 ### 本篇學習重點 * 參加 ElasticOn Global 2021 Observability Workshop 的心得分享 * Elastic Observability 追縱及觀察問題的心得 ## ElasticOn Global 2021 Observability Workshop 在參與這次第 13 屆鐵人賽的過程中，剛好遇到了 [ElasticCon Global 2021](https://www.elastic.co/elasticon/global) 的活動 ( Oct 5-7, 2021 )，在最後一天的議程中，有 Workshop 可以參加，我自然就選了最近我投入最深的 Observability 這個主題 - **Capture the Bug with Observability** ![30-elasticon-workshop](https://i.imgur.com/13WzJuf.png) 很驚豔的一場活動，由 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](https://github.com/GoogleCloudPlatform/microservices-demo)，在裡面裝了 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 的心得來當作這次鐵人賽的結尾。 (完全沒想到這次有夠累，比上一屆參賽還累，之後有空再來補心得! 打完收工!) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://training.onedoggo.com/tech-sharing/uncle-joe-teach-es-elastc-observability/you-xiao-de-shi-yong-observability-de-zi-liao/shi-yong-elastic-observability-zhui-zong-ji-guan-cha-wen-ti-de-xin-de.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.