Elastic Observability 簡介 淺談四大功能 Logs、Metrics、Apm、Uptime

me
林彥成
2020-09-05 | 3 min.

繼前面幾篇文章教大家怎麼安裝 Filebeat (Logs)Metricbeat (Metrics)APM (Apm) 後,這篇文章將淺談 Observability 及四大功能 Logs、Metrics、Apm、Uptime。

Observability 簡介

目標是可以偵測並快速找到服務的停機時間、錯誤、回應過慢的可能原因,讓系統達到:

  • 可用性 (usability)
  • 高可用性 (high availability)
  • 穩定性 (stability)

Observability 可以看成是其中一種搜尋案例,主要

  • Logs: 集中管理各種實體 Log 資料
  • Metrics: 監控並了解 infrastructure、apps、services 相關指標趨勢,更進一步也可提供告警機制
  • Apm: 著重在哪些服務被使用,讓效能瓶頸更容易被找到
  • Uptime: 主要協助監控主機是否活著

Observability 的目的是幫助我們快速找到問題,幾個名詞定義

  • SLI (Service Level Indicators): Uptime
  • SLO (Service Level Objectives): 95%
  • SLA (Service Level Agreement): Uptime 95%

舉例來說最後我們的目標就會是希望某個系統的 Uptime 維持在 95%,並在低於 95% 的時候有相關紀錄甚至是提供告警的機制。

如何使用

如果是 DevOops 或是系統維運的團隊,會需要監控機台的相關資訊,前面幾篇文章有介紹怎麼安裝使用 Elastic Cloud 提供的 Filebeat (Logs)Metricbeat (Metrics)APM (Apm) 去進行資料蒐集與系統和服務監控。

  • Filebeat (Logs)
    • Web Sever log
    • App log
    • DB log
    • Container log
  • Metricbeat (Metrics)
    • Container Metric
    • Host Metric
    • DB Metric
    • 網路流量
    • 硬碟空間
  • APM (Apm)
    • 服務使用情況
    • 交易狀況
    • 服務依賴狀況
  • Heartbeat (Uptime)
    • Uptime
    • 回應速度

舉例來說如果今天我們使用 Nginx 當成我們的附載平衡伺服器時,我們可以安裝:

  • Metricbeat: 監控相關連線數及 CPU 狀況
    • connections
    • CPU
  • Filebeat: 蒐集相關 Log
    • access log
    • error log
  • Kibana: 要注意 Index Pattern 需要讓 kibana 可以辨識 (ECS)

ECS (Elastic Common Schema)

在我們照著相關範例啟動並查看 Dashborad 時,會發現 ECS (Elastic Common Schema) 這個名詞,ESC 是一種新規格,讓使用者以一致、可定義的方式整理 Elasticsearch 中資料結構,協助分析不同來源的數據。

透過 ECS,使用者可以更方便的去使用儀錶板或是 Machine Learning 等工具分析内容,更方便的去建立並搜尋。

Beats

不管是 Logs、Metrics、APM 都是透過 Beats 傳送到 Elasticsearch,Beats 是開源的 data shippers,可以安裝到程式中做為 agents 提供相關的資料到 Elasticsearch,Elastic 提供了各式各樣的用途 Beats 給使用者:

  • Filebeat: 傳送實體檔案型的 log
  • Metricbeat: 系統或服務的狀態監控
  • Packetbeat: 監控封包
  • Winlogbeat: 微軟相關事件
  • Auditbeat: Linux Audit data
  • Heatbeat: Uptime 監控
  • Functionalbeat: Serverless 相關監控

使用 Beats 解決了什麼問題:

  • 讀取解析 log 檔
  • 取得系統或服務相關指標
  • 取得網路傳輸相關指標
  • 測試服務可用性

Logs

解決的痛點

  • 每個應用程式或是裝置都有各自格式需要解析
  • 時間格式不一定相同,需要整合
  • 通常是需要專家才看得懂的格式

Log 小結:

  • 提供了尋找問題解答的材料
  • 一筆 log 由 timestamp 還有訊息組成
  • 透過 Filebeat 可以監控資料夾或是某個檔案
  • Filebeat 模組簡化了蒐集、解析、協助處理 log 的格式
  • 只要資料送到 Elasticsearch 就能夠被檢索

Metrics

解決了什麼問題

  • 知道主機在每個時間的狀況

Metrics 和 Logs 都是依照時序來記錄的資料,提供了系統相關的可觀察資料,主要差異如下

  • Logs: 事件發生了才記住什麼時候發生及發生的事情 (相關格式大多不同)
  • Metrics: 定時的紀錄相關指標,像是硬碟空間、處理器使用量、Process 數量等等

Metricbeat 可以從系統及服務上蒐集多個監控指標,原則上安裝好就可以用了:

  • 下載安裝 Metricbeat
  • 設定 Metricbeat
  • 開始 Metricbeat

APM

解決了什麼問題

  • 每個 requests 回應時間,找出服務在哪裏花了最多時間
  • 服務發生了什麼類型的錯誤,即使程式沒處理也會被蒐集

一套完整的 APM 會由以下組成

  • APM Agents: 是一個 lib 需要寫進去我們的程式裡
  • APM Server:
    • beat framwork 實作的 http server
    • 協助驗證並轉換格式寫入 Elasticsearch
    • 資料灌爆來不及寫入的時候可以當 bufffer
    • 與使用者之間多了一層 server 對資料來說也更安全
    • 開 API 讓更多類型的 client 容易串接
  • Elasticsearch
  • Kibana: 相當於 Elasticsearch 的後台 GUI

APM 紀錄哪些東西

  • spans: 哪行程式被執行多久
  • transactions: 也是一種 span
  • errors: 紀錄程式或是服務拋出的錯誤及未處理的錯誤,且包含 stack trace 方便 debug
  • metrics: Distributed Tracing 讓 microservices 的監控更容易,同一時間多個 transactions 也沒問題

Elastic Stack 提供了全端的監控,除了 log 還有主機狀態的監控外,APM 提供了應用程式層級的監控及真實用戶監測,蒐集了相關效能資訊像是 response time、DB queries、calls to caches 等等。

  • Real User Monitoring (RUM): APM
  • Application-level Monitoring: APM
  • Server-level Monitoring: Beats
  • Logging: Beats or Logstash

如何在本機也可以使用 APM

  • 安裝 Elasticsearch cluster with Kibana (version > 5.6)
  • 下載並啟動 APM server
  • 在需要監控的程式中安裝並設定 APM agents
  • Kibana 查看資料是否資料正確送到 Elasticsearch

小結

方便的 Observability 工具讓我們可以更容易地監控機器與服務,進一步也可以透過 Elastic Cloud 提供的機器學習視覺化工具去分析了解我們的指標或資料。


喜歡這篇文章,請幫忙拍拍手喔 🤣

share