統一觀測丨使用 Prometheus 監控 Cassandra 資料庫最佳實踐

作者：元格

本篇內容主要包括四部分：Cassandra 概覽介紹、常見關鍵指標解讀、常見告警規則解讀、如何通過 Prometheus 建立相應監控體系。

Cassandra 簡介

Cassandra 是什麼？ Apache Cassandra 是一個開源、分散式、去中心化、彈性可伸縮、高可用、容錯、可調一致性、面向行的資料庫。它的分散式設計基於 Amazon Dynamo，資料模型基於 Google BigTable。Cassandra 由 Facebook 建立，目前在 Facebook、Twitter、Apple、360 等各大 IT 企業成熟落地使用。

Cassandra 特點

大規模可延伸儲存

Cassandra 可延伸到數百 TB，以出色的效能執行在商用叢集上。

易於管理

Cassandra 群集易於大規模管理，並且可以隨需求的變化動態擴容。

高可用性

Cassandra 設計為「持續線上」並已支援零停機時間升級等功能，應用於生產環境已有十多年的歷史。

寫密集型應用

Cassandra 特別適合寫密集型應用的時序型資料，如時間序列流資料、感測器紀錄檔資料和物聯網應用程式等。

統計和分析

Cassandra 支援與 Spark 等巨量資料計算框架整合，使用者可以利用 Spark 強大的記憶體分析功能進行巨量資料統計和分析。

異地多活

Cassandra 支援異地多資料中心，資料可以跨多個雲和資料中心進行復製備份。

典型適用場景

Cassandra 是一個非常靈活的分散式 NoSQL 資料庫系統，適用於許多不同的場景。以下是 Cassandra 的適用場景的詳細描述：

1.巨量資料量、高寫入頻率的應用場景

Cassandra 的設計目標之一就是處理大規模資料集和高寫入頻率的應用場景，例如社交媒體、物聯網、實時資料分析等。Cassandra 能夠輕鬆地水平擴充套件，使得其能夠處理數百億行資料的工作負載，並支援快速的寫入和讀取操作。

2.高可用性和容錯性的應用場景

Cassandra 具有自動分割區、複製和故障轉移功能，因此非常適合需要高可用性和容錯性的應用場景，例如金融交易、線上遊戲等。Cassandra 的分散式體系結構確保了即使在節點故障的情況下，系統也能夠繼續執行，並保持一致性。

3.跨資料中心和地理位置的資料複製和同步的應用場景

Cassandra 支援多資料中心複製，因此能夠輕鬆地在不同的資料中心之間進行資料同步和資料備份。這使得 Cassandra 非常適合需要全球擴充套件的應用場景，例如線上廣告、電子商務等。

4.需要支援分散式事務的應用場景

Cassandra 通過支援輕量級事務來保證資料的一致性。這些事務能夠跨多個節點和多個資料中心，並且能夠在高吞吐量和低延遲的情況下執行。Cassandra 還支援分散式計數器，這使得它非常適合需要支援分散式事務的應用場景，例如金融交易。

5.需要靈活的資料模型，能夠支援多種查詢方式的應用場景
Cassandra 的靈活的資料模型和支援多種查詢方式的能力，使得它非常適合需要儲存和查詢靈活資料模型的應用場景，例如儲存時序資料、跟蹤訂單狀態等。Cassandra 還支援多種資料結構，例如集合、對映、列表等，這使得它非常適合儲存半結構化和非結構化資料。

雖然 Cassandra 非常適合許多應用場景，但也有一些情況下它可能不適合使用。以下是一些 Cassandra 不適合使用的場景：

對於小規模資料集和低寫入頻率的應用場景，Cassandra 可能會顯得過於複雜和冗餘。在這種情況下，使用傳統的關係型資料庫可能更加合適。
對於需要複雜資料模型和複雜查詢的應用場景，Cassandra 可能會限制查詢能力和靈活性，因為它不支援複雜的聯接操作和事務。在這種情況下，使用傳統的關係型資料庫或其他 NoSQL 資料庫可能更加合適。
對於需要嚴格的資料一致性和隔離級別的應用場景，Cassandra 的輕量級事務可能無法滿足要求。在這種情況下，使用傳統的關係型資料庫可能更加合適。
對於需要進行復雜分析和聚合的應用場景，Cassandra 可能不是最佳選擇，因為它不支援複雜的分析查詢和聚合操作。在這種情況下，使用專門的分析資料庫可能更加合適。

