使用 Metricbeat 掌握 Infrastructure 的健康狀態 Host 篇

本篇學習重點

  • 如何設定 Metricbeat 並且以 Host 部署的方式來收集 Elastic Observability 所需的資訊

  • 使用 Kibana Observability 掌控 Infrastructure 當中各服務與主機狀態的簡介

Infrastructure 監控的示範情境

由於我在寫文章的當下,手邊沒有合適的實際環境來當作示範,所以只能以我目前手邊有的機器,來模擬一些情境,主要是介紹配置的方式來說明,實際上若有更複雜的情境,可以以同樣的類推以進行部署。

以下是我目前的進行的環境模擬:

服務名稱
主機環境
情境說明

opbeans-node web server

Mac mini's Docker container

主要只是讓服務運作在 Container 之中

opbeans-node PostgreSQL DB server

Mac mini's Docker container

主要只是讓服務運作在 Container 之中

opbeans-node Redis server

Mac mini's Docker container

主要只是讓服務運作在 Container 之中

Metricbeat

Mac mini

透過 Mac mini 的 Metricbeat 當作是 Infrastructure 當中,專門集中化收集 opbeans 這組服務的 Metrics。

Metricbeat

web-server-1 @ Mac mini's Docker container

在 Container 之中,模擬另一台主機,並在裡面安裝獨立的 Metricbeat 收集 System info。

Metricbeat

web-server-2 @ Mac mini's Docker container

在 Container 之中,模擬另一台主機,並在裡面安裝獨立的 Metricbeat 收集 System info。

opbeans-node 示範 App

opbeans-node 是 Elastic 官方維護的一個 Demo App,他是一個庫存管理的系統,

我們可以從 Github 取得他的 Source Code:https://github.com/elastic/opbeans-node

整個 stack 就只有簡單的 Web Server + PostgreSQL + Redis Server,架設起來長相如下:

如何設定 Metricbeat 來進行監控 Metrics 的收集

由於我們要使用 Mac Mini 當作 Metricbeat 監控的主要收集點,我們首先要先安裝 Metricbeat,這部份請參考先前 Metricbeat 基本介紹的文章

接著我們分別針對我們這次要監控的情境進行設置。

使用 System module 收集機器的系統 Metrics

收集 System Metrics 是監控 Infrastructure 最基本的要取得的資訊,基本上整個 Infra 之中的每台主機,我們都應該要掌握機器的 System Metrics,不過因為要收到的夠詳細的資訊的話,Metricsbeat 的佈署必須要安裝在本機,無法透過 Remote 的方式直接取得,所以在我們的情境之中,會要在以下三台 Host (其中有兩台是用 docker 模擬的) 都安裝好 Metricbeat。

  • Mac Mini

  • web-server-1

  • web-server-2

接著啟用 System module

./metricbeat enable system

並且在 ./modules.d/system.yml 調整相關的配置

- module: system
  period: 10s
  metricsets:
    - cpu
    - load
    - memory
    - network
    - process
    - process_summary
    - socket_summary
    # - entropy
    # - core
    # - diskio
    # - socket
    # - service
    # - users
  process.include_top_n:
    by_cpu: 5      # include top 5 processes by CPU
    by_memory: 5   # include top 5 processes by memory
  # Configure the mount point of the host’s filesystem for use in monitoring a host from within a container
  #system.hostfs: "/hostfs"

- module: system
  period: 1m
  metricsets:
    - filesystem
    - fsstat
  processors:
  - drop_event.when.regexp:
      system.filesystem.mount_point: '^/(sys|cgroup|proc|dev|etc|host|lib|snap)($|/)'

- module: system
  period: 15m
  metricsets:
    - uptime

我們可以設定不同的 period 來以不同的頻率收集不同的 metricsets

注意:由於 System module 要收集許多系統層級的資訊,會需要的權限會較高,官方文件有特別提醒要謹慎的開放權限。[1]

啟用 PostgreSQL module

接著我們要啟用 PostgreSQL module

./metricbeat enable postgresql

./modules.d/postgresql.yml 調整相關的配置

