深入探究，使用外部工具

機器存取允許操作員比記錄和 nodetool 允許更深入地探究。雖然每個 Cassandra 操作員可能都有自己偏好的疑難排解工具組，但此頁面包含一些最常見的操作員技術和這些工具的範例。其中許多命令只在 Linux 上執行，但如果您在不同的作業系統上部署，您可能可以使用其他相當類似的工具來評估類似的作業系統層級指標和程序。

JVM 工具

JVM 附帶許多有用的工具。其中一些工具可協助除錯 Cassandra 問題，特別是與堆疊和執行堆疊相關的問題。

注意：JVM 工具和 Cassandra 有兩個常見的陷阱

Cassandra 預設附帶 -XX:+PerfDisableSharedMem，以防止長時間暫停（有關詳細資訊，請參閱 CASSANDRA-9242 和 CASSANDRA-9483）。如果您想要使用 JVM 工具，您可以改將 /tmp 安裝在記憶體中的 tmpfs 上，這也可以有效解決 CASSANDRA-9242。
請務必以 Cassandra 執行的相同使用者身分執行這些工具，例如，如果資料庫以 cassandra 身分執行，則也必須以 cassandra 身分執行該工具，例如，透過 sudo -u cassandra <cmd>。

垃圾收集狀態 (jstat)

如果您懷疑堆疊壓力，您可以使用 jstat 深入探究 Cassandra 程序的垃圾收集狀態。這個命令總是安全執行，並會產生詳細的堆疊資訊，包括 Eden 堆疊使用量 (E)、舊世代堆疊使用量 (O)、Eden 收集次數 (YGC)、在 Eden 收集中花費的時間 (YGCT)、舊/混合世代收集 (FGC) 和在舊/混合世代收集中花費的時間 (FGCT)

jstat -gcutil <cassandra pid> 500ms
 S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
 0.00   0.00  81.53  31.16  93.07  88.20     12    0.151     3    0.257    0.408
 0.00   0.00  82.36  31.16  93.07  88.20     12    0.151     3    0.257    0.408
 0.00   0.00  82.36  31.16  93.07  88.20     12    0.151     3    0.257    0.408
 0.00   0.00  83.19  31.16  93.07  88.20     12    0.151     3    0.257    0.408
 0.00   0.00  83.19  31.16  93.07  88.20     12    0.151     3    0.257    0.408
 0.00   0.00  84.19  31.16  93.07  88.20     12    0.151     3    0.257    0.408
 0.00   0.00  84.19  31.16  93.07  88.20     12    0.151     3    0.257    0.408
 0.00   0.00  85.03  31.16  93.07  88.20     12    0.151     3    0.257    0.408
 0.00   0.00  85.03  31.16  93.07  88.20     12    0.151     3    0.257    0.408
 0.00   0.00  85.94  31.16  93.07  88.20     12    0.151     3    0.257    0.408

在這種情況下，我們看到我們有一個相對健康的堆配置檔，其中 31.16% 為舊生代堆使用率，而 Eden 為 83%。如果舊生代通常高於 75%，那麼您可能需要更多堆（假設 CMS 的佔用率閾值為 75%）。如果您確實有如此持續的高舊生代，這通常表示您要麼低估了舊生代堆，要麼 Cassandra 要收集的堆上活動數據太多（例如，因為記憶表）。另一件需要注意的是年輕垃圾回收 (YGC) 之間的時間，這表示 Eden 堆收集的頻率。每次年輕 GC 暫停約為 20-50 毫秒，因此如果您有許多這樣的暫停，您的客戶會在他們的高百分位數延遲中注意到。

執行緒資訊 (jstack)

若要取得 Cassandra 正在執行之內容的即時快照，請針對 Cassandra PID 執行 jstack。請注意，這會暫停 JVM 一段非常短暫的時間 (<20 毫秒)。

$ jstack <cassandra pid> > threaddump

# display the threaddump
$ cat threaddump