總之，Cassandra 適合處理大規模資料集和高寫入頻率的應用場景，但對於小規模資料集和複雜查詢、分析等場景可能不適合。 因此，在選擇資料庫時，需要根據具體的應用需求進行綜合考慮。

Cassandra 核心概念

1.Cassandra 節點（Cassandra Node）

Cassandra 節點是 Cassandra 叢集中的一個範例，它負責儲存一部分資料，處理讀寫請求，並與其他節點進行通訊。Cassandra 節點之間通過 Gossip 協定進行通訊，以維護節點狀態和拓撲。

2.Memtable（Memory Table）
Memtable 是一種類似於 SkipList 的記憶體結構，用於提高寫入效能。Memtable 是 Cassandra 在寫入過程中使用的臨時資料結構，用於儲存待寫入到磁碟中的資料。當 Memtable 已滿時，Cassandra 會將其中的資料寫入到磁碟中，並在記憶體中繼續寫入新資料。

3.Key Caches

Cassandra 在讀取資料時使用的快取，用於加速讀取操作。Key Cache 儲存在每個節點的記憶體中，快取最近使用的資料項，以便快速查詢和存取資料。Cassandra 使用雜湊表來儲存 key/value 資料，根據 LRU（Least Recently Used）演演算法來管理 Key Cache 中的資料項。當 Key Cache 已滿時，Cassandra 會將最近最少使用的資料項從 Key Cache 中移除以釋放空間。

4.Row Caches

Row Cache 是一種記憶體快取，用於儲存 Cassandra 中的行級資料。Row Cache 是 Cassandra 在讀取資料時使用的快取，用於加速讀取操作。Row Cache 儲存在每個節點的記憶體中，快取最近使用的行級資料，以便快速查詢和存取資料。與 Key Cache 和 Memtable 不同，Row Cache 快取的是完整的行級資料，而不是其中的 key/value 資料。

5.Commit Logs

Commit Logs 機制實際上就是 Cassandra 中實現 WAL（Write Ahead Log）機制的方式之一，用於在寫入資料時保證資料的永續性和一致性。當 Cassandra 收到寫入請求時，它首先將資料寫入到記憶體中的 Memtable 中，並將資料追加到 Commit Logs 中。這樣可以保證在系統出現故障時，資料可以從 Commit Logs 中恢復到最後一次提交的狀態。

6.SSTable（Sorted String Table）

SSTable 是 Cassandra 中儲存資料的物理格式。每個 SSTable 是一個已排序的字串表，包含多個資料分割區的資料，並根據分割區鍵和列名進行排序。Cassandra 使用多個 SSTable 來儲存資料，並使用 BloomFilter 和索引來快速定位資料。

7.Hints

Hints 是 Cassandra 中一種機制，用於在節點故障時保證資料的一致性和可靠性。當節點無法響應寫入請求時，Cassandra 會將這些請求儲存在 Hints 中，並在節點恢復後重新嘗試處理這些請求。Hints 機制可以提高系統的可靠性，但可能會對效能產生影響。

8.Tombstone

在 Cassandra 中，刪除操作實際上是一種「寫入」操作，Cassandra 會將要刪除的資料標記為Tombstone。Tombstone 是一種特殊的資料型別，它包含了要刪除資料的資訊（如表名、鍵名、時間戳等），並在磁碟上佔據一定的空間。當讀取資料時，Cassandra 會檢查 Tombstone，如果資料被標記為 Tombstone，則視為已刪除，不會返回給使用者端。

9.Bloom filter

在 Cassandra 中，Bloom Filter 主要用於查詢 Memtable 和 SSTable中的資料是否存在，是 Cassandra 中的一種用於快速查詢資料存在性的機制，用於在讀取操作時加速查詢資料。當 Cassandra 需要查詢資料時，它會首先查詢 Bloom Filter，如果資料不存在於 Bloom Filter中，則可以直接跳過讀取操作，因為資料一定不存在於 Memtable 和 SSTable 中。如果資料可能存在於 SSTable 中，則繼續讀取 SSTable 中的資料進行驗證。

