這篇文章會淺談 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