在本章中，您將學習如何使用各種工具來監視和了解Cassandra集羣生命週期中的重要事件。我們將看一些簡單的方法來查看正在發生的事情，例如更改日誌記錄級別和了解輸出。

Cassandra還具有對Java Management Extensions（JMX）的內置支持，它提供了一種豐富的方式來監視您的Cassandra節點及其底層Java環境。通過JMX，我們可以看到數據庫的健康狀況和正在進行的事件，甚至可以遠程與之交互以調整某些值。 JMX是Cassandra的重要組成部分，我們將花一些時間確保我們知道它是如何工作的，以及Cassandra用JMX監控和管理的確切內容。讓我們開始吧！

記錄

瞭解數據庫中發生的事情的最簡單方法是隻更改日誌記錄級別以使輸出更加詳細。這對於開發和學習Cassandra在幕後所做的事情非常有用。

Cassandra使用Simple Logging Facade for Java（SLF4J）API進行日誌記錄，使用Logback作爲實現。 SLF4J提供了各種日誌框架的外觀，例如Logback，Log4J和Java的內置記錄器（java.util.logging）。您可以在http://logback.qos.ch/上了解有關Logback的更多信息。

默認情況下，Cassandra服務器日誌級別設置爲INFO，這不會爲您提供有關Cassandra在任何給定時間正在執行的工作的詳細信息。它只輸出基本狀態更新，如下所示：

INFO  [main] 2015-09-19 09:40:20,215 CassandraDaemon.java:149 - 
  Hostname: Carp-iMac27.local
INFO  [main] 2015-09-19 09:40:20,233 YamlConfigurationLoader.java:92 -
  Loading settings from file:/Users/jeff/Cassandra/
  apache-cassandra-2.1.8/conf/cassandra.yaml
INFO  [main] 2015-09-19 09:40:20,333 YamlConfigurationLoader.java:135 - 
  Node configuration
...

當您在終端中啓動Cassandra時，通過向程序傳遞-f標誌來保持此輸出在終端窗口中運行（以保持輸出在終端窗口的前景中可見）。但Cassandra也將這些日誌寫入物理文件供您稍後檢查。

通過將日誌記錄級別更改爲DEBUG，我們可以更清楚地看到服務器正在處理的活動，而不是僅查看這些階段更新。

要更改日誌記錄級別，請打開文件 /conf/logback.xml並找到如下所示的部分：

 <root level="INFO">
    <appender-ref ref="FILE" />
    <appender-ref ref="STDOUT" />
  </root>

更改第一行，使其如下所示：

<root level="DEBUG">

完成此更改並保存文件後，Cassandra將很快開始打印DEBUG級別的日誌記錄語句。這是因爲默認日誌記錄配置爲每分鐘掃描一次配置文件，如下所示：

<configuration scan="true">

現在，隨着Cassandra的工作，我們可以看到更多的活動。這使您可以準確地瞭解Cassandra正在做什麼以及何時做什麼，這在故障排除方面非常有用。但它也有助於簡單地理解Cassandra爲維持自身所做的工作。

調整生產中的記錄

當然，在生產中，您需要將日誌記錄級別調整回WARN或ERROR，因爲詳細輸出會大大減慢速度。

默認情況下，Cassandra的日誌文件存儲在Cassandra安裝目錄下的logs目錄中。

如果要更改logs目錄的位置，只需在logback.xml文件中找到以下條目並選擇其他文件名：

    <file>${cassandra.logdir}/system.log</file>

缺少日誌文件

如果在指定的位置中沒有看到任何日誌文件，請確保您是目錄的所有者，或者至少設置了正確的讀寫權限。 Cassandra不會告訴你它是否不能寫日誌; 它只是不會寫。數據文件也是如此。

logback.xml文件中的其他設置支持滾動日誌文件。默認情況下，system.log文件在達到20 MB的大小時將滾動到存檔。每個日誌文件存檔都以zip格式壓縮，並根據模式system.log.1.zip，system.log.2.zip等命名。

Tailing

您不需要使用前臺開關啓動Cassandra以查看滾動日誌。您也可以在沒有-f選項的情況下啓動它，然後拖尾日誌。拖尾不是Cassandra特有的; 它是Linux發行版中提供的一個小程序，用於查看打印到控制檯的新值，因爲它們會附加到文件中。

要拖尾日誌，像這樣啓動Cassandra：

$ bin/cassandra

然後打開第二個控制檯，輸入tail命令，並將要傳遞給特定文件的位置傳遞給它，如下所示：

$ tail -f $CASSANDRA_HOME/logs/system.log

-f選項表示“跟隨”，當Cassandra將信息輸出到物理日誌文件時，tail會將其輸出到屏幕。要停止拖尾，只需按Ctrl-C即可。

如果您使用的是Windows，則可以執行相同的操作，但Windows本身不包含尾部程序。因此，要實現這一點，您需要下載並安裝Cygwin，它是一個免費的開源Bash shell模擬器。 Cygwin允許您擁有Linux風格的界面並在Windows上使用各種Linux工具。

然後，您可以定期啓動Cassandra並使用以下命令拖尾日誌文件：

$ tail -f %CASSANDRA_HOME%\\logs\\system.log

這將以與預設相同的方式顯示控制檯中的輸出。

檢查日誌文件

在啓用調試日誌記錄的情況下運行服務器後，您可以看到在調試過程中可以提供更多幫助。例如，在這裏我們可以看到使用cqlsh將簡單值寫入數據庫時的輸出：

cqlsh> INSERT INTO hotel.hotels (id, name, phone, address) 
   ... VALUES ( 'AZ123', 'Comfort Suites Old Town Scottsdale', 
   ... '(480) 946-1111', { street : '3275 N. Drinkwater Blvd.', 
   ... city : 'Scottsdale', state : 'AZ', zip_code : 85251 });

DEBUG [SharedPool-Worker-1] 2015-09-30 06:21:41,410 Message.java:506 - 
  Received: OPTIONS, v=4