監控關鍵指標

這裡以阿里雲的 Cassandra 元件為例，介紹監控 Cassandra 服務中常見的關鍵指標。

基礎資訊

1.CPU / 記憶體 / 硬碟使用率

Cassandra 作為一個高吞吐量、低延遲的分散式資料庫，需要充分利用節點的硬體資源來提供高效能的資料儲存和查詢服務，如果節點的資源使用超過了預期或者達到了極限，可能會導致效能下降或者系統崩潰，影響業務的正常執行。因此我們首先需要關注節點實時的 CPU / 記憶體 / 硬碟使用率，以確保 Cassandra 服務執行的穩定性。

2.使用者端連線數

連線到當前 Cassandra 伺服器端的使用者端連線數量也是需要監控的指標之一。使用者端連線數表示當前正在與 Cassandra 叢集進行通訊的使用者端數量，如果連線數過高可能會導致叢集出現資源不足的情況，從而影響系統的效能和可用性。特別是在高並行情況下，使用者端連線數的監控和優化顯得尤為重要。如果連線數過高，可以通過優化節點設定、增加節點數量等手段來緩解壓力，從而保證系統的高可用和高效能。

3.Cassandra 資料量

Cassandra 作為一個資料庫，其資料量也是需要緊密關注的監控資料之一。Cassandra 支援海量資料的儲存和查詢，因此在實際應用中，其資料量通常會不斷增長。如果資料量過大，可能會導致節點出現資源不足、查詢效能下降等問題，從而影響業務的正常執行。因此，對 Cassandra 叢集的資料量進行監控和優化，可以幫助我們更好地管理和維護 Cassandra 叢集。監控資料量可以通過監測磁碟使用情況、分散式儲存的資料分佈情況等指標來實現。如果資料量過大，可以考慮增加節點數量、升級硬體設定、進行資料遷移等措施來緩解壓力，從而提高系統的可用性和效能。

4.使用者端讀寫分佈比例

最後，我們推薦監控的一個指標是使用者端的讀寫分佈比例，Cassandra 是一個支援高吞吐量、低延遲的分散式資料庫，通常用於儲存大量的讀寫資料。如果讀寫分佈比例不均衡，可能會導致叢集出現瓶頸，從而影響系統的效能和可用性。通過監控使用者端的讀寫分佈比例，我們可以及時發現問題，採取措施來優化叢集的讀寫效能。例如，可以通過增加節點數量、調整分割區策略、優化查詢語句等手段來實現優化。

讀寫延遲和吞吐量

Cassandra 作為資料庫服務，其讀寫延遲和吞吐量是我們必須要關注的指標之一。Cassandra 以其高吞吐量、低延遲的特點著稱，因此在實際應用中，讀寫延遲和吞吐量是衡量 Cassandra 叢集效能的重要指標。

1.讀寫延遲

讀寫延遲是 Cassandra 叢集效能的重要指標，如果讀寫延遲較高，則可能會導致系統響應時間長、節點之間資料同步慢影響資料一致性、節點出現高負載、系統出現瓶頸等問題。因此，保持讀寫延遲的合理水平是確保 Cassandra 叢集高可用和高效能的重要因素之一。如果發現讀寫延遲較高，運維人員可以通過關注其他監控資料來排查問題。讀寫延遲的增加可能是由多種因素導致的，例如快取/布隆過濾器/硬碟佔用等。因此，針對不同的問題，可以採取不同的排查和優化措施來提高叢集的效能和可用性。

2.吞吐量

讀寫吞吐量是反映當前 Cassandra 叢集每秒處理的讀寫請求次數的指標，如果吞吐量過高導致節點出現高負載，可能會影響系統的穩定性和可用性。高負載可能會導致節點出現瓶頸，從而影響系統的響應時間和可用性。因此，如果吞吐量過高，運維人員需要引起警惕，並採取有效的措施來緩解負載壓力，例如增加節點數量、修改路由策略等。

