如何使用MetricsServlet获取Cassandra节点指标（无需JMX）

Great question! I’ve set up MetricsServlet for pulling Cassandra metrics in JSON (no JMX required) a few times, so let’s walk through this step-by-step with actionable examples.

Step 1: Match Metrics Versions & Add Dependencies #

Cassandra relies on Dropwizard Metrics (formerly Yammer Metrics) under the hood. To avoid classloader conflicts, you must use a metrics-servlets jar that matches the exact version of metrics-core included with your Cassandra installation.

• First, check your Cassandra's Metrics version: Navigate to your Cassandra lib directory and look for a file named metrics-core-<version>.jar (e.g., metrics-core-4.2.12.jar for Cassandra 4.1.2).
• Download the corresponding metrics-servlets-<version>.jar.
• Copy the downloaded jar into the lib directory of every Cassandra node you want to monitor.

Step 2: Configure Jetty to Host the MetricsServlet #

The setup varies slightly between Cassandra 3.x and 4.x, since 4.x introduced a built-in HTTP server.

For Cassandra 4.x+ #

1. Enable the built-in HTTP server in cassandra.yaml:

   http_server_enabled: true
   http_server_port: 8080  # Customize this port if needed
   

2. Create a new Jetty config file in your Cassandra conf directory (e.g., metrics-jetty.xml) with this content:

   <Configure id="Server" class="org.eclipse.jetty.server.Server">
     <Call name="getServletHandler">
       <Call name="addServletWithMapping">
         <Arg>com.codahale.metrics.servlets.MetricsServlet</Arg>
         <Arg>/metrics/*</Arg>
       </Call>
     </Call>
   </Configure>
   

3. Update cassandra-env.sh to include this new config:

   # If JETTY_CONF doesn't exist yet, add this line
   JETTY_CONF="$CASSANDRA_CONF/metrics-jetty.xml"
   # If JETTY_CONF already exists, append the new config instead:
   # JETTY_CONF="$JETTY_CONF $CASSANDRA_CONF/metrics-jetty.xml"
   

For Cassandra 3.x #

Cassandra 3.x doesn’t have a built-in HTTP server, so we’ll configure Jetty manually:

1. Create a jetty.xml file in your conf directory:

   <Configure id="Server" class="org.eclipse.jetty.server.Server">
     <Set name="port">8080</Set>
     <Call name="addBean">
       <Arg>
         <New class="org.eclipse.jetty.servlet.ServletContextHandler">
           <Set name="contextPath">/</Set>
           <Call name="addServlet">
             <Arg>com.codahale.metrics.servlets.MetricsServlet</Arg>
             <Arg>/metrics/*</Arg>
           </Call>
         </New>
       </Arg>
     </Call>
   </Configure>
   

2. Modify cassandra-env.sh to start Jetty with this config:

   # Add Jetty startup parameters to JVM_OPTS
   JVM_OPTS="$JVM_OPTS -Djetty.config=$CASSANDRA_CONF/jetty.xml"
   JVM_OPTS="$JVM_OPTS -jar $CASSANDRA_HOME/lib/jetty-server-*.jar"
   

   Note: Cassandra 3.x already includes Jetty jars in its lib directory, so no extra downloads are needed here.

Step 3: Restart Cassandra Nodes #

Restart each Cassandra node to apply the configuration changes. Once nodes are back up, the MetricsServlet will be running.

Step 4: Fetch Metrics in JSON #

Use curl (or any HTTP client) to hit the metrics endpoint. For example:

curl http://<your-node-ip>:8080/metrics

This returns a large JSON object with all available metrics, organized into categories like gauges, timers, counters, and histograms.

Example: Filter for Specific Metrics #

If you want to pull just read latency data (a common metric), use a tool like jq to filter the JSON response:

# Install jq first if you haven't: sudo apt install jq (Debian/Ubuntu) or brew install jq (macOS)
curl http://<your-node-ip>:8080/metrics | jq '.timers["org.apache.cassandra.db.ColumnFamily.read_latency"]'

This will return details like average latency, 95th/99th percentile latencies, request counts, and more.

Key Notes #

• Security: By default, the MetricsServlet has no authentication. In production, add Jetty basic auth or restrict access via firewall rules to prevent sensitive metric exposure.
• Performance: The servlet itself has minimal overhead, but avoid polling metrics too frequently (e.g., more than once every 10 seconds) to prevent unnecessary load on nodes.
• Version Consistency: Always double-check that metrics-servlets version matches your Cassandra's metrics-core version—mismatches will cause runtime errors like NoClassDefFoundError.

内容的提问来源于stack exchange，提问作者Vishal Sharma