DEBUG [SharedPool-Worker-1] 2015-09-30 06:21:41,410 Message.java:525 - 
  Responding: SUPPORTED {COMPRESSION=[snappy, lz4], 
  CQL_VERSION=[3.3.1]}, v=4
DEBUG [SharedPool-Worker-1] 2015-09-30 06:21:42,082 Message.java:506 -
  Received: QUERY INSERT INTO hotel.hotels (id, name, phone, address) 
  VALUES ( 'AZ123', 'Comfort Suites Old Town Scottsdale', 
  '(480) 946-1111', { street : '3275 N. Drinkwater Blvd.', 
  city : 'Scottsdale', state : 'AZ', zip_code : 85251 });
  [pageSize = 100], v=4
DEBUG [SharedPool-Worker-1] 2015-09-30 06:21:42,086 
  AbstractReplicationStrategy.java:87 - clearing cached endpoints
DEBUG [SharedPool-Worker-1] 2015-09-30 06:21:42,087 Tracing.java:155 - 
request complete
DEBUG [SharedPool-Worker-1] 2015-09-30 06:21:42,087 Message.java:525 -
   Responding: EMPTY RESULT, v=4

鑑於它在單個節點集羣上運行，因此該特定輸出的表現力不如其他情況。

如果我們然後通過一個簡單的查詢加載行：

cqlsh> SELECT * from hotel.hotels;

The server log records this query as follows:

DEBUG [SharedPool-Worker-1] 2015-09-30 06:27:27,392 Message.java:506 - 
  Received: QUERY SELECT * from hotel.hotels;[pageSize = 100], v=4
DEBUG [SharedPool-Worker-1] 2015-09-30 06:27:27,395 
  StorageProxy.java:2021 - Estimated result rows per range: 0.0; 
  requested rows: 100, ranges.size(): 257; concurrent range requests: 1
DEBUG [SharedPool-Worker-1] 2015-09-30 06:27:27,401 
  ReadCallback.java:141 - Read: 0 ms.
DEBUG [SharedPool-Worker-1] 2015-09-30 06:27:27,401 Tracing.java:155 - 
  request complete
DEBUG [SharedPool-Worker-1] 2015-09-30 06:27:27,401 Message.java:525 - 
  Responding: ROWS [id(hotel, hotels), 
  org.apache.cassandra.db.marshal.UUIDType][address(hotel, hotels), 
  org.apache.cassandra.db.marshal.UserType(hotel,61646472657373,
  737472656574:org.apache.cassandra.db.marshal.UTF8Type,
  63697479:org.apache.cassandra.db.marshal.UTF8Type,7374617465:
  org.apache.cassandra.db.marshal.UTF8Type,7a69705f636f6465:
  org.apache.cassandra.db.marshal.Int32Type)][name(hotel, hotels), 
  org.apache.cassandra.db.marshal.UTF8Type][phone(hotel, hotels), 
  org.apache.cassandra.db.marshal.UTF8Type][pois(hotel, hotels), 
  org.apache.cassandra.db.marshal.SetType(org.apache.cassandra.db.
  marshal.UUIDType)]
 | 452d27e1-804e-479b-aeaf-61d1fa31090f | 3275 N. Drinkwater Blvd.:
  Scottsdale:AZ:85251 | Comfort Suites Old Town Scottsdale | 
  (480) 946-1111 | null

如您所見，服務器通過負責從磁盤格式編組數據的類加載我們請求的每個列。

DEBUG日誌級別應該爲您提供足夠的信息以跟蹤服務器在您工作時所執行的操作。

使用JMX監視Cassandra

在本節中，我們將探討Cassandra如何利用Java Management Extensions（JMX）來實現服務器的遠程管理。 JMX從Java規範請求（JSR）160開始，自5.0版以來一直是Java的核心部分。

更多關於JMX

您可以通過檢查java.lang.management包來閱讀有關Java中JMX實現的更多信息。

JMX是一種Java API，它以兩種主要方式提供應用程序管理。首先，JMX允許您瞭解應用程序在內存，線程和CPU使用方面的運行狀況和整體性能 - 這些內容通常適用於任何Java應用程序。其次，JMX允許您使用已經檢測的應用程序的特定方面。

Instrumentation是指爲應用程序代碼提供一個包裝器，該應用程序代碼提供從應用程序到JVM的鉤子，以便允許JVM收集外部工具可以使用的數據。此類工具包括監視代理程序，數據分析工具，分析程序等。 JMX不僅允許您查看此類數據，還可以在應用程序啓用時通過更新值在運行時管理您的應用程序。

JMX通常用於各種應用程序控制操作，包括：

低可用內存檢測，包括堆上每個生成空間的大小
線程信息，例如死鎖檢測，線程峯值數和當前活動線程
詳細的類加載器跟蹤
日誌級別控制
一般信息，例如應用程序正常運行時間和活動類路徑

許多流行的Java應用程序都使用JMX進行檢測，包括JVM本身，Tomcat應用程序服務器和Cassandra。 JMX架構的描述如圖10-1所示。

JMX架構很簡單。 JVM從底層操作系統收集信息。 JVM本身是經過檢測的，因此如前所述，它的許多功能都會被公開用於管理。一個帶有檢測的Java應用程序（例如Cassandra）在此基礎上運行，並將其一些功能公開爲可管理對象。 JDK包括一個MBean服務器，該服務器通過遠程協議將檢測的功能提供給JMX管理應用程序。 JVM還通過簡單網絡監視協議（SNMP）提供管理功能，如果您使用的是Nagios或Zenoss等SMTP監視工具，這可能很有用。

但是在給定的應用程序中，您只能管理應用程序開發人員可供您管理的內容。幸運的是，Cassandra開發人員已經對大部分數據庫引擎進行了檢測，通過JMX進行管理非常簡單。

這個Java應用程序的工具是通過包裝您希望JMX與託管bean掛鉤的應用程序代碼來執行的。
通過JConsole連接到Cassandra

jconsole工具隨附標準Java Development Kit。它提供了一個用於處理MBean的圖形用戶界面客戶端，可用於本地或遠程管理。讓我們使用JConsole在其JMX端口上連接到Cassandra。爲此，請打開一個新終端並鍵入以下內容：