如果叢集效能較強，可以適當提高吞吐量的監控閾值，以反映叢集的實際效能水平。這樣可以更好地反映 Cassandra 叢集的效能和可用性，從而更好地支援業務需求。但需要注意的是，吞吐量的閾值不能過於樂觀，需要綜合考慮叢集的硬體效能、業務需求和系統特點等多個因素，以確保叢集的高可用和高效能。

快取和布隆過濾器

快取和布隆過濾器能夠直接顯著影響 Cassandra 資料庫的效能。快取可以提高查詢的效能和效率，減少對磁碟的讀取次數，從而提高系統的響應速度和吞吐量。如果快取命中率高，可以顯著提高 Cassandra 叢集的效能和可用性。布隆過濾器可以降低資料庫的查詢負載，通過減少不必要的查詢請求，提高叢集的吞吐量和效能。如果布隆過濾器的誤判率低，可以減少查詢的操作次數，從而提高叢集的效能和可用性。

我們推薦監控 Cassandra 服務中 key cache 命中率以及 Bloom filter 誤判率這兩項指標。

Key cache 命中率

Key cache 是 Cassandra 中的一種快取機制，用於儲存最常用的資料塊和索引資料。當應用程式請求資料時，Cassandra 首先會查詢 Key cache，如果資料塊或索引資料已經存在於 Key cache 中，則可以直接返回結果，避免了對磁碟的存取。因此，Key cache 的命中率直接反映 Cassandra 叢集的效能和效率。如果 Key cache 命中率較低，可能會導致 Cassandra 叢集響應時間變長，影響系統的效能和可用性。

Bloom filter 誤判率

Bloom filter 是 Cassandra 中用於快速查詢資料是否存在的一種資料結構。Bloom filter 雖能快速判斷資料是否存在，但會存在誤判的情況。Bloom filter 的誤判率反映了 Cassandra 叢集查詢資料的準確性和效率。如果 Bloom filter 誤判率較高，可能會導致 Cassandra 叢集查詢效率下降，從而影響系統的效能和可用性。

異常和錯誤

異常和錯誤是 Cassandra 服務中需要監控的核心指標之一，反映了系統的異常情況，例如節點宕機、資料丟失、網路故障等問題。當異常和錯誤指標非0時，通常意味著系統出現了問題，需要及時排查和解決。例如，如果節點宕機，可能需要重新啟動或替換節點，以恢復叢集的正常執行。如果資料丟失，可能需要採取資料恢復措施，以確保資料的完整性和可靠性。

在某些情況下，異常和錯誤指標可能會出現誤報或誤判的情況。例如，某些異常和錯誤可能只是暫時的，可以自動恢復，不需要進行手動干預。因此，在分析異常和錯誤指標時，也需要結合其他指標，例如讀寫延遲、吞吐量、CPU 和記憶體使用率等指標，來判斷和排查問題。

我們推薦監控異常請求，錯誤請求、dropped message 三項指標。

異常請求：異常請求指 Cassandra 叢集在處理讀寫請求時出現異常的情況，例如請求超時、請求被拒絕等等。異常請求的出現通常意味著 Cassandra 叢集出現了問題，需要及時排查和解決。因此，監控異常請求是確保 Cassandra 叢集高可用和高效能的關鍵指標之一。
錯誤請求：錯誤請求指 Cassandra 叢集在處理讀寫請求時出現錯誤的情況，例如請求的資料不存在、資料型別不匹配等等。錯誤請求的出現可能會影響 Cassandra 叢集的查詢效率和準確性，從而影響系統的效能和可用性。因此，監控錯誤請求也是 Cassandra 叢集監控的重要指標之一。
Dropped message：Dropped message 指在 Cassandra 叢集間節點之間進行通訊時出現丟失訊息的情況。Dropped message 的出現通常意味著 Cassandra 叢集間通訊出現異常，可能會影響叢集的可用性和效能。因此，監控 Dropped message 也是 Cassandra 叢集監控的重要指標之一。

硬體資源佔用

