Lindorm：監控警示最佳實務

CPU與負載

該模組用於監控系統的CPU使用率與負載，包含指標：CPU利用率、CPU WIO使用率、CPU空閑率、平均負載。其中CPU使用率包括使用者使用率（User）和系統使用率（System）。

在設定警示規則時，建議您根據業務特性和對延遲的敏感程度來設定CPU空閑率（%）的警示值。通常情況下，CPU利用率的升高會導致回應時間的增加，但不同性質的業務受影響的程度不同。例如，當CPU利用率超過40%時線上型業務的響應可能會受到影響，而對於部分離線型業務，即使CPU利用率達到100%其業務運行也不會受到影響。因此，建議您根據業務自身情況來合理設定警示值。當CPU使用率過高時，可以通過擴容或升配來滿足業務需求。如何擴容或升配，請參見管理儲存空間和變更執行個體配置。

CPU WIO使用率(%)表示CPU在等待IO操作時所佔用的時間比例，該指標過高表示讀寫磁碟遇到瓶頸。在判斷機器的健康狀態時，可以將CPU WIO使用率(%)和每分鐘平均負載(load1)（下文簡稱Load指標）一起分析。Load指標綜合了CPU利用率和磁碟使用率。

機器可以承受的負載通常與其CPU配置相關。例如購買的機器CPU為8核，當Load指標的值大於8即意味著CPU的處理開始排隊，機器處於亞健康狀態。如果CPU利用率不高，但Load指標偏高，則代表磁碟的使用率過高。當CPU負載過高或WIO使用率過高時，建議您擴容或者升配，以免影響業務。

網路和磁碟

該模組用於監控機器的網路和磁碟情況。您需要關注機器的網路流量、磁碟讀寫情況和IOPS指標，避免其超過ECS執行個體和雲端硬碟的限流閾值。

不同規格的ECS執行個體具備不同的網路頻寬，網路的限流閾值請參見執行個體規格類型系列。磁碟的限流閾值請參見Block Storage效能。如果對網路和磁碟限制有疑問，請聯絡Lindorm支援人員（DingTalk號：s0s3eg3）為您解答。

非本地碟機型的ECS雲端硬碟存在總頻寬上限，如果讀加寫的流量超過ECS雲端硬碟頻寬，也會出現限流導致業務受損。在使用過程中，您需要密切關注磁碟和網路使用方式，防止超出底層機器的網路或磁碟限制。

叢集負載

叢集負載指標主要監控以下幾項：

• 寬表計算節點記憶體使用量比率(%)：表示寬表引擎當前堆記憶體已使用的比率。如果堆的使用比率長期過高，可能會導致寬表引擎OOM或Full GC，進而影響業務。堆記憶體大小是會波動的，如果您臨時過度使用了堆記憶體，系統將通過記憶體回收（GC）等方式使堆的大小自然下降。當堆記憶體大小持續超過某個閾值時，需要進行關注。因此，當該數值過高時，建議升級寬表節點的規格，以增大記憶體。在配置警示規則時，建議將規則配置為：該比率大於85%~90%且持續30~60分鐘後警示。如何升級規格，請參見變更執行個體規格。

• RS的region數(個)：每個寬表節點上的資料分區個數。寬表引擎會把表按範圍切片並分布到各個機器上，由master統一管理分配。每個分區（Region）都會佔用中繼資料記憶體空間，因此Region數量過多會導致機器記憶體不足。您需要控制Region的數量，例如減少表的數量、減少建表時預分區的個數。

  以下是不同配置下，單個機器的Region個數建議：

  機器配置（記憶體大小）	單機建議的分區個數
  8 GB	< 500
  16 GB	< 1000
  32 GB	< 2000
  64 GB	< 3000
  128 GB	< 5000

  以上數值僅供參考，實際使用時您可以通過寬表計算節點記憶體使用量量 / 寬表計算節點記憶體總量來判斷執行個體是否存在記憶體不足的問題。

• HandlerQueue長度(個)：表示伺服器上請求排隊的情況。如果HandlerQueue長度大於0，則表示請求在伺服器上需排隊處理，預示著伺服器資源無法承載當前請求量，因此無法及時處理請求，建議您升級執行個體配置來增加CPU資源。