>jconsole

When you run jconsole, you’ll see a login screen similar to that in Figure 10-2.

從這裏，如果您正在監視同一臺機器上的節點，只需雙擊“本地進程”部分下的值org.apache.cassandra.service.CassandraDaemon即可。如果要監視其他計算機上的節點，請選中“遠程進程”單選按鈕，然後輸入要連接的主機和端口。默認情況下，Cassandra JMX在端口7199上廣播，因此您可以輸入類似於此處所示的值，然後點擊Connect：

>lucky:7199

通過JMX遠程連接

默認情況下，Cassandra僅在啓用JMX以進行本地訪問時運行。要啓用遠程訪問，請編輯文件/cassandra-env.sh（或Windows上的cassandra.ps1）。搜索“JMX”以查找文件部分，其中包含用於控制JMX端口和其他本地/遠程連接設置的選項。

連接到服務器後，默認視圖包含有關服務器狀態的四個主要類別，這些類別會不斷更新：

堆內存使用情況
- 這顯示了Cassandra程序可用的總內存，以及它現在使用的內存量。
主題
- 這是Cassandra正在使用的活線程數。
類
- Cassandra加載的類數。對於這樣一個強大的程序，這個數字相對較小; Cassandra通常需要不到3000個課程。將其與Oracle WebLogic等程序進行比較，該程序通常會加載大約24,000個類。
CPU使用率
- 這顯示了Cassandra程序當前使用的處理器的百分比。

您可以使用選擇器調整圖表中顯示的時間範圍。

如果要查看Cassandra如何使用Java堆和非堆內存的更詳細視圖，請單擊“內存”選項卡。通過更改下拉列表中的圖表值，您可以詳細查看Cassandra使用其內存的分級。如果您認爲有必要，您也可以（嘗試）強制進行垃圾收集。

您可以一次連接到多個JMX代理。只需選擇文件→新建連接…並重復步驟以連接到另一個正在運行的Cassandra節點，以便一次查看多個服務器。

其他JMX客戶端

當您正在尋找JMX客戶端時，JConsole是一個簡單的選擇，因爲它易於使用並隨JDK一起提供。但這只是一個可能的JMX客戶端 - 還有很多其他客戶端可用。以下是一些可能滿足您需求的客戶示例：

Oracle Java Mission Control和Visual VM

這些工具還隨Oracle JDK一起提供，併爲內存使用，線程，垃圾收集等提供更強大的指標，診斷和可視化。兩者之間的主要比較是Visual VM是GNU許可下可用的開源項目，而Mission Control通過名爲Flight Control的框架提供與Oracle JVM的更深層次的集成。

Java Mission Control可以通過命令$ JAVA_HOME / bin / jmc和Visual VM通過命令$ JAVA_HOME / bin / jvisualvm運行。兩者都適用於開發和生產環境。
MX4J

Management Extensions for Java（MX4J）項目提供了JMX的開源實現，包括使用HTTP / HTML等工具，如JMX的嵌入式Web界面。這允許通過標準Web瀏覽器與JMX交互。

要將MX4J集成到Cassandra安裝中，請下載mx4j_tools.jar庫，將JAR文件保存在Cassandra安裝的lib目錄中，並在conf / cassandra-env.sh中配置MX4J_ADDRESS和MX4J_PORT選項。
Jmxterm

Jmxterm是一個命令行JMX客戶端，允許在沒有圖形界面的情況下訪問JMX服務器。這在雲環境中工作時尤其有用，因爲圖形工具通常更耗費資源。

Jmxterm是Cyclops Group提供的一個開源Java項目。
IDE集成

您還可以找到與流行的IDE集成的JMX客戶端; 例如，eclipse-jmx。

MBean概述

託管bean或MBean是一種特殊類型的Java bean，它表示JVM中的單個可管理資源。 MBean與MBean服務器交互以使其功能遠程可用。

圖10-3中提供了JConsole的視圖。

在此圖中，您可以看到提供有關每個應用程序將具有的線程，內存和CPU的一般視圖的選項卡式窗口，以及更詳細的MBeans選項卡，該選項卡公開了與應用程序公開的MBean進行更詳細交互的能力。例如，在圖中，我們選擇查看峯值線程計數值。您可以看到應用程序的許多其他檢測方面也可用。

應用程序或JVM的許多方面都可以進行檢測，但可能會被禁用。線程爭用是JVM中默認關閉的可能有用的MBean的一個示例。這些方面對於調試非常有用，因此如果您看到一個MBean，您認爲可以幫助您解決問題，請繼續並啓用它。但請記住，沒有任何東西是免費的，並且最好在要啓用的MBean上讀取JavaDoc，以便了解對性能的潛在影響。例如，測量每個線程的CPU時間是一個有用但昂貴的MBean操作的示例。

MBean對象名稱約定

向MBean服務器註冊MBean時，它指定用於標識JMX客戶端的MBean的對象名稱。對象名稱由一個域後跟一個鍵值對列表組成，其中至少有一個必須標識一個類型。典型的約定是選擇一個類似於MBean的Java包名稱的域名，並在MBean接口名稱之後命名該類型（減去“MBean”），但這不是嚴格要求的。

例如，我們之前看到的線程屬性出現在JConsole中的java.lang.Threading標題下，並由實現java.lang.management。ThreadMXBean接口的類公開，該接口使用對象名java註冊MBean。 lang.type =線程。

在本章討論各種MBean時，我們將識別MBean對象名稱和界面，以幫助您在JMX客戶端和Cassandra源代碼之間導航。

應用程序中的一些簡單值作爲屬性公開。一個例子是Threading> PeakThreadCount，它只報告MBean爲應用程序在單個時間點使用的最大線程數存儲的值。您可以刷新以查看最新值，但這幾乎可以用它來完成。因爲這樣的值是在JVM內部維護的，所以在外部設置它是沒有意義的（它是從實際事件派生的，而不是可配置的）。