在 Cassandra 監控中，監控 CPU、記憶體、硬碟和網路的使用情況是比較重要的指標。在這個模組，我們可以深入挖掘這些指標的監控資料，以更好地瞭解 Cassandra 叢集的效能和可用性。

CPU 使用率：CPU 是 Cassandra 叢集的計算資源，CPU 使用率反映了叢集的計算負載情況。高 CPU 使用率可能會導致叢集響應變慢，影響系統的效能和可用性。因此，監控 CPU 使用率是確保 Cassandra 叢集高效能和高可用的重要指標之一。
記憶體使用率：記憶體是 Cassandra 叢集的重要資源，記憶體使用率反映了叢集的記憶體負載情況。高記憶體使用率可能會導致叢集出現高負載，影響系統的效能和可用性。因此，監控記憶體使用率也是 Cassandra 叢集監控的重要指標之一。
硬碟使用率：硬碟是 Cassandra 叢集的儲存資源，硬碟使用率反映了叢集儲存的負載情況。高硬碟使用率可能會導致叢集儲存壓力過大，影響系統效能和可用性。因此，監控硬碟使用率也是 Cassandra 叢集監控的重要指標之一。
網路使用率：網路是 Cassandra 叢集的通訊資源，網路使用率反映了叢集節點之間通訊的負載情況。高網路使用率可能會導致叢集通訊異常，影響系統的效能和可用性。因此，監控網路使用率也是 Cassandra 叢集監控的重要指標之一。

儲存佔用

Memtable、SSTable 和 Commit Log 是 Cassandra 服務中儲存資料的三部分，各自承擔著不同的作用，在Cassandra 讀寫操作中起到了重要作用，我們推薦對這三部分資料的儲存佔用情況進行監控。

Memtable 儲存佔用：對 Memtable 儲存佔用情況進行監控，可以及時發現叢集中寫入效能和效率的問題。如果Memtable 儲存佔用過大，可能會導致寫入效能下降，影響系統的效能和可用性。因此，監控 Memtable 儲存佔用情況能夠幫助運維人員及時採取措施，優化叢集的寫入效能和效率。
SSTable 儲存佔用：對 SSTable 儲存佔用情況進行監控，可以及時發現叢集中儲存容量不足的問題。如果 SSTable 儲存佔用過大，可能會導致儲存容量不足，從而影響系統的效能和可用性。因此，監控 SSTable 儲存佔用情況能夠幫助運維人員及時採取措施，增加叢集的儲存容量，確保叢集的高可用性和高效能。
Commit Log 儲存佔用：對 Commit Log 儲存佔用情況進行監控，能夠及時發現叢集中故障恢復問題。如果 Commit Log 儲存佔用過大，可能會導致故障恢復時間變長，影響系統的可靠性和穩定性。因此，監控 Commit Log儲存佔用情況能夠幫助運維人員及時採取措施，優化叢集的故障恢復能力，確保叢集的高可靠性和高可用性。

執行緒池狀態

我們推薦對 Cassandra 的執行緒池進行監控，分別統計 active task、blocked task 和 pending task 數量進行實時監控。

Active task：Active task 指正在執行中的任務數量。如果 Active task 數量過高，可能會導致執行緒池過載，影響系統的效能和可用性。
Blocked task：Blocked task 指正在等待獲取鎖的任務數量。如果 Blocked task 數量過高，可能會導致執行緒池阻塞，影響系統的效能和可用性。
Pending task：Pending task 指正在等待執行的任務數量。如果 Pending task 數量過高，可能會導致任務積壓，影響系統的效能和可用性。

通過監控這三項指標，可以及時發現執行緒池中的效能問題，從而採取相應的措施，優化執行緒池的效能和效率。同時，監控執行緒池也可以幫助運維人員及時發現執行緒池過載、阻塞和任務積壓等問題，從而確保 Cassandra 叢集的高可用和高效能。

JVM 監控

Cassandra 作為一個基於 Java 編寫的應用，在監控中也需要監控 JVM 相關的三項指標，分別是 JVM 應用吞吐率、JVM 垃圾回收時間和 JVM 記憶體使用情況。這些指標對於保障 Cassandra 的高可用和高效能非常重要。

