喬叔的 Elastic Stack 專業教育訓練
  • 喬叔的 Elastic Stack 專業教育訓練
  • 🧑關於喬叔 (Joe Wu)
  • Elastic 課程公開班
    • 🎯Elasticsearch 基礎實務班
      • 💯學員課後回饋
    • 🆕Elasticsearch 進階運維班
      • 💯學員課後回饋
    • Elasticsearch 進階開發班
    • Elastic Stack 基礎實務班
    • Elastic Observability 基礎實務班
    • 📩課程許願池
  • 技術分享
    • 📗喬叔帶你上手 Elastic Stack
      • 前言
      • Elastic Cloud 如何建立 Deployment
        • ES Node 的種類
        • 配置的選擇
      • Index 建立前你該知道的
        • ES Index 如何被建立
        • ES 的超前佈署 - Dynamic Mapping
        • ES 的超前佈署 - Index Template
        • ES Index 的別名 (Alias)
        • 管理你的 Index - Kibana Index
      • 管理 Index 的 Best Practices
        • Shard 的數量與 Rollover & Shrink API
        • 三溫暖架構 - Hot Warm Cold Architecture
        • Index Lifecycle Management (ILM)
        • Rollup
        • Transform
        • Snapshot Lifecycle Management (SLM)
        • 總結
      • Elastic Cloud 比免費版還多的功能
        • Elastic Stack 的方案比較與銷售方式
        • Centralized Beats Management
        • Centralized Pipeline Management
        • Watcher
        • Elasticsearch Token Service
        • Multi-stack monitoring & Automatic stack issue alerts
      • 向 App Search 學習怎麼用 Elasticsearch
        • 揭開 App Search 的面紗
        • Engine 的 Index Settings 篇
        • Engine 的 Mapping 篇
        • Engine 的 Search 基礎剖析篇
        • Engine 的 Search 進階剖析篇
      • Elasticsearch 的優化技巧
        • Indexing 索引效能優化
        • Searching 搜尋效能優化
        • Index 的儲存空間最佳化
        • Shard 的最佳化管理
      • 完賽心得
    • 📘喬叔帶你上手 Elastic Stack - 探索與實踐 Observability 系列
      • 前言 & 淺談 Observability
      • Elastic 的 Observability 解決方案
      • Uptime - 掌握系統的生命徵象
        • 我們要觀測的生命徵象是什麼?
        • 使用 Heartbeat 收集系統生命徵象數據
        • 透過 Kibana 觀看心電圖及設定警報
        • 使用合成監控 (Synthetics Monitor) 從使用者情境驗證服務的運作狀態
      • Metrics - 觀察系統的健康指標
        • Metrics 與 Metricbeat 的基本介紹
        • 使用 Metricbeat 掌握 Elastic Stack 的健康狀態
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 Host 篇
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 Docker 篇
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 Kubernetes 篇
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 AWS 篇
      • Logs - 挖掘系統內部發生的狀況
        • Logs 與 Filebeat 的基本介紹
        • 使用 Filebeat 應該要了解的設計細節與原理
        • 透過 Filebeat 收集 Elastic Stack 中各種服務的細節資訊
        • 透過 Filebeat 收集 Infrastructure 中各種服務的細節資訊
      • Traces - 觀察應用程式的效能瓶頸
        • Elastic APM 基本介紹
        • 使用 APM-Integratoin-Testing 建立 Elastic APM 的模擬環境
        • 如何在 Kibana 使用 APM UI
        • 使用 APM Server 來收集 APM 數據
        • 透過 APM Agents 收集並傳送後端服務運作的記錄
        • 透過真實使用者監控 (RUM, Real User Monitoring) 來改善使用者體驗
      • 建立結構化的 Log
        • Elastic Common Schema 結構化 Log 的規範
        • Elasticsearch Ingest Pipeline 資料 Index 前的轉換好幫手
          • 基本介紹
          • 各種常用的 Processor
          • Enrich 資料與例外處理
      • 有效的使用 Observability 的資料
        • 透過 Machine Learning 發現異常的問題
        • 使用 Kibana Alerts 主動通知異常狀況
        • 資料的生命週期管理
        • 使用 Elastic Observability 追縱及觀察問題的心得
      • 完賽心得
    • 😀Elasticsearch 技術分享小品
      • 🤖Elastic 與 AI
        • Elasticsearch Inference API 讓我們直接在 ES 裡運用 OpenAI Completion API
    • 🎥線上分享
      • 喬叔 Elasticsearch Index 管理與效能優化技巧
      • Elastic Certification 認證經驗分享
    • 🛠️workshop
      • 如何在 Elasticsearch 實現敏捷的資料建模與管理 @ DevOpsDays 2023
        • 工作坊實作內容
      • Elastic Observability 實作體驗坊 @ DevOpsDays 2022
        • 行前準備
        • 工作坊實作內容
      • 當 Elasticsearch 搜尋引擎遇上 AI @ HelloWordDevConference 2024
        • 投影片
        • Elasticsearch 環境準備
        • Google Colab 環境準備
        • 工作坊操作說明
        • ElasticSearch Relevance Engine (ESRE)
    • ⬆️Elastic Stack 版本升級記錄
      • 🔍Elasticsearch
  • 其他專業服務
    • 👩‍🎓企業包班 | 企業內訓
    • 👨‍💼顧問服務
    • 🈺專案合作
    • 🧩Elastic 授權代理
  • 相關連結
    • Facebook 粉絲頁
Powered by GitBook
On this page
  • 本篇學習重點
  • ElasticOn Global 2021 Observability Workshop
  • 有趣的競賽 Workshop
  • 貼近真實情境的出題
  • 手把手的教學
  • 競賽時間壓力造成擬真感
  • 有一定難度的題目
  • Elastic Observability 追縱及觀察問題的心得
  • 盡可能掌握全局的狀態
  • 觀察影響的程度
  • 時間的變化
  • 集中化並且結構化的 Log 真的非常重要
  • Machine Learning 的協助
  1. 技術分享
  2. 喬叔帶你上手 Elastic Stack - 探索與實踐 Observability 系列
  3. 有效的使用 Observability 的資料

使用 Elastic Observability 追縱及觀察問題的心得

Previous資料的生命週期管理Next完賽心得

Last updated 2 years ago

本篇學習重點

  • 參加 ElasticOn Global 2021 Observability Workshop 的心得分享

  • Elastic Observability 追縱及觀察問題的心得

ElasticOn Global 2021 Observability Workshop

在參與這次第 13 屆鐵人賽的過程中,剛好遇到了 的活動 ( 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分,最後排名前三的有小獎品。

貼近真實情境的出題

手把手的教學

每一道題目過後,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 的心得來當作這次鐵人賽的結尾。

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

活動的環境是使用 GCP 環境,並且使用 GCP 自己提供的一個 ,在裡面裝了 Elastic APM Agents,來收集 Observability 相關的資訊,十道題目為了要模擬各種真實發生的情況,會修改原來的 source code 並且打包成不同的 build,再透過 python 控制環境及操作 GKE,要在活動進行的短短時間內快速準備好環境、模擬真實的各種狀況,這部份的技術水準很高,也能真實的體驗到被 Alert 通知有問題時,在摸不著頭緒的情況下,每道題目只有十分鐘的限時,要如何使用手邊有的線索與工具來解決問題。

📘
demo project
ElasticCon Global 2021