但其他MBean是可配置的。它們使JMX代理可以使用操作，以便獲取和設置值。您可以通過查看可寫值來判斷MBean是否允許您設置值。如果爲false，您將看到一個標籤，指示只讀值;如果確實如此，您將看到一組用於添加新值的一個或多個字段以及一個用於更新它的按鈕。這方面的一個例子是ch.qos.logback.classic.jmx.JMXConfigurator bean，如圖10-4所示。

請注意，參數名稱不可用於JMX代理程序;它們只是標記爲p0，p1，依此類推。那是因爲Java編譯器在編譯期間“擦除”了參數名稱。因此，爲了知道在操作上設置哪些參數，您需要查看您正在使用的特定MBean的JavaDoc。

對於JMXConfigurator，此類實現一個名爲JMXConfiguratorMBean的接口，該接口將其包裝以進行檢測。要找出setLoggerLevel操作的正確參數，我們將檢查此接口的JavaDoc，可從http://logback.qos.ch/apidocs/ch/qos/logback/classic/jmx/JMXConfiguratorMBean.html獲取。查看文檔，您將看到p0表示要更改的記錄器的名稱，p1描述了要將該記錄器設置爲的記錄級別。

某些MBean返回javax.management.openmbean.CompositeDataSupport的屬性值。這意味着這些不是可以在單個字段中顯示的簡單值，例如LoadedClassCount，而是多值。一個例子是Memory> HeapMemoryUsage，它提供了幾個數據點，因此有自己的視圖。

另一種類型的MBean操作不是簡單地顯示值或允許您設置值，而是允許您執行一些有用的操作。 dumpAllThreads和resetPeakThreadCount是兩個這樣的操作。

現在我們很快就會開始專門開始監控和管理Cassandra。

卡桑德拉的MBeans

一旦與JConsole等JMX代理連接，就可以使用它公開的MBean來管理Cassandra。爲此，請單擊MBeans選項卡。除了每個代理程序可用的標準Java項目之外，還有幾個包含可管理bean的Cassandra程序包，這些bean由程序包名稱組織，以org.apache.cassandra開頭。我們不會在這裏詳細介紹所有這些內容，但有幾個我們需要關注的興趣。

Cassandra中的許多類都公開爲MBean，這實際上意味着它們實現了一個自定義接口，該接口描述了需要實現的操作以及JMX代理將爲其提供掛鉤的操作。使任何MBean工作的步驟基本相同。如果您希望JMX啓用尚未啓用的功能，請按照此大綱修改源代碼，您將開始營業。

例如，我們從org.apache.cassandra.db.compaction包中查看Cassandra的CompactionManager以及它如何使用MBean。這是CompactionManagerMBean類的定義，爲簡潔起見省略了註釋：

public interface CompactionManagerMBean
{
    public List<Map<String, String>> getCompactions();
    public List<String> getCompactionSummary();
    public TabularData getCompactionHistory();

    public void forceUserDefinedCompaction(String dataFiles);
    public void stopCompaction(String type);
    public void stopCompactionById(String compactionId);

    public int getCoreCompactorThreads();
    public void setCoreCompactorThreads(int number);

    public int getMaximumCompactorThreads();
    public void setMaximumCompactorThreads(int number);

    public int getCoreValidationThreads();
    public void setCoreValidationThreads(int number);

    public int getMaximumValidatorThreads();
    public void setMaximumValidatorThreads(int number);
}

正如您在MBean接口定義中所看到的那樣，沒有任何魔力可言。這只是一個常規接口，用於定義將向CompMManager實現必須支持的JMX公開的操作集。這通常意味着在常規操作完成其工作時維護其他元數據。

CompactionManager類實現此接口，並且必須執行直接支持JMX的工作。 CompactionManager類本身爲MBean服務器註冊和取消註冊它在本地維護的JMX屬性：

public static final String MBEAN_OBJECT_NAME = 
    "org.apache.cassandra.db:type=CompactionManager";
// ...
static
{
    instance = new CompactionManager();
    MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
    try
    {
        mbs.registerMBean(instance, 
           new ObjectName(MBEAN_OBJECT_NAME));
    }
    catch (Exception e)
    {
        throw new RuntimeException(e);
    }
}

請注意，MBean在域org.apache.cassandra.db中註冊，其類型爲CompactionManager。此MBean公開的屬性和操作顯示在JMX客戶端中的org.apache.cassandra.db> CompactionManager下。該實現完成了它打算完成的所有工作，然後實現了只與MBean服務器通信所必需的方法。例如，這是stopCompaction（）操作的CompactionManager實現：

public void stopCompaction(String type)
{
    OperationType operation = OperationType.valueOf(type);
    for (Holder holder : CompactionMetrics.getCompactions())
    {
        if (holder.getCompactionInfo().getTaskType() == operation)
            holder.stop();
    }
}

CompactionManager迭代正在進行的壓縮，停止每個具有指定類型的壓縮。 Javadoc讓我們知道有效類型是COMPACTION，VALIDATION，CLEANUP，SCRUB和INDEX_BUILD。

當我們在JConsole中查看CompactionManagerMBean時，我們可以選擇操作並查看stopCompaction（）操作，如圖10-5所示。我們可以輸入上述類型之一併請求停止壓縮。

在以下部分中，我們將瞭解通過JMX可用於監視和管理的功能。

數據庫MBean

這些是與核心數據庫本身相關的Cassandra類，它們暴露給org.apache.cassandra.db域中的客戶端。此域中有許多MBean，但我們將專注於與存儲，緩存，提交日誌和表存儲相關的幾個關鍵MBean。

存儲服務MBean

因爲Cassandra是一個數據庫，它本質上是一個非常複雜的存儲程序;因此，當您遇到問題時，您首先想要查看的地方之一是org.apache.cassandra.service.StorageServiceMBean。這允許您檢查您的OperationMode，如果一切順利（其他可能的狀態是離開，加入，退役和客戶端），則報告正常。

您還可以查看當前的活動節點集以及羣集中無法訪問的節點集。如果任何節點無法訪問，Cassandra將在UnreachableNodes屬性中告訴您IP地址。