JVM 應用吞吐率：JVM 的應用吞吐率是指 JVM 在單位時間內完成的任務數量，也就是吞吐量。高吞吐率表示 JVM 效能較好，反之則表JVM 效能較差。因此，監控 JVM 應用吞吐率可以在J VM 效能下降時及時發現問題，從而採取措施進行優化。
JVM 垃圾回收時間：JVM 垃圾回收時間是指 JVM 在進行垃圾回收時所需要的時間，高垃圾回收時間會導致JVM 效能下降。因此，監控 JVM 垃圾回收時間可以幫助運維人員及時發現垃圾回收過程中的效能問題，從而優化 JVM 效能。
JVM 記憶體使用情況：JVM 的記憶體使用情況是指 JVM 在執行過程中所佔用的記憶體大小。如果 JVM 記憶體使用過高，可能會導致記憶體溢位，影響系統的效能和可用性。因此，監控JVM的記憶體使用情況能夠幫助運維人員及時發現記憶體問題，從而採取措施進行優化。

關鍵告警規則

在對 Cassandra 進行告警規則設定時，我們推薦基於以上採集得到的指標，從以下幾個方面進行告警規則的設定，分別是叢集健康狀態、資源使用情況、讀寫延遲和吞吐量、異常和錯誤及 JVM，以下是一些推薦的告警規則。

叢集健康狀態

我們推薦對叢集中 Cassandra 宕機節點的比例進行監控，並根據需要靈活設定閾值。

在設定閾值時，需要考慮到 Cassandra 叢集的規模、硬體設定、資料負載以及業務需求等因素。一般來說，如果叢集中有多個節點，建議將宕機節點的比例控制在 5% 以下，如果叢集規模較小，則可以設定更嚴格的閾值。但是，需要注意的是，過於嚴格的閾值可能會導致誤報，過於寬鬆的閾值則可能會導致漏報。因此，在設定閾值時，需要根據實際情況進行調整和優化。

資源使用情況

在資源使用情況中，我們推薦對 Cassandra 叢集中各個節點的 CPU、記憶體以及硬碟使用率設定告警規則：

CPU使用率：建議設定 CPU 使用率的告警閾值，當節點的 CPU 使用率超過閾值時，可以發出告警通知相關人員及時處理，以防止 Cassandra 叢集進入不穩定狀態甚至出現宕機等問題，以保障 Cassandra 叢集的高可用和高效能。
記憶體使用率：建議設定記憶體使用率的告警閾值，當節點的記憶體使用率超過閾值時，可以發出告警通知相關人員及時處理，防止因記憶體不足導致系統崩潰。
硬碟使用率：建議設定硬碟使用率的告警閾值，當節點的硬碟使用率超過閾值時，可以發出告警通知相關人員及時處理，防止因磁碟空間不足導致資料丟失等問題。

讀寫延遲和吞吐量

Cassandra 作為一個資料庫服務，其讀寫延遲和吞吐量是極為重要的效能指標，因此都需要設定告警規則。

讀寫延遲：建議當讀寫延遲超過一定閾值時觸發告警規則。在 Cassandra 叢集中，讀寫延遲是一個非常重要的效能指標，當讀寫延遲超過一定閾值時，往往會導致應用程式響應變慢，甚至造成資料丟失，因此需要對其進行監控和告警。在設定讀寫延遲的告警規則時，需要根據實際情況進行調整和優化。一般來說，可以設定較短的閾值，例如1秒或更短的時間。當讀寫延遲超過設定的閾值時，就會觸發告警，通知相關人員及時處理問題。此外，也可以根據業務需求和資料負載進行調整，以便儘可能地滿足應用程式的需求。
吞吐量：吞吐量反映了 Cassandra 服務當前單位時間內處理的請求數量，過高的吞吐量可能會導致系統進入不穩定狀態，甚至出現宕機的情況。當 Cassandra 叢集的吞吐量過高時，會導致系統資源的緊張，例如 CPU、記憶體和磁碟等資源可能會達到瓶頸，從而影響系統的穩定性和可用性。此外，過高的吞吐量還可能會導致資料的一致性問題，例如因寫入衝突而產生的資料丟失等問題。因此，我們建議對 Cassandra 叢集的吞吐量設定相應的告警規則，以便及時發現和處理過高的吞吐量問題。在設定告警規則時，需要根據實際情況進行調整和優化，例如根據業務需求和資料負載進行調整，以儘可能地滿足應用程式的需求。