# look at runnable threads
$grep RUNNABLE threaddump -B 1
"Attach Listener" #15 daemon prio=9 os_prio=0 tid=0x00007f829c001000 nid=0x3a74 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
--
"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x00007f82e800e000 nid=0x2a19 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
--
"JPS thread pool" #10 prio=5 os_prio=0 tid=0x00007f82e84d0800 nid=0x2a2c runnable [0x00007f82d0856000]
   java.lang.Thread.State: RUNNABLE
--
"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x00007f82e80d7000 nid=0x2a2a runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
--
"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007f82e80cc000 nid=0x2a29 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
--

# Note that the nid is the Linux thread id

執行緒傾印中最重要的資訊包括正在等待/封鎖的執行緒，包括執行緒正在封鎖/等待的鎖或監視器。

基本作業系統工具

在除錯 Cassandra 問題時，一個很好的起點是了解 Cassandra 如何與系統資源互動。以下是 Cassandra 大量使用的所有資源

CPU 核心。用於執行並行的使用者查詢
CPU 處理時間。用於查詢活動（資料解壓縮、列合併等）
CPU 處理時間（低優先順序）。用於背景工作（壓縮、串流等…）
Java 堆的 RAM。用於保存內部資料結構，並且預設為 Cassandra 記憶表。堆空間是寫入效能以及一般效能的關鍵組成部分。
作業系統磁碟快取的 RAM。用於快取頻繁存取的 SSTable 區塊。作業系統磁碟快取是讀取效能的關鍵組成部分。
磁碟。Cassandra 非常重視磁碟讀取延遲、磁碟寫入吞吐量，當然還有磁碟空間。
網路延遲。Cassandra 會執行許多節點間請求，因此節點之間的網路延遲會直接影響效能。
網路吞吐量。Cassandra（與其他資料庫一樣）經常出現所謂的「內部廣播」問題，其中一個小型請求（例如 SELECT * from foo.bar）會傳回一個非常大的結果集（例如，整個資料集）。在這種情況下，輸出頻寬至關重要。

通常，對 Cassandra 進行故障排除歸結為對機器或叢集用盡的資源進行故障排除。然後，您建立更多該資源或變更查詢模式以減少使用該資源。

高層級資源使用率 (top/htop)

Cassandra 會大量使用系統資源，因此通常第一個有用的動作是執行 top 或 htop (網站) 來查看機器狀態。

有用的觀察事項

系統負載層級。儘管這些數字可能令人困惑，但一般來說，如果負載平均值大於 CPU 核心數，Cassandra 可能不會有非常好的延遲時間（低於 100 毫秒）。請參閱 Linux 負載平均值以取得更多資訊。
CPU 使用率。htop 特別有助於將 CPU 使用率細分為 使用者（低和正常優先順序）、系統（核心）和 io 等待。Cassandra 查詢執行緒以正常優先順序 使用者執行緒執行，而壓縮執行緒則以低優先順序 使用者執行緒執行。高 系統時間可能表示問題，例如執行緒競爭，而高 io 等待 可能表示磁碟機速度較慢。這有助於您瞭解 Cassandra 如何使用處理資源。
記憶體使用率。找出哪些程式擁有最多的常駐記憶體，這可能是 Cassandra。由於 Linux（截至 2018 年）如何處理記憶體映射檔案記憶體，因此 Cassandra 的數字可能不準確地偏高。

IO 使用率 (iostat)

使用 iostat 來確定資料磁碟機的表現，包括延遲時間分佈、傳輸量和使用率