如果要在不中斷服務的情況下在運行時更改Cassandra的日誌級別（正如我們在前面的示例中所見），您可以調用setLoggingLevel（String classQualifier，String level）方法。例如，假設您已將Cassandra的日誌級別設置爲DEBUG，因爲您正在解決問題。您可以使用此處描述的某些方法來嘗試幫助解決問題，然後您可能希望將日誌級別更改爲對系統不那麼重要的事情。爲此，請導航到JMX客戶端（如JConsole）中的StorageService MBean。我們將改變一個特別健談的類的價值：Gossiper。此操作的第一個參數是要爲其設置日誌級別的類的名稱，第二個參數是您要將其設置爲的級別。輸入org.apache.cassandra.gms.Gossiper和INFO，然後單擊標記爲setLoggingLevel的按鈕。您應該在日誌中看到以下輸出（假設您的級別已經調試）：

INFO  03:08:20 set log level to INFO for classes under 
  'org.apache.cassandra.gms.Gossiper' (if the level doesn't look 
   like 'INFO' then the logger couldn't parse 'INFO')

在調用setLoggingLevel操作之後，我們獲得INFO輸出而不再有DEBUG級語句。

要了解每個節點上存儲的數據量，可以使用getLoadMap（）方法，該方法將返回帶有IP地址密鑰的Java Map，其中包含相應存儲負載的值。您還可以使用effectiveOwnership（String keyspace）操作來訪問每個節點擁有的鍵空間中的數據百分比。

如果要查找某個鍵，可以使用getNaturalEndpoints（String table，byte [] key）操作。將表名和要查找端點值的密鑰傳遞給它，它將返回負責存儲此密鑰的IP地址列表。

您還可以使用getRangeToEndpointMap操作來獲取描述環形拓撲的範圍到端點的映射。

如果您感覺很勇敢，可以爲給定鍵空間中的給定表調用truncate（）操作。如果所有節點都可用，則此操作將刪除表中的所有數據，但保留其定義不變。

StorageServiceMBean爲您提供了許多標準維護操作，包括resumeBootstrap（），joinRing（），repairAsync（），drain（），removeNode（），decommission（），以及啓動和停止八卦的操作，本機傳輸以及節儉（直到Thrift終於被刪除）。瞭解可用的維護操作對於保持集羣的健康狀況非常重要，我們將在第11章中詳細介紹。

存儲代理MBean

正如我們在第6章中學到的，org.apache.cassandra.service.StorageProxy在StorageService之上提供了一個層來處理客戶端請求和節點間通信。 StorageProxyMBean提供了檢查和設置各種操作（包括讀取和寫入）的超時值的功能。

此MBean還提供對提示的切換設置的訪問，例如存儲提示的最大時間窗口。提示的切換統計信息包括getTotalHints（）和getHintsInProgress（）。您可以使用禁用HintsForDC（）操作禁用特定節點的提示。

您還可以通過setHintedHandoffEnabled（）打開或關閉此節點參與提示切換，或通過getHintedHandoffEnabled（）檢查當前狀態。這些由nodetool的enablehandoff，disablehandoff和statushandoff命令分別使用。

reloadTriggerClasses（）操作允許您安裝新的觸發器而無需重新啓動節點。

ColumnFamilyStoreMBean

Cassandra爲org.apache.cassandra.db> Tables（以前爲ColumnFamilies）下的節點中存儲的每個表註冊org.apache.cassandra.db.ColumnFamily Store MBean的實例。

ColumnFamilyStoreMBean提供對每個表的壓縮和壓縮設置的訪問。這允許您臨時覆蓋特定節點上的這些設置。重新啓動節點時，這些值將重置爲在表架構上配置的值。

MBean還公開了有關該表的節點在磁盤上的數據存儲的大量信息。 getSSTableCountPerLevel（）操作提供每個層中有多少個SStables的列表。 estimateKeys（）操作提供對此節點上存儲的分區數量的估計。總之，這些信息可以讓您瞭解是否爲此表調用forceMajorCompaction（）操作可能有助於釋放此節點上的空間並提高讀取性能。

還有一個trueSnapshotsSize（）操作，允許您確定不再處於活動狀態的SSTable shapshots的大小。此處的較大值表示您可以考慮刪除這些快照，可能是在製作存檔副本之後。

由於Cassandra將索引存儲爲表，因此每個索引列還有一個ColumnFamilyStoreMBean實例，可在org.apache.cassandra.db> IndexTables（以前爲IndexColumnFamilies）下使用，具有相同的屬性和操作。

CacheServiceMBean

org.apache.cassandra.service.CacheServiceMBean提供對域org.apache.cassandra.db>緩存下的Cassandra密鑰緩存，行緩存和計數器緩存的訪問。每個緩存可用的信息包括緩存項目的最大大小和持續時間，以及使每個緩存無效的能力。

CommitLogMBean

org.apache.cassandra.db.commitlog.CommitLogMBean公開了允許您瞭解提交日誌當前狀態的屬性和操作。 Commit LogMBean還公開了recover（）操作，該操作可用於從存檔的提交日誌文件中恢復數據庫狀態。

控制提交日誌恢復的默認設置在conf / commitlog_archiving.properties文件中指定，但可以通過MBean覆蓋。我們將在第11章中瞭解有關數據恢復的更多信息。

壓縮管理器MBean

我們已經在org.apache.cassandra.db.compaction.CompactionManagerMBean的源代碼中查看了它與JMX的交互方式，但我們並沒有真正談論它的用途。這個MBean允許我們獲取有關過去執行的壓縮的統計信息，以及通過調用Compaction Manager類的forceUserDefinedCompaction方法強制壓縮我們識別的特定SSTable文件的能力。這個MBean由nodetool命令利用，包括compact，compactionhistory和compactionstats。

Snitch MBeans

Cassandra提供兩個MBean來監視和配置告密者的行爲。 org.apache.cassandra.locator.EndpointSnitchInfoMBean提供給定主機的機架和數據中心的名稱，以及正在使用的snitch的名稱。

如果您正在使用DynamicEndpointSnitch，則會註冊org.apache.cassandra.locator.FynamicEndpointSnitchMBean。此MBean公開了重置snitch用於將節點標記爲脫機的不良閾值的功能，以及允許您查看各個節點的分數。

HintedHandoffManagerMBean

除了前面提到的StorageServiceMBean上的暗示切換操作之外，Cassandra還通過org.apache.cassandra.db.HintedHandOffManagerMBean提供了對提示切換的更精細控制。 MBean通過調用listEndpointsPendingHints（）來公開列出存儲提示的節點的能力。然後，您可以通過scheduleHintDelivery（）強制將提示傳遞到節點，或者使用deleteHintsForEndpoint（）刪除爲特定節點存儲的提示。

此外，您可以使用pauseHint Delivery（）暫停和恢復提示傳遞到所有節點，或使用truncateAllHints（）操作刪除所有節點的存儲提示。這些由nodetool的pausehandoff，resumehandoff和truncatehints命令分別使用。

重複提示切換管理

org.apache.cassandra.hints.HintsService在域org.apache.cassandra .hints> HintsService下公開HintsServiceMBean。此MBean提供暫停和恢復提示切換的操作，並刪除爲所有節點或由IP地址標識的特定節點存儲的提示。

由於StorageService MBean，HintedHandOffManagerMBean和HintsServiceMBean之間存在大量重疊，因此在將來的版本中可能會對這些操作進行一些合併。

網絡MBean

org.apache.cassandra.net域包含MBean，用於幫助管理Cassandra的網絡相關活動，包括Phi故障檢測和八卦，消息服務和流管理器。

FailureDetectorMBean

org.apache.cassandra.gms.FailureDetectorMBean提供描述其他節點的狀態和Phi分數的屬性，以及Phi定罪閾值。

GossiperMBean

org.apache.cassandra.gms.GossiperMBean提供對Gossiper工作的訪問。

我們已經討論過StorageServiceMBean如何報告哪些節點無法訪問。根據該列表，您可以調用GossiperMBean上的getEndpointDowntime（）操作來確定給定節點已關閉多長時間。停機時間是從我們正在檢查的MBean的節點的角度來衡量的，當節點重新聯機時該值會重置。 Cassandra在內部使用此操作來了解它可以等待多長時間來丟棄提示。

getCurrentGenerationNumber（）操作返回與特定節點關聯的世代號。生成號包含在節點之間交換的八卦消息中，用於區分節點的當前狀態和重啓之前的狀態。節點處於活動狀態時，世代號保持不變，並且每次節點重新啓動時都會增加。它由Gossiper使用時間戳維護。

assassinateEndpoint（）操作試圖通過告訴其他節點該節點已被永久刪除來從環中刪除節點，類似於人類八卦中的“角色暗殺”概念。當無法正常從羣集中刪除節點時，暗殺節點是最後的維護步驟。 nodetool assassinate命令使用此操作。

StreamManagerMBean

org.apache.cassandra.streaming.StreamManagerMBean允許我們查看節點與其對等體之間發生的流活動。這裏有兩個基本思想：流源和流目的地。每個節點都可以將其數據流式傳輸到另一個節點以執行負載平衡，StreamManager類支持這些操作。 StreamManagerMBean爲在集羣中的節點之間移動的數據提供必要的視圖。

StreamManagerMBean支持兩種操作模式。 getCurrentStreams（）操作提供當前傳入和傳出流的快照，MBean還發布與流狀態更改相關的通知，例如初始化，完成或失敗。您可以在JMX客戶端中訂閱這些通知，以便在流式傳輸操作發生時進行觀察。

因此，與StorageServiceMBean結合使用時，如果您擔心某個節點沒有接收到應有的數據，或者某個節點是不平衡甚至是不合適的，那麼這兩個MBean一起工作可以讓您深入瞭解您的確切發生的事情。簇。

Metrics MBeans

訪問與應用程序性能，運行狀況和關鍵活動相關的指標的能力已成爲維護Web級應用程序的基本工具。幸運的是，Cassandra在自己的活動中收集了大量指標，以幫助我們瞭解行爲。

Cassandra報告的指標包括以下內容：

描述Cassandra使用內存的緩衝池指標。
CQL指標，包括準備和常規語句執行的數量。
緩存密鑰，行和計數器緩存的度量標準，例如條目數與容量，以及命中率和未命中率。
客戶端指標，包括已連接客戶端的數量，以及有關客戶端請求的信息，如延遲，故障和超時。
提交日誌指標，包括提交日誌大小和待處理和已完成任務的統計信息。
壓縮指標，包括壓縮的總字節數以及待處理和已完成壓縮的統計數據。
羣集中每個節點的連接指標，包括八卦。
丟棄的消息指標，用作nodetool tpstats的一部分。
閱讀修復指標，描述隨時間推移執行的後臺修復與阻止讀取修復的次數。
存儲指標，包括正在進行的提示計數和總提示。
線程池度量標準，包括每個線程池的活動，已完成和已阻止的任務。
表格指標，包括緩存，memtables，SSTables和Bloom過濾器使用情況以及各種讀寫操作的延遲，以1分鐘，5分鐘和15分鐘的間隔報告。
Keyspace指標，用於聚合每個鍵空間中表的指標。

爲了通過JMX訪問這些指標，Cassandra使用Dropwizard Metrics開源Java庫。 Cassandra使用Metrics庫註冊其度量標準，而Metrics庫又將它們公開爲org.apache.cassandra.metrics域中的MBean。

許多這些指標由nodetool命令使用，例如tpstats，表直方圖和代理組合圖。例如，tpstats只是線程池和已刪除消息度量的表示。

線程MBeans

org.apache.cassandra.internal域包含MBean，允許您配置與Cassandra的分階段事件驅動架構（SEDA）中的每個階段關聯的線程池。這些階段包括AntiEntropyStage，GossipStage，InternalResponseStage，MigrationStage等。

閱讀修復MBean

由於歷史原因，ReadRepairStage MBean位於org.apache.cassandra.request域下，而不是org.apache.cassandra.internal。

線程池是通過org.apache.cassandra .concurrent包中的JMXEnabledThreadPoolExecutor和JMXEnabledScheduledThreadPoolExecutor類實現的。每個階段的MBean實現JMXEnabledScheduledThreadPoolExecutorMBean接口，該接口允許您查看和配置每個線程池中的核心線程數以及最大線程數。

服務MBean

GCInspectorMXBean公開單個操作getAndResetStats（），該操作檢索並重置Cassandra在其JVM上收集的垃圾收集指標。此MBean出現在org.apache.cassandra.service域中。 nodetool gcstats命令可以訪問此MBean。

安全MBean

org.apache.cassandra.auth域包含與安全相關的MBean，這些MBean根據相同的Java包名稱進行分組。從3.0版本開始，它由一個MBean（PermissionsCacheMBean）組成，它以org.apache.cassandra.auth.PermissionsCache的形式向客戶端公開。我們將在第13章討論這個MBean。

使用nodetool進行監控

我們已經在之前的章節中探討了nodetool提供的一些命令，但讓我們藉此機會正確介紹。

nodetool附帶Cassandra，可以在 / bin中找到。這是一個命令行程序，它提供了豐富的方法來查看您的羣集，瞭解其活動並對其進行修改。 nodetool允許您獲得有關羣集的有限統計信息，查看每個節點維護的範圍，將數據從一個節點移動到另一個節點，停用節點，甚至修復有問題的節點。

nodetool和JMX的重疊

nodetool中的許多任務與JMX接口中可用的功能重疊。這是因爲，在幕後，nodetool使用名爲org.apache .cassandra .tools.NodeProbe的幫助程序類調用JMX。因此JMX正在做實際工作，NodeProbe類用於連接到JMX代理並檢索數據，NodeCmd類用於在交互式命令行界面中呈現它。

nodetool使用與Cassandra守護程序相同的環境設置：Unix上的bin / cassandra.in.sh和conf / cassandra-env.sh（或Windows上的bin / cassandra.in.bat和conf / cassandra-env.ps1）。日誌記錄設置位於conf / logback-tools.xml文件中;這些工作方式與conf / logback.xml中的Cassandra守護程序日誌記錄設置相同。

啓動nodetool是一件輕而易舉的事。只需打開終端，導航到，然後輸入以下命令：

$ bin/nodetool help

這會導致程序打印一個可用命令列表，其中幾個我們將暫時介紹。不帶參數運行nodetool等同於help命令。您還可以使用特定命令的名稱執行幫助以獲取其他詳細信息。

連接到特定節點

除help命令外，nodetool必須連接到Cassandra節點才能訪問有關該節點或集羣的信息。

您可以使用-h選項來標識要與nodetool連接的節點的IP地址。如果未指定IP地址，則該工具會嘗試連接到本地計算機上的默認端口，這是本章中我們將採用的示例方法。

獲取羣集信息

您可以獲得有關羣集及其節點的各種信息，我們將在本節中介紹這些信息。您可以獲得有關單個節點或參與環的所有節點的基本信息。

describecluster

describecluster命令打印出有關集羣的基本信息，包括名稱，告密者和分區器：

$ bin/nodetool describecluster
Cluster Information:
  Name: Test Cluster
  Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
  Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
  Schema versions:
    2d4043cb-2124-3589-b2d0-375759b9dd0a: [127.0.0.1, 127.0.0.2, 127.0.0.3]]