異常和錯誤

當 Cassandra 服務中出現異常和錯誤時，需要引起警惕。Cassandra 是一個分散式的資料庫系統，異常和錯誤可能會對資料的一致性和可用性造成很大影響，因此需要對其進行監控和處理。

我們推薦對超時請求、失敗請求以及 Dropped Message 三種異常和錯誤情況設定告警規則。這些異常和錯誤可能會影響 Cassandra 叢集的可用性和效能，因此需要對其進行監控和處理。

超時請求：當 Cassandra 服務無法在指定的時間內響應請求時，就會出現超時請求的情況。超時請求可能會導致使用者端無法獲取所需的資料，影響系統的可用性和效能。因此，我們建議對超時請求進行監控，並設定相應的告警規則，以便及時發現和處理問題。
失敗請求：當 Cassandra 服務無法成功完成請求時，就會出現失敗請求的情況。失敗請求可能會導致資料的不一致性，影響系統的可用性和效能。因此，我們建議對失敗請求進行監控，並設定相應的告警規則，以便及時發現和處理問題。
Dropped Message：Cassandra 叢集中的訊息可能會丟失，例如由於網路問題或節點故障等原因。這些丟失的訊息可能會導致資料的不一致性，影響系統的可用性和效能。因此，我們建議對 Dropped Message 進行監控，並設定相應的告警規則，以便及時發現和處理問題。

JVM 相關

我們推薦對 Cassandra 服務中 GC 的時間佔比設定告警規則。頻繁的 GC 操作可能會對應用程式的效能產生很大影響，因此需要對其進行監控和處理。

在 Cassandra中，GC（Garbage Collection）是一項重要的操作，用於回收無用的記憶體。當 GC 操作頻繁出現時，可能會佔用大量的 CPU 時間，影響系統的效能和可用性。因此，我們建議對 Cassandra 服務中 GC 的時間佔比進行監控，並設定相應的告警規則，以便及時發現和處理問題。

在設定告警規則時，需要根據實際情況進行調整和優化。一般來說，可以設定較短的 GC 時間佔比閾值，例如10%或更短的時間。當 GC 時間佔比超過設定的閾值時，就會觸發告警，通知相關人員及時處理問題。

監控體系搭建

自建 Prometheus 監控

目前廣泛採用的 Cassandra 監控方案主要是基於 JMX 的監控方案。使用者可以選擇自行編寫或者從開源社群選擇合適的 Agent，然後在 Cassandra 服務啟動時掛載對應的 Agent，實現對 Cassandra 叢集的監控。

在掛載了對應的 agent 之後，使用者需要在自建的 Prometheus 中註冊服務，然後基於 Grafana 等工具客製化 Cassandra監控大盤。

上在自建 Cassandra 監控方案中，可能會遇到一些問題和挑戰。以下是一些可能會出現的問題和挑戰：

社群的 Agent 質量良莠不齊：在開源社群中，有很多 Cassandra 監控 Agent 可供選擇。但這些 Agent 質量和效能可能不盡相同。有些 Agent 可能存在 Bug 或效能問題，可能會影響 Cassandra 叢集的效能和可用性。
指標缺乏解釋：在監控 Cassandra 時，需要監控很多指標。但是，這些指標的含義和解釋可能並不清晰，需要運維人員對其進行解釋和理解。如果缺乏指標的解釋，可能會導致運維人員對 Cassandra 叢集的狀態和效能理解不全面，無法及時發現問題。
自建的大盤不夠專業：在自建 Cassandra 監控大盤時，需要對資料進行處理和視覺化。但是，如果缺乏專業的技術和工具，可能會導致自建的大盤不夠專業，無法滿足運維人員的需求。

為了避免這些問題和挑戰，我們推薦使用阿里雲可觀測監控 Prometheus 版去監控 Cassandra 資料庫，真正做到開箱即用，一鍵整合。