- module: postgresql
  metricsets:
    # Stats about every PostgreSQL database
    - database
    # Stats about the background writer process's activity
    - bgwriter
    # Stats about every PostgreSQL process
    - activity
  period: 10s
  hosts: ["postgres://localhost:5432?sslmode=disable"]
  username: postgres
  password: _PASSWORD_

這邊要注意,因為我的示範環境 PostgreSQL 沒有開啟 SSL,所以有特別加上 sslmode=disable ,這個不應該在正式環境出現。

啟用 Redis module

接著啟用 Redis module

./metricbeat enable redis

./modules.d/redis.yml 調整相關的配置

- module: redis
  metricsets:
   - info
   - key
   - keyspace
  period: 10s

  # Redis hosts
  hosts: ["127.0.0.1:6379"]

  # Network type to be used for redis connection. Default: tcp
  #network: tcp

  # Max number of concurrent connections. Default: 10
  #maxconn: 10

  # Redis AUTH password. Empty by default.
  #password: foobared
  
  key.patterns:
    - pattern: 'pipeline-*'
      limit: 20

在這裡我有啟用 key 的資訊收集,所以要設定好 key.patterns 設定。

以上三種模組只是個示範,Metricbeat 裡已經整合好 60 多種的模組,可以直接使用,對於想要監控自己 host 的各種服務,可以簡單的開啟即使用。

設定完成後,啟用 Metricbeat 我們就可以到 Kibana Observability 來觀察收集到的資訊。

使用 Kibana Observability 來掌握 Infrastructure 的 Metrics

Inventory 概觀

從 Kibana Observability 的 Metric Inventory 畫面,我們先針對 Hosts 的方式來檢示,預設的 Metric 是觀看 CPU usage ,這部份我們可以自己依需求調整,甚至可以儲存成不同的 view,方便日後切換檢示。

由於我的情境,只有三台 Host,所以看到的畫面如下圖,三台機器全部列在 Inventory 的列表上,並且即時的顯示 CPU 的使用量,而若是要檢示歷史的數據變化,在最底下有檢示歷史數據的走勢圖。

09-kibana-obs-metrics-inventory

Inventory 的分群與搜尋檢示

Inventory 預設的檢示畫面其實很陽春,我們可以多透過 Group by 的功能,來使用像是 Service type 或甚至自己定義的欄位也可以用來 Group by,只要是 index 裡面有收集到的資訊,都可以使用,所以先前所建議我們可以使用 TagsFields 等自訂義的欄位,就能派上用場。

09-kibana-obs-inventory-group-by

使用 Service type Group By 之後的結果如下,可以更快速的專注在某一塊要觀察的主題上。

09-kibana-obs-inventory-service-view

從 Inventory 的概觀,進入到 Host 的細節,更深入的 Observability

一但我們發現某一台機器有異常,想要多觀察時,這時只要點下這台機器,我們馬上可以進入細節的頁面,而這個細節的頁面,也就是 Elastic Observability 整合好各種資料檢示的入口,讓我們能從 Metrics、Logs、Processes…等各種資訊來盤查問題,也可以查看 Machine Learning 的 Anomalies 的執行狀況,甚至可以直接連接到 APM 與 Uptime 繼續追縱。

09-kibana-obs-inventory-detail-view

Kibana 另外內建的 Dashboard

透過 Metriccbeat 所收集的資訊,除了 Kibana Observability 這邊可以看到之外,特別是針對像是 System、PostgreSQL、Redis 的服務,Elastic 也有預先建立好這些服務所專用的各種 Dashboard,非常的豐富,可以從 Kibana > Analytics > Dashboard 去搜尋。

以下圖為例,就是 [Metricbeat System] Host overview ECS 的 Dashboard。

本章小結

針對 Host 服務所要觀察的 Metrics 資訊,Elastic 透過 Metricbeat 整合好許多的服務,也建立了各種不錯的 Dashboard,這部份對於我們要快速的掌控系統及服務的狀態,能很容易的上手,同時 Elastic Observability 針對 Metrics, Logs, Uptime, Trace 的整合也做得蠻不錯,讓我們要追縱問題時,可以容易的將這些資訊串連在一起,在 Observability 上的確有不錯的幫助。

參考資訊

Last updated