輸出的最後一部分對於識別表定義中的任何不一致或節點之間的“模式”尤其重要。當Cassandra通過集羣傳播模式更改時，通常會快速解決任何差異，因此任何延遲的模式差異通常表示需要重新啓動的節點已關閉或無法訪問。

狀態

識別羣集中節點以及它們所處狀態的更直接方法是使用status命令：

$ bin/nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens  Owns  Host ID
UN  127.0.0.1  103.82 KB  256     ?     31d9042b-6603-4040-8aac-fef0a235570b
UN  127.0.0.2  110.9 KB   256     ?     caad1573-4157-43d2-a9fa-88f79344683d
UN  127.0.0.3  109.6 KB   256     ?     e78529c8-ee9f-46a4-8bc1-3479f99a1860

狀態由數據中心和機架組織。每個節點的狀態由雙字符代碼標識，其中第一個字符指示節點是否已啓動（當前可用並準備好查詢）或向下，第二個字符指示節點的狀態或操作模式。 load列表示每個節點持有的數據的字節數。

owns列指示節點擁有的令牌範圍的有效百分比，並考慮複製。因爲我們沒有指定鍵空間，並且此集羣中的各種鍵空間具有不同的複製策略，所以nodetool無法計算有意義的所有權百分比。

信息

info命令告訴nodetool連接單個節點並獲取有關其當前狀態的基本數據。只需將您想要信息的節點的地址傳遞給它：