• Compaction隊列長度(個)：表示伺服器上Compaction任務的排隊情況。當寫入量增多時，需要執行的Compaction操作會隨之增多，可能會出現需要排隊執行的現象。

  說明

  • Compaction隊列長度大於0不代表執行個體一定處於不健康狀態。假設業務的寫入高峰和寫入低穀有比較明顯的周期，白天寫入高峰，晚上寫入低穀，那麼白天Compaction任務可能存在積壓（即Compaction隊列長度大於0），但在晚上的業務低穀期，系統將自動處理這些積壓的任務，此時Compaction隊列長度會減少到0，這說明執行個體是健康的。此外，如果Compaction隊列長度長期穩定在某一個值，表示執行個體處於穩定點，無需關注。

  • 如果Compaction隊列長度持續上漲且沒有下降趨勢，說明執行個體資源不足，需要增加節點或升級配置來增加CPU資源，以便及時處理Compaction任務。Compaction任務的積壓在短時間內不會影響業務，但長期積壓會導致分區內檔案過多，可能會影響讀RT。如果檔案數量持續增長可能會出現反壓寫現象，導致寫入RT增加甚至逾時。

• Region的平均檔案數：表示分區內平均檔案的個數，數量越多，讀RT越大。每個檔案中繼資料都會佔用記憶體，如果檔案總數過多可能導致Full GC或OOM。

• Region的最大檔案數：Lindorm對單個Region內的檔案數量存在限制，如果超過該限制會出現反壓寫現象導致寫逾時。具體限制說明，請參見資料請求的限制。

讀請求

主要包含以下幾類監控項：

• Get監控項：包括Get請求量(個/秒)、Get平均RT(毫秒)、Get P99 RT(毫秒)三項。該監控項是指根據完整的主鍵資訊，在Lindorm伺服器執行一次點查調用，擷取相關的監控指標，包括QPS，平均RT和P99 RT。如果您使用了BatchGet操作，無論BatchGet操作中包含多少行，都只會被視為一次點查調用。由於BatchGet操作是在單個伺服器上以串列方式執行，因此如果僅使用了BatchGet操作，或同時使用了BatchGet操作和單行Get操作，平均RT的值會高於單行Get操作的RT。

• Scan監控項：包括Scan請求量(個/秒)、Scan平均RT(毫秒)、Scan P99 RT(毫秒)三項。該監控項用於監控範圍掃描操作（Scan請求）的相關指標。Lindorm伺服器會將大範圍的Scan請求拆分並以流式的方式返回，Scan請求量(個/秒)和Scan平均RT(毫秒)分別指將Scan請求拆分後，每秒發送到伺服器的掃描子調用數量和每個掃描操作的平均耗時，因此Scan請求量(個/秒)顯示的Scan請求的數量可能會比實際使用時發起的Scan請求數量多。同時，完整Scan請求的耗時也由多個子掃描請求的耗時組成。

• 讀監控項：包括讀請求量(個/秒)、讀平均RT(毫秒)、讀流量三項。該監控項同時包含了Get和Scan請求的監控項，用於統計執行個體每秒返回多少行資料、返回每行資料的平均耗時。Get請求和Scan請求可能一次請求返回多行，因此該監控項能夠更真實地反映執行個體的讀吞吐。

寫請求

• 寫流量：該監控項用於監控寫入寬表引擎的流量吞吐，單位為KB/s。寬表寫入底層儲存時，寬表的列會被轉化為索引值對（KeyValue）形式，因此寫入的列相比於業務實際寫入的列更多，資料量更大。建議您通過該指標來判斷Lindorm寬表引擎的寫入吞吐。

  寫入吞吐過大，可能會導致Compaction任務積壓，進而影響執行個體的穩定性，請您根據業務需求綜合考慮並選擇合適的CPU配置。

  以下是不同配置下的寫入吞吐參考：

  CPU配置	建議的寫入吞吐
  4核	< 5 MB/s
  8核	< 10 MB/s
  16核	< 30 MB/s
  32核	< 60 MB/s

  以上值僅供參考，實際使用時您可以進一步結合Compaction隊列長度、Region的平均檔案數以及Region的最大檔案數來綜合考慮。

• 超過Memstore上限次數(次)：Lindorm寬表在寫入時會先將資料寫入對應Region的記憶體緩衝（Memstore）中，當Memstore過大時，系統將觸發一次Flush操作將資料刷寫到磁碟上。如果業務的寫入熱點過於集中，寫入請求集中在某幾個Region上，就會造成這些Region的Memstore過大，會導致出現反壓寫現象，從而影響寫吞吐。因此當該指標大於0時，您需要考慮寫入是否存在熱點現象，或寫入TPS已經超過執行個體能夠承受的最大值導致來不及將資料刷寫至磁碟上。您可以通過Hash演算法將主鍵打散，避免熱點的產生。更多介紹，請參見如何設計寬表主鍵。