Elastic Metric 基礎 透過 Metricbeat 監控系統與服務的實務應用

Lin Yen-Cheng on 2020-09-11 5 min. read

這篇文章會淺談 Eastic Metric 的相關基礎知識與 Metricbeat 的實務應用。

Metric 簡介

系統或服務的監控為什麼重要?

  • 實體機硬碟要滿了,資料庫快要寫不進去資料怎麼辦?
  • 都沒發現網路頻寬用滿,伺服器還是很輕鬆?
  • 服務掛了等到被客訴了才發現? APP 都閃退幾次了?
  • 每個服務都開一台機器,結果流量集中在少數服務上?
  • 有些服務吃記憶體,有些吃運算效能,到底要怎麼配機台?

Metric 跟 Log 單看內容其實很像,其中的異同在

  • Metrics 跟 Logs 都提供了監控的效果
  • Logs 專注在事件什麼時候發生,還有事件本身
  • Metrics 就是排程收集固定資料

Metricbeat

要評估系統和服務需要很多指標,要評估需要:

  • 儲存: 讀檔、抓相關指標、網路流量
  • 分析: 這就是 kibana 的工作
  • 監控: 監控服務可用性

Elastic Stack 提供了最方便蒐集指標的工具也就是 Metricbeat,沒有之一。

Metricbeat 可以同時從系統及服務上收集好幾種指標傳送到 Elasticsearch 或是 Logstash 儲存,資料量比較大的話通常也會先傳到 Redis 或是 Kafka,資料的生命週期大致如下:

  • 排程
  • 傳送
    • Metricbeat error events: 沒抓到也會送錯誤
  • Hot data 儲存
  • 搜尋、分析
  • Warm data 封存
  • Purge

要怎麼開始使用,可以參考之前寫的 Metric Quick Start,步驟大致如下:

  • 下載
    • 有提供各平台可執行的 binaries 檔
  • 配置
    • 記得正確設定 Output
    • ./metricbeat setup --dashboards
  • 啟動
  • 查看資料
    • Index Pattern ‒{type}beat-{version}-{yyyy-MM-dd}-XXXXXX
    • XXXXXX is the number of the index for a given day (文件寫的不太懂怎麼翻 XD)
    • 預設每滿 30 天或是達到 50GB 新的 Index 就會 Rotate
    • 資料有送到 Elasticsearch 就可以透過搜尋介面查看

實際案例

如果我們想要實作一個提供地理資訊的平台,以開源的技術選型為例,資料讀取會需要好幾個服務來源提供,這樣的架構底下只要有一個服務來源出錯,前端就會有功能出現異常,這時候我們就會想要在每個服務上面都安裝監控,去發現系統裡面的效能瓶頸。

使用組合技 Metrics + Logging + APM 我們就可以更快更方便的了解服務與系統現在的狀況,在出現效能或是系統錯誤時,我們也可以更快速地去進行相關修正。

  • 資料庫: Metricbeat
  • Web Service
    • 如果服務在不同台主機上,就每一台都裝 Metricbeat
    • 服務如果有 Log 可以搭配使用 Filebeat
    • API Service: 自己實作的可以再加碼 APM

ServerAndService


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

share