$ bin/nodetool -h 192.168.2.7 info
ID                     : 197efa22-ecaa-40dc-a010-6c105819bf5e
Gossip active          : true
Thrift active          : false
Native Transport active: true
Load                   : 301.17 MB
Generation No          : 1447444152
Uptime (seconds)       : 1901668
Heap Memory (MB)       : 395.03 / 989.88
Off Heap Memory (MB)   : 2.94
Data Center            : datacenter1
Rack                   : rack1
Exceptions             : 0
Key Cache              : entries 85, size 8.38 KB, capacity 49 MB,
  47958 hits, 48038 requests, 0.998 recent hit rate, 14400 save 
  period in seconds
Row Cache              : entries 0, size 0 bytes, capacity 0 bytes,
  0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds
Counter Cache          : entries 0, size 0 bytes, capacity 24 MB, 
  0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds
Token                  : (invoke with -T/--tokens to see all 256 tokens)

報告的信息包括節點的內存和磁盤使用情況（“負載”）以及Cassandra提供的各種服務的狀態。您還可以通過nodetool命令statusgossip，statusthrift，statusbinary和statushandoff檢查各個服務的狀態（請注意，切換狀態不是信息的一部分）。

環

要確定環中的節點以及它們所處的狀態，請在nodetool上使用ring命令，如下所示：

