使用 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 兆字节的单个单元格，那么在读取时可能会导致一些堆压力。
线程池状态
您可以使用 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 阶段的线程池的详细细分，包括当前正在执行的线程数（活动）和等待运行的线程数（挂起）。通常，如果您在特定线程池中看到挂起的执行，则表明该类型操作存在本地问题。例如，如果 RequestResponseState 队列正在积压，则意味着协调器正在等待大量下游副本请求，这可能表明缺乏令牌感知，或者在读取请求中使用了非常高的一致性级别（例如，在 ALL 处读取会占用 RF RequestResponseState 线程，而 LOCAL_ONE 仅使用 ReadStage 线程池中的单个线程）。另一方面，如果您看到大量挂起的压缩，这可能表明您的压缩线程无法跟上写入量，您可能需要调整压缩策略或 concurrent_compactors 或 compaction_throughput 选项。
第二部分显示了所有主要请求类型的丢弃（错误）和延迟分布。丢弃自进程启动以来是累积的，但是，如果您有任何丢弃表明存在严重问题，因为默认的超时时间（以资格为丢弃）非常高（约 5-10 秒）。丢弃的消息通常需要进一步调查。
压缩状态
由于 Cassandra 是 LSM 数据存储，因此 Cassandra 有时需要将 sstable 压缩在一起，这会对性能产生不利影响。特别是，压缩会消耗相当数量的 CPU 资源，使大量操作系统 页面缓存 无效，并可能给磁盘驱动器带来很大负载。有一些很棒的 os 工具 <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 兆字节，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。
