ELK 筆記 - 硬體規格評估

-- Pageviews

已經習慣把 Log 存到 Elasticsearch(以下簡稱 ES) 再透過 Kibana 查看日誌,所以每當有新產品要上線前,都會評估 ELK 需要的硬體規格。
依照產品大小不同,儲存 Log 的資料筆數跟空間,都有很大的差異,會直接影響到 CPU、記憶體、硬碟空間等。

近期產品是上到 GCP 跟阿里雲,本篇硬體規格會以雲端服務的 Server 規格做為參考的基準。

情境描述

本範例產品的參考資料:

  • 在線數同時約:6000
  • 交易量每秒約:20筆
  • Log 每週約:320萬筆 (25~30 GB)

算是一個不大的小系統,用 Kibana 查詢近期一週的 ES Index 用量。如圖:

ELK 筆記 - 硬體規格評估 - Elasticsearch Index 用量

使用資源

由於經費有限,所以只有使用兩台 ELK 做 HA,用 Master/Slave 架構,沒有做到 Cluster。
兩台 Server 分別裝載著 ELK 三個服務,架構如下:

ELK 筆記 - 硬體規格評估 - ELK Master/Slave 架構

此範例幾個月前從 GCP 轉移到阿里雲,在這兩個平台使用的 VM 等級如下:

  • GCP (n1-highmem-8)
    • vCPU: 8 core
    • RAM: 52 GB
    • Disk: 20 GB + 300 GB
  • 阿里雲 (ecs.r5.2xlarge)
    • vCPU: 8 core
    • RAM: 64 GB
    • Disk: 20 GB + 300 GB

Master/Slave 的機器規格都是一樣的。

產品運行超過半年,CPU 大約都落在 30% 左右,依照上述使用量,在阿里雲其中一台 ELK Server,近期一週的監控資訊:

ELK 筆記 - 硬體規格評估 - 阿里雲監控資訊

找不到當時在 GCP 用量的截圖。

硬體規格評估

首先要評估預計要放到 ELK 的 Log 量,資料筆數及資料大小。
再來就是 Log Parsing 的規則,如果 Parsing 很複雜 CPU 就會佔用較高的資源。

ELK 三項服務,分別佔用資源情況:

服務CPURAMDisk
Elasticsearch中高極高
Logstash
Kibana

基本上可以完全不用考慮 Kibana 消耗資源。
主要高耗能的就是 ElasticsearchLogstash

CPU

CPU 是比較難評估部分,因為 Log Parsing 的複雜度以及查詢 ES 的條件,都會強烈影響 CPU 的使用量。

  • ES 查詢所消耗的 CPU,阿里雲提供參考:

    每個 vCPU core 大約可處理 20~40 GB 查詢資料。
    (依據本例使用情境,CPU 消耗偏高一些,但也沒落差太多。)

  • Logstash 依照上述的情境,Log 每秒也才 500 筆左右,分配 vCPU * 1,其實綽綽有餘了。

    建議每處理 1500 筆資料,就分一個 vCPU core。

RAM

  • ES 使用記憶體有兩個條件限制:

    1. 最高只能設定為系統的 50%。例:系統 8 GB,ES 只能設定 4GB。
    2. 不能超過 32 GB

    如果條件允許,就直上 64 GB 記憶體,然後把一半分給 ES。
    ES 查詢很吃記憶體,尤其是大區間的查詢,根據阿里雲提供的參考:

    每 1 GB RAM,大約可處理 10 GB 查詢資料。

  • Logstash 的記憶體用於緩存消化不完的資料,CPU 不夠力的情況下就會需要比較高的記憶體。
    不過還是要依照實際使用量調整,在預估資源分配上,不用考慮太高的比重。

    基本上 1 GB 以內都夠用,甚至 128 MB 都夠用。

Disk

ELK 實際存資料的是 ES,所以評估時就不考慮 Logstash 跟 Kibana。
系統碟分配 20 GB 基本上就很足夠了,甚至可以更低。
這邊只單純討論 ES 存資料的空間計算。

估計 ES 硬碟空間要注意的項目:

  1. 主要資料
    ES 收到的內容及索引。

    注意!儲存的資料大小,不等於原始資料的大小。
    如果對資料加工不熟悉的話,建議在估計時 * 1.5 倍 當作彈性倍率

    • 原始資料若透過 Logstash 加工,產生了很多欄位,且保留原始內容,實際存放的大小就會比原始資料大很多,可能會多到一倍。
    • 若加工的欄位建的好,且加工完就拋棄原始內容,實際存放就會比原始資料更小。如圖:
      ELK 筆記 - 硬體規格評估 - Logstash 拋棄原始內容
  2. 副本資料
    主要資料的備援檔,大小與主要資料相等。
    若有兩個以上的節點,預設會建立一份副本,可變更副本數量。
    如果設定一份以上的副本,就會占用更多空間。
  3. 保留空間
    預設儲存資料只會使用硬碟空間的 85%,超過 85% 就不會在寫入資料到 ES。

預估硬碟空間公式如下:

主要資料 = 原始資料 * 1.5(彈性倍率)
節點硬碟需求 = 主要資料 * 1.15(保留空間) * (1 + 副本數量) / ES節點數量

假設預估每週產生 10 GB 的 Log,希望可以留 4 週,每個 ES 節點所需的硬碟空間:

  • 一台 ES

    10 GB * 4 * 1.5 * 1.15 * (1 + 0) / 1 ≒ 69 GB

  • 兩台 ES 做 Master/Slave 架構

    10 GB * 4 * 1.5 * 1.15 * (1 + 1) / 2 ≒ 70 GB

  • 三台 ES 做 Cluster 架構

    10 GB * 4 * 1.5 * 1.15 * (1 + 1) / 3 ≒ 46 GB

  • 五台 ES 做 Cluster 架構,建立三分副本

    10 GB * 4 * 1.5 * 1.15 * (1 + 3) / 5 ≒ 55 GB

參考

AlibabaCloudDocs - Elasticsearch 规格容量评估