使用 Nodetool
Cassandra 的 nodetool 讓您可以將叢集問題縮小到特定節點，並深入了解 Cassandra 程序本身的狀態。有數十個有用的指令（請參閱 nodetool help 以取得所有指令），但以下簡要說明一些最有用於疑難排解的指令
叢集狀態
您可以使用 nodetool status 評估叢集狀態
$ nodetool status <optional keyspace>
Datacenter: dc1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 127.0.1.1 4.69 GiB 1 100.0% 35ea8c9f-b7a2-40a7-b9c5-0ee8b91fdd0e r1
UN 127.0.1.2 4.71 GiB 1 100.0% 752e278f-b7c5-4f58-974b-9328455af73f r2
UN 127.0.1.3 4.69 GiB 1 100.0% 9dc1a293-2cc0-40fa-a6fd-9e6054da04a7 r3在這個案例中，我們可以看到我們在一個資料中心中有三個節點，每個節點約有 4.6GB 的資料，而且它們都「正常」。節點的正常/異常狀態是由叢集中的每個節點獨立確定的，因此您可能必須在叢集中的多個節點上執行 nodetool status 才能看到完整檢視。
您可以使用 nodetool status 加上一些 grep 來查看哪些節點異常
$ nodetool status | grep -v '^UN'
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
DN 127.0.0.5 105.73 KiB 1 33.3% df303ac7-61de-46e9-ac79-6e630115fd75 r1在這個案例中有兩個資料中心，其中一個節點在資料中心 dc2 和機架 r1 中異常。這可能表示 127.0.0.5 上的問題需要調查。
協調器查詢延遲
您可以使用 nodetool proxyhistograms 查看協調器讀取和寫入延遲的延遲分佈，以協助縮小延遲問題
$ nodetool proxyhistograms
Percentile Read Latency Write Latency Range Latency CAS Read Latency CAS Write Latency View Write Latency
(micros) (micros) (micros) (micros) (micros) (micros)
50% 454.83 219.34 0.00 0.00 0.00 0.00
75% 545.79 263.21 0.00 0.00 0.00 0.00
95% 654.95 315.85 0.00 0.00 0.00 0.00
98% 785.94 379.02 0.00 0.00 0.00 0.00
99% 3379.39 2346.80 0.00 0.00 0.00 0.00
Min 42.51 105.78 0.00 0.00 0.00 0.00
Max 25109.16 43388.63 0.00 0.00 0.00 0.00在這裡，您可以看到讀取、寫入、範圍要求（例如 select * from keyspace.table）、CAS 讀取（CAS 的比較階段）和 CAS 寫入（比較和設定的設定階段）的完整延遲分佈。這些對於縮小高階延遲問題很有用，例如，在這個案例中，如果客戶端在讀取時有 20 毫秒的逾時，他們可能會偶爾從這個節點逾時，但少於 1%（因為 99% 的讀取延遲為 3.3 毫秒 < 20 毫秒）。
本機查詢延遲
如果您知道哪個表格有延遲/錯誤問題，可以使用 nodetool tablehistograms 來更深入了解節點上發生什麼事
$ nodetool tablehistograms keyspace table
Percentile SSTables Write Latency Read Latency Partition Size Cell Count
(micros) (micros) (bytes)
50% 0.00 73.46 182.79 17084 103
75% 1.00 88.15 315.85 17084 103
95% 2.00 126.93 545.79 17084 103
98% 2.00 152.32 654.95 17084 103
99% 2.00 182.79 785.94 17084 103
Min 0.00 42.51 24.60 14238 87
Max 2.00 12108.97 17436.92 17084 103這會顯示百分比細分，特別是關鍵指標。
第一個欄位包含每個邏輯讀取讀取的 sstable 數量。如果這裡的數字很高，表示您可能選擇錯誤的壓縮策略，例如 SizeTieredCompactionStrategy 通常比 LeveledCompactionStrategy 的每個讀取讀取更多，用於更新繁重的負載。
第二個欄位顯示 本機 寫入延遲的延遲細分。在這個案例中，我們看到 p50 在 73 微秒時相當好，但最大延遲在 12 毫秒時相當慢。高寫入最大延遲通常表示提交記錄磁碟區速度慢（fsync 速度慢）或大型寫入會快速填滿提交記錄區段。
第三個欄位顯示 本機 讀取延遲的延遲細分。我們可以看到，本機 Cassandra 讀取（如預期）比本機寫入慢，而且讀取速度與每個讀取讀取的 sstable 數量高度相關。
第四和第五個欄位顯示每個分區的分區大小和欄位數量的分配。這些欄位有助於判斷表格平均而言是瘦分區還是寬分區，而且可以協助您找出不良資料模式。例如，如果您有一個 2 MB 的單一儲存格，這可能會在讀取時造成一些堆積壓力。
執行緒池狀態
您可以使用 nodetool tpstats 來檢視特定節點上目前未完成的要求。這有助於找出 Cassandra 程序缺乏哪個資源（讀取執行緒、寫入執行緒、壓縮、要求回應執行緒）。例如
$ nodetool tpstats
Pool Name Active Pending Completed Blocked All time blocked
ReadStage 2 0 12 0 0
MiscStage 0 0 0 0 0
CompactionExecutor 0 0 1940 0 0
MutationStage 0 0 0 0 0
GossipStage 0 0 10293 0 0
Repair-Task 0 0 0 0 0
RequestResponseStage 0 0 16 0 0
ReadRepairStage 0 0 0 0 0
CounterMutationStage 0 0 0 0 0
MemtablePostFlush 0 0 83 0 0
ValidationExecutor 0 0 0 0 0
MemtableFlushWriter 0 0 30 0 0
ViewMutationStage 0 0 0 0 0
CacheCleanupExecutor 0 0 0 0 0
MemtableReclaimMemory 0 0 30 0 0
PendingRangeCalculator 0 0 11 0 0
SecondaryIndexManagement 0 0 0 0 0
HintsDispatcher 0 0 0 0 0
Native-Transport-Requests 0 0 192 0 0
MigrationStage 0 0 14 0 0
PerDiskMemtableFlushWriter_0 0 0 30 0 0
Sampler 0 0 0 0 0
ViewBuildExecutor 0 0 0 0 0
InternalResponseStage 0 0 0 0 0
AntiEntropyStage 0 0 0 0 0
Message type Dropped Latency waiting in queue (micros)
50% 95% 99% Max
READ 0 N/A N/A N/A N/A
RANGE_SLICE 0 0.00 0.00 0.00 0.00
_TRACE 0 N/A N/A N/A N/A
HINT 0 N/A N/A N/A N/A
MUTATION 0 N/A N/A N/A N/A
COUNTER_MUTATION 0 N/A N/A N/A N/A
BATCH_STORE 0 N/A N/A N/A N/A
BATCH_REMOVE 0 N/A N/A N/A N/A
REQUEST_RESPONSE 0 0.00 0.00 0.00 0.00
PAGED_RANGE 0 N/A N/A N/A N/A
READ_REPAIR 0 N/A N/A N/A N/A此命令會顯示各類有趣的統計資料。第一個區段會顯示每個 Cassandra 階段的執行緒集詳細細目，包括目前執行中 (Active) 的執行緒數目和等待執行的執行緒數目 (Pending)。通常，如果在特定執行緒集中看到有待處理的執行，表示該類型作業發生問題。例如，如果 RequestResponseState佇列備份，表示協調器正在等待許多下游複本要求，而且可能表示缺乏令牌感知，或讀取要求使用非常高的一致性層級 (例如，在 ALL 讀取會綁定 RF RequestResponseState執行緒，而 LOCAL_ONE 只會在 ReadStage 執行緒集中使用單一執行緒)。另一方面，如果您看到許多待處理壓縮，這可能表示您的壓縮執行緒無法跟上寫入量，您可能需要調整壓縮策略或 concurrent_compactors 或 compaction_throughput 選項。
第二個區段會顯示所有主要要求類型的中斷 (錯誤) 和延遲分佈。中斷會從程序啟動後累計，但如果您有任何中斷表示嚴重問題，因為符合中斷資格的預設逾時時間相當高 (~5-10 秒)。中斷訊息通常需要進一步調查。
壓縮狀態
由於 Cassandra 是 LSM 資料儲存，因此 Cassandra 有時必須將 sstable 壓縮在一起，這可能會對效能產生負面影響。特別是，壓縮會使用合理的 CPU 資源數量，使大量作業系統 頁面快取失效，而且會對您的磁碟機造成大量負載。有許多很棒的 作業系統工具 <os-iostat> 可以判斷是否為這種情況，但通常使用 nodetool compactionstats 檢查壓縮是否正在執行會是個好主意
$ nodetool compactionstats
pending tasks: 2
- keyspace.table: 2
id compaction type keyspace table completed total unit progress
2062b290-7f3a-11e8-9358-cd941b956e60 Compaction keyspace table 21848273 97867583 bytes 22.32%
Active compaction remaining time : 0h00m04s在這種情況下，有一個單一壓縮在 keyspace.table 表格上執行，已完成 97 個 21.8 MB，而且 Cassandra 估計 (根據設定的壓縮處理量) 這將需要 4 秒。您也可以傳遞 -H 以人類可讀格式取得單位。
一般而言，每個執行中的壓縮都能消耗一個核心，但並行執行的次數越多，資料壓縮的速度就越快。壓縮對於確保良好的讀取效能至關重要，因此，並行壓縮的正確平衡非常重要，讓壓縮能快速完成，但不會從查詢執行緒中耗用過多資源。如果您發現壓縮無法跟上，請嘗試調整 Cassandra 的 concurrent_compactors 或 compaction_throughput 選項。
資料檔案使用的路徑
Cassandra 會在已設定的目錄中將資料儲存在磁碟中。資料檔案會分佈在使用 data_file_directories 設定的目錄中。Cassandra 會在 data_file_directories 中建立子目錄，類似於鍵空間和資料表的結構。不過，即使刪除資料表和鍵空間，目錄也不會被移除。雖然保留這些目錄的目的是為了保留快照，但它們會被移除。這時，操作員需要知道哪些目錄仍在使用中。執行 nodetool datapaths 指令是列出 Cassandra 實際上在磁碟上儲存 sstable 資料的目錄的簡單方法。
% nodetool datapaths -- system_auth
Keyspace: system_auth
Table: role_permissions
Paths:
/var/lib/cassandra/data/system_auth/role_permissions-3afbe79f219431a7add7f5ab90d8ec9c
Table: network_permissions
Paths:
/var/lib/cassandra/data/system_auth/network_permissions-d46780c22f1c3db9b4c1b8d9fbc0cc23
Table: resource_role_permissons_index
Paths:
/var/lib/cassandra/data/system_auth/resource_role_permissons_index-5f2fbdad91f13946bd25d5da3a5c35ec
Table: roles
Paths:
/var/lib/cassandra/data/system_auth/roles-5bc52802de2535edaeab188eecebb090
Table: role_members
Paths:
/var/lib/cassandra/data/system_auth/role_members-0ecdaa87f8fb3e6088d174fb36fe5c0d預設會列出所有鍵空間和資料表，不過，可以提供 keyspace 和 keyspace.table 引數清單來查詢特定資料路徑。使用 --format 選項，可以將輸出格式化為 YAML 或 JSON。