$ sudo iostat -xdm 2
Linux 4.13.0-13-generic (hostname)     07/03/2018     _x86_64_    (8 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.28    0.32    5.42     0.01     0.13    48.55     0.01    2.21    0.26    2.32   0.64   0.37
sdb               0.00     0.00    0.00    0.00     0.00     0.00    79.34     0.00    0.20    0.20    0.00   0.16   0.00
sdc               0.34     0.27    0.76    0.36     0.01     0.02    47.56     0.03   26.90    2.98   77.73   9.21   1.03

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    2.00   32.00     0.01     4.04   244.24     0.54   16.00    0.00   17.00   1.06   3.60
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdc               0.00    24.50    0.00  114.00     0.00    11.62   208.70     5.56   48.79    0.00   48.79   1.12  12.80

在這種情況下，我們可以看到 /dev/sdc1 是非常慢的磁碟機，等待時間接近 50 毫秒，avgqu-sz 接近 5 個 io。磁碟機並未特別飽和（使用率僅為 12.8%），但我們仍應關注這將如何影響我們的 p99 延遲時間，因為 50 毫秒對於典型的 Cassandra 作業來說相當長。話雖如此，在這種情況下，大部分延遲時間存在於寫入（通常寫入比讀取延遲時間更長），由於 Cassandra 的 LSM 特性，這通常對使用者是隱藏的。

使用 iostat 評估的重要指標

每秒讀取和寫入。這些數字會隨著工作負載而改變，但一般來說，Cassandra 從磁碟機讀取的次數越多，Cassandra 讀取延遲時間就越慢。每秒大量讀取可能是群集沒有足夠記憶體進行作業系統頁面快取的明顯跡象。
寫入傳輸量。Cassandra 的 LSM 模型會延後使用者寫入並將其批次處理，這表示對底層媒體的傳輸量是 Cassandra 最重要的寫入指標。
讀取延遲時間 (r_await)。當 Cassandra 錯過作業系統頁面快取並從 SSTable 讀取時，讀取延遲時間直接決定 Cassandra 能多快回應資料。
寫入延遲時間。Cassandra 對寫入延遲時間不太敏感，除非它同步提交記錄。這通常會進入寫入延遲時間的非常高百分位數。

請注意，若要取得詳細的延遲時間細分，您需要更進階的工具，例如 bcc-tools。

作業系統頁面快取使用率

由於 Cassandra 大量使用記憶體映射檔案，因此作業系統的頁面快取的正常運作對於效能至關重要。首先找出系統中有多少可用快取

$ free -g
              total        used        free      shared  buff/cache   available
Mem:             15           9           2           0           3           5
Swap:             0           0           0

在此情況下，9GB 的記憶體由使用者程序（Cassandra 堆積）使用，而 8GB 可供作業系統頁面快取使用。其中，3GB 實際上用於快取檔案。如果大部分記憶體都被使用，且無法供頁面快取使用，Cassandra 的效能可能會大幅下降。這就是 Cassandra 會從預留給堆積的合理小量記憶體開始的原因。

如果您懷疑自己經常遺失作業系統頁面快取，可以使用進階工具，例如 cachestat 或 vmtouch 來深入探討。

網路延遲和可靠性

每當 Cassandra 執行涉及其他複本的寫入或讀取時，例如 LOCAL_QUORUM 讀取，網路延遲會對延遲造成主要影響之一。在嘗試除錯多機器操作的問題時，網路可能是重要的調查資源。您可以使用 ping 和 traceroute 等工具，或最有效地使用 mtr 來確定節點間延遲

$ mtr -nr www.google.com
Start: Sun Jul 22 13:10:28 2018
HOST: hostname                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%    10    2.0   1.9   1.1   3.7   0.7
  2.|-- 96.123.29.15               0.0%    10   11.4  11.0   9.0  16.4   1.9
  3.|-- 68.86.249.21               0.0%    10   10.6  10.7   9.0  13.7   1.1
  4.|-- 162.141.78.129             0.0%    10   11.5  10.6   9.6  12.4   0.7
  5.|-- 162.151.78.253             0.0%    10   10.9  12.1  10.4  20.2   2.8
  6.|-- 68.86.143.93               0.0%    10   12.4  12.6   9.9  23.1   3.8
  7.|-- 96.112.146.18              0.0%    10   11.9  12.4  10.6  15.5   1.6
  9.|-- 209.85.252.250             0.0%    10   13.7  13.2  12.5  13.9   0.0
 10.|-- 108.170.242.238            0.0%    10   12.7  12.4  11.1  13.0   0.5
 11.|-- 74.125.253.149             0.0%    10   13.4  13.7  11.8  19.2   2.1
 12.|-- 216.239.62.40              0.0%    10   13.4  14.7  11.5  26.9   4.6
 13.|-- 108.170.242.81             0.0%    10   14.4  13.2  10.9  16.0   1.7
 14.|-- 72.14.239.43               0.0%    10   12.2  16.1  11.0  32.8   7.1
 15.|-- 216.58.195.68              0.0%    10   25.1  15.3  11.1  25.1   4.8

在此 mtr 範例中，我們可以快速評估封包傳輸路徑，以及其典型的封包遺失率和延遲。封包遺失通常會導致 200ms 到 3s 的額外延遲，因此這可能是延遲問題的常見原因。

網路傳輸量

由於 Cassandra 對傳出頻寬限制很敏感，因此有時確定網路傳輸量是否受限很有用。一個方便的工具是 iftop，它可以一目了然地顯示頻寬使用情況和連線資訊。以下範例顯示在對本地 ccm 群集進行壓力測試期間的流量

$ # remove the -t for ncurses instead of pure text
$ sudo iftop -nNtP -i lo
interface: lo
IP address is: 127.0.0.1
MAC address is: 00:00:00:00:00:00
Listening on lo
   # Host name (port/service if enabled)            last 2s   last 10s   last 40s cumulative
--------------------------------------------------------------------------------------------
   1 127.0.0.1:58946                          =>      869Kb      869Kb      869Kb      217KB
     127.0.0.3:9042                           <=         0b         0b         0b         0B
   2 127.0.0.1:54654                          =>      736Kb      736Kb      736Kb      184KB
     127.0.0.1:9042                           <=         0b         0b         0b         0B
   3 127.0.0.1:51186                          =>      669Kb      669Kb      669Kb      167KB
     127.0.0.2:9042                           <=         0b         0b         0b         0B
   4 127.0.0.3:9042                           =>     3.30Kb     3.30Kb     3.30Kb       845B
     127.0.0.1:58946                          <=         0b         0b         0b         0B
   5 127.0.0.1:9042                           =>     2.79Kb     2.79Kb     2.79Kb       715B
     127.0.0.1:54654                          <=         0b         0b         0b         0B
   6 127.0.0.2:9042                           =>     2.54Kb     2.54Kb     2.54Kb       650B
     127.0.0.1:51186                          <=         0b         0b         0b         0B
   7 127.0.0.1:36894                          =>     1.65Kb     1.65Kb     1.65Kb       423B
     127.0.0.5:7000                           <=         0b         0b         0b         0B
   8 127.0.0.1:38034                          =>     1.50Kb     1.50Kb     1.50Kb       385B
     127.0.0.2:7000                           <=         0b         0b         0b         0B
   9 127.0.0.1:56324                          =>     1.50Kb     1.50Kb     1.50Kb       383B
     127.0.0.1:7000                           <=         0b         0b         0b         0B
  10 127.0.0.1:53044                          =>     1.43Kb     1.43Kb     1.43Kb       366B
     127.0.0.4:7000                           <=         0b         0b         0b         0B
--------------------------------------------------------------------------------------------
Total send rate:                                     2.25Mb     2.25Mb     2.25Mb
Total receive rate:                                      0b         0b         0b
Total send and receive rate:                         2.25Mb     2.25Mb     2.25Mb
--------------------------------------------------------------------------------------------
Peak rate (sent/received/total):                     2.25Mb         0b     2.25Mb
Cumulative (sent/received/total):                     576KB         0B      576KB
============================================================================================

在此情況下，我們可以看到頻寬在許多對等方之間公平共享，但如果總計接近網路介面卡的額定容量或集中在單一用戶端，則可能指出發生什麼問題的線索。

進階工具

有時，作為操作員，您可能需要深入探討。這時進階作業系統工具就派上用場了。

bcc-tools

大多數現代 Linux 發行版（核心版本高於 4.1）支援 bcc-tools，以便深入探討效能問題。首先安裝 bcc-tools，例如透過 Debian 上的 apt

$ apt install bcc-tools

然後您可以使用 bcc-tools 包含的所有工具。其中一個最有用的工具是 cachestat (cachestat 範例），它允許您準確地確定發生多少次作業系統頁面快取命中和遺失

$ sudo /usr/share/bcc/tools/cachestat -T 1
TIME        TOTAL   MISSES     HITS  DIRTIES   BUFFERS_MB  CACHED_MB
18:44:08       66       66        0       64           88       4427
18:44:09       40       40        0       75           88       4427
18:44:10     4353       45     4308      203           88       4427
18:44:11       84       77        7       13           88       4428
18:44:12     2511       14     2497       14           88       4428
18:44:13      101       98        3       18           88       4428
18:44:14    16741        0    16741       58           88       4428
18:44:15     1935       36     1899       18           88       4428
18:44:16       89       34       55       18           88       4428

在此情況下，沒有太多頁面快取 MISSES，這表示快取大小合理。這些指標是 Cassandra 節點「熱門」資料集最直接的衡量標準。如果您沒有足夠的快取，MISSES 會很高，效能會很慢。如果您有足夠的快取，MISSES 會很低，效能會很快（因為幾乎所有讀取都是從記憶體中提供）。

您也可以使用 biolatency (biolatency 範例) 衡量磁碟延遲分佈，以了解當讀取錯過作業系統頁面快取並必須存取磁碟時，Cassandra 會有多慢

$ sudo /usr/share/bcc/tools/biolatency -D 10
Tracing block device I/O... Hit Ctrl-C to end.


disk = 'sda'
     usecs               : count     distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 0        |                                        |
         4 -> 7          : 0        |                                        |
         8 -> 15         : 0        |                                        |
        16 -> 31         : 12       |****************************************|
        32 -> 63         : 9        |******************************          |
        64 -> 127        : 1        |***                                     |
       128 -> 255        : 3        |**********                              |
       256 -> 511        : 7        |***********************                 |
       512 -> 1023       : 2        |******                                  |

disk = 'sdc'
     usecs               : count     distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 0        |                                        |
         4 -> 7          : 0        |                                        |
         8 -> 15         : 0        |                                        |
        16 -> 31         : 0        |                                        |
        32 -> 63         : 0        |                                        |
        64 -> 127        : 41       |************                            |
       128 -> 255        : 17       |*****                                   |
       256 -> 511        : 13       |***                                     |
       512 -> 1023       : 2        |                                        |
      1024 -> 2047       : 0        |                                        |
      2048 -> 4095       : 0        |                                        |
      4096 -> 8191       : 56       |*****************                       |
      8192 -> 16383      : 131      |****************************************|
     16384 -> 32767      : 9        |**                                      |

在此情況下，資料磁碟機 (sdc) 上的大多數 I/O 都很快，但許多 I/O 會花費 8 至 16 毫秒。

最後，biosnoop (範例) 可用於更深入地探究，並查看每個 I/O 的延遲時間

$ sudo /usr/share/bcc/tools/biosnoop | grep java | head
0.000000000    java           17427  sdc     R  3972458600 4096      13.58
0.000818000    java           17427  sdc     R  3972459408 4096       0.35
0.007098000    java           17416  sdc     R  3972401824 4096       5.81
0.007896000    java           17416  sdc     R  3972489960 4096       0.34
0.008920000    java           17416  sdc     R  3972489896 4096       0.34
0.009487000    java           17427  sdc     R  3972401880 4096       0.32
0.010238000    java           17416  sdc     R  3972488368 4096       0.37
0.010596000    java           17427  sdc     R  3972488376 4096       0.34
0.011236000    java           17410  sdc     R  3972488424 4096       0.32
0.011825000    java           17427  sdc     R  3972488576 16384      0.65
... time passes
8.032687000    java           18279  sdc     R  10899712  122880     3.01
8.033175000    java           18279  sdc     R  10899952  8192       0.46
8.073295000    java           18279  sdc     R  23384320  122880     3.01
8.073768000    java           18279  sdc     R  23384560  8192       0.46

使用 biosnoop，您可以看到每個 I/O 以及它們花費的時間。此資料可用於建構 biolatency 中的延遲分佈，但也可以用於更深入地了解磁碟延遲如何影響效能。例如，由於 read_ahead_kb 的預設值 (128kb) 很高，因此此特定磁碟機需要 ~3 毫秒才能提供記憶體對應讀取服務。若要改善點讀取效能，您可能想要在快速資料磁區 (例如 SSD) 上減少 read_ahead_kb，同時保持較高的值，例如 128kb 的值可能適合 HD。這涉及權衡取捨，請參閱 queue-sysfs 文件以取得更多資訊，但無論如何，biosnoop 都有助於了解 Cassandra 如何使用磁碟機。

vmtouch

有時，了解作業系統快取了多少 Cassandra 資料檔案會很有用。回答此問題的絕佳工具是 vmtouch。

首先安裝它

$ git clone https://github.com/hoytech/vmtouch.git
$ cd vmtouch
$ make

然後在 Cassandra 資料目錄上執行它

$ ./vmtouch /var/lib/cassandra/data/
           Files: 312
     Directories: 92
  Resident Pages: 62503/64308  244M/251M  97.2%
         Elapsed: 0.005657 seconds

在此情況下，幾乎整個資料集都在作業系統頁面快取中是熱的。一般來說，除非讀取錯過快取 (例如 cachestat)，否則百分比並不重要，在這種情況下，擁有額外的記憶體可能有助於讀取效能。

CPU 火焰圖

Cassandra 通常會使用大量的 CPU，但要說明它在做什麼可能很困難。分析 CPU 時間上 Cassandra 的最佳方法之一是使用 CPU 火焰圖，它以有用的方式顯示 Cassandra 程式碼的哪些區域正在使用 CPU。這可能有助於將壓縮問題縮小為「壓縮問題會刪除墓碑」或只是通常有助於您縮小 Cassandra 在發生問題時正在執行的範圍。若要取得 CPU 火焰圖，請遵循 Java 火焰圖的說明。

一般來說

在 Cassandra 的 jvm.options 設定檔中啟用 -XX:+PreserveFramePointer 選項。這對效能的影響微乎其微，但能讓您實際看到 Cassandra 在做什麼。
執行 perf 以取得一些資料。
透過 FlameGraph 工具組中相關的腳本傳送該資料，並將資料轉換成漂亮的火焰圖。在瀏覽器或其他影像瀏覽器中檢視產生的 SVG 影像。

例如，直接從 GitHub 複製，我們會先將 perf-map-agent 安裝到 JVM 的位置（假設為 /usr/lib/jvm）

$ sudo bash
$ export JAVA_HOME=/usr/lib/jvm/java-8-oracle/
$ cd /usr/lib/jvm
$ git clone --depth=1 https://github.com/jvm-profiling-tools/perf-map-agent
$ cd perf-map-agent
$ cmake .
$ make

現在取得火焰圖

$ git clone --depth=1 https://github.com/brendangregg/FlameGraph
$ sudo bash
$ cd FlameGraph
$ # Record traces of Cassandra and map symbols for all java processes
$ perf record -F 49 -a -g -p <CASSANDRA PID> -- sleep 30; ./jmaps
$ # Translate the data
$ perf script > cassandra_stacks
$ cat cassandra_stacks | ./stackcollapse-perf.pl | grep -v cpu_idle | \
    ./flamegraph.pl --color=java --hash > cassandra_flames.svg

產生的 SVG 可搜尋、可縮放，且通常使用瀏覽器很容易內省。

封包擷取

有時您必須了解 Cassandra 節點正在執行哪些查詢，現在才能解決問題。在這些時候，像 tcpdump 和 Wireshark 這樣的可靠封包擷取工具可以非常有助於剖析封包擷取。Wireshark 甚至有原生的 CQL 支援，儘管它有時會與較新的 Cassandra 協定版本相容性問題。

要取得封包擷取，請先擷取一些封包

$ sudo tcpdump -U -s0 -i <INTERFACE> -w cassandra.pcap -n "tcp port 9042"

現在使用 Wireshark 開啟它

$ wireshark cassandra.pcap

如果您看不到類似 CQL 的陳述式，請嘗試透過右鍵按一下傳送到 9042 的封包，然後選取「解碼為」→ 從 9042 埠的下拉式選單中選取 CQL，來告訴它解碼為 CQL。

如果您不想手動執行此操作或使用 GUI，您也可以使用類似 cqltrace 的東西來輕鬆取得和剖析 CQL 封包擷取。

Cassandra 文件

版本