這篇文章簡介並整理了 Elastic Observability 基礎服務中 Logs、Metrics、Apm 使用情境。

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