$ bin/nodetool ring
Datacenter: datacenter1
==========
Address      Rack   Status State   Load      Owns   Token                                       
                                                    9208237582789476801 
192.168.2.5  rack1  Up     Normal  243.6 KB  ?      -9203905334627395805
192.168.2.6  rack1  Up     Normal  243.6 KB  ?      -9145503818225306830
192.168.2.7  rack1  Up     Normal  243.6 KB  ?      -9091015424710319286

此輸出按vnodes組織。在這裏，我們看到環中所有節點的IP地址。在這種情況下，我們有三個節點，所有節點都已啓動（當前可用且已準備好進行查詢）。 load列表示每個節點持有的數據的字節數。描述命令的輸出類似，但是圍繞令牌範圍組織。

nodetool提供的其他有用狀態命令包括：

getLoggingLevels和setLoggingLevels命令允許使用我們之前討論過的Logback JMXConfiguratorMBean動態配置日誌記錄級別。
gossipinfo命令通過八卦將此節點與其自身通信的參數打印到其他節點。
version命令打印此節點正在運行的Cassandra版本。

獲取統計數據

nodetool還允許您在聚合級別以及特定鍵空間和表的級別收集有關服務器狀態的統計信息。兩個最常用的命令是tpstats和tablestats，我們現在都要檢查它們。

使用tpstats

tpstats工具爲我們提供了有關Cassandra維護的線程池的信息。 Cassandra高度併發，並針對多處理器/多核機器進行了優化。此外，Cassandra在內部採用了分階段事件驅動架構（SEDA），因此瞭解線程池的行爲和運行狀況對於良好的Cassandra維護非常重要。

要查找有關線程池的統計信息，請使用tpstats命令執行nodetool：

$ bin/nodetool tpstats
Pool Name            Active  Pending   Completed   Blocked  All time 
                                                             blocked
ReadStage                 0        0         216         0         0
MutationStage             1        0        3637         0         0
CounterMutationStage      0        0           0         0         0
ViewMutationStage         0        0           0         0         0
GossipStage               0        0           0         0         0
RequestResponseStage      0        0           0         0         0
AntiEntropyStage          0        0           0         0         0
MigrationStage            0        0           2         0         0
MiscStage                 0        0           0         0         0
InternalResponseStage     0        0           2         0         0
ReadRepairStage           0        0           0         0         0

Message type           Dropped
READ                         0
RANGE_SLICE                  0
_TRACE                       0
HINT                         0
MUTATION                     0
COUNTER_MUTATION             0
BATCH_STORE                  0
BATCH_REMOVE                 0
REQUEST_RESPONSE             0
PAGED_RANGE                  0
READ_REPAIR                  0

輸出的頂部顯示了每個Cassandra線程池中的任務數據。您可以直接查看處於哪個階段的操作數量，以及它們是處於活動狀態，待處理狀態還是已完成狀態。在寫入操作期間捕獲此輸出，因此顯示MutationStage中存在活動任務。

輸出的底部指示節點的已刪除消息數。丟棄的消息是Cassandra減載實現的一個指標，當每個節點收到的請求超過它可以處理的數量時，每個節點都會使用它來保護自己。例如，節點接收但未在rpc_timeout內處理的節點間消息被丟棄而不是處理，因爲協調節點將不再等待響應。

在輸出中看到大量的零用於被阻止的任務和丟棄的消息意味着您在服務器上的活動非常少，或者Cassandra在保持負載方面做得非常出色。很多非零值表示Cassandra很難跟上的情況，並且可能表明需要第12章中描述的某些技術。

使用tablestats

要查看鍵空間和表的概述統計信息，可以使用tablestats命令。您也可以從之前的名稱cfstats中識別此命令。以下是酒店鍵空間的示例輸出：

$ bin/nodetool tablestats hotel
Keyspace: hotel
    Read Count: 8
    Read Latency: 0.617 ms.
    Write Count: 13
    Write Latency: 0.13330769230769232 ms.
    Pending Flushes: 0
        Table: hotels
        SSTable count: 3
        Space used (live): 16601
        Space used (total): 16601
        Space used by snapshots (total): 0
        Off heap memory used (total): 140
        SSTable Compression Ratio: 0.6277372262773723
        Number of keys (estimate): 19
        Memtable cell count: 8
        Memtable data size: 792
        Memtable off heap memory used: 0
        Memtable switch count: 1
        Local read count: 8
        Local read latency: 0.680 ms
        Local write count: 13
        Local write latency: 0.148 ms
        Pending flushes: 0
        Bloom filter false positives: 0
        Bloom filter false ratio: 0.00000
        Bloom filter space used: 56
        Bloom filter off heap memory used: 32
        Index summary off heap memory used: 84
        Compression metadata off heap memory used: 24
        Compacted partition minimum bytes: 30
        Compacted partition maximum bytes: 149
        Compacted partition mean bytes: 87
        Average live cells per slice (last five minutes): 1.0
        Maximum live cells per slice (last five minutes): 1
        Average tombstones per slice (last five minutes): 1.0
        Maximum tombstones per slice (last five minutes): 1

這裏我們省略了鍵空間中其他表的輸出，因此我們可以專注於酒店表; 爲每個表生成相同的統計信息。我們可以在鍵空間和表級看到讀寫延遲和讀寫總數。我們還可以看到有關Cassandra每個表的內部結構的詳細信息，包括memtables，Bloom過濾器和SSTables。

總結

在本章中，我們介紹了監視和管理Cassandra集羣的方法。特別是，我們詳細介紹了JMX，並瞭解了Cassandra爲MBean服務器提供的各種操作。我們瞭解瞭如何使用JConsole和nodetool來查看Cassandra集羣中發生的情況。您現在已準備好了解如何執行日常維護任務以幫助保持Cassandra集羣的健康。

第十章：Cassandra監控--Cassandra：The Definitive Guide 2nd Edition

記錄