ScyllaDB University Live | Free Virtual Training Event
Learn more
ScyllaDB Documentation Logo Documentation
  • Deployments
    • Cloud
    • Server
  • Tools
    • ScyllaDB Manager
    • ScyllaDB Monitoring Stack
    • ScyllaDB Operator
  • Drivers
    • CQL Drivers
    • DynamoDB Drivers
    • Supported Driver Versions
  • Resources
    • ScyllaDB University
    • Community Forum
    • Tutorials
Install
Search Ask AI
ScyllaDB Docs ScyllaDB Operator Troubleshoot Change log level on a live cluster

Caution

You're viewing documentation for an unstable version of ScyllaDB Operator. Switch to the latest stable version.

Change log level on a live cluster¶

Change the ScyllaDB log level without a full rolling restart. This is useful when a rolling restart is not feasible — for example, when a StatefulSet is stuck mid-rollout or the cluster is degraded.

When to use each method¶

Scenario

Method

Persistent?

Normal operations — rolling restart is acceptable

Spec change

Yes

StatefulSet stuck mid-rollout

REST API

No — lost on pod restart

Cluster degraded — cannot tolerate a rolling restart

REST API

No — lost on pod restart

Method 1: Spec change (rolling restart)¶

Add the log level argument to the ScyllaCluster spec:

apiVersion: scylla.scylladb.com/v1
kind: ScyllaCluster
metadata:
  name: my-cluster
  namespace: scylla
spec:
  # ... existing configuration ...
  scyllaArgs: "--default-log-level=debug"

Apply the change:

kubectl apply --server-side -f scylla-cluster.yaml

ScyllaDB Operator performs a rolling restart to apply the new argument.

See Passing ScyllaDB arguments for details.

Method 2: REST API (no restart)¶

Use the ScyllaDB REST API to change the log level on running pods without triggering a rollout.

Change log level on a single pod¶

kubectl -n scylla exec <pod-name> -c scylla -- \
  curl -s -X POST "http://localhost:10000/system/logger/<logger-name>?level=<level>"

Where:

  • <logger-name> is the logger to adjust (e.g., compaction, gossip, storage_proxy)

  • <level> is the desired level: error, warn, info, debug, trace

To set all loggers at once, omit the logger name from the path:

kubectl -n scylla exec <pod-name> -c scylla -- \
  curl -s -X POST "http://localhost:10000/system/logger?level=<level>"

Example — set all loggers to debug:

kubectl -n scylla exec <pod-name> -c scylla -- \
  curl -s -X POST "http://localhost:10000/system/logger?level=debug"

Change log level on all pods¶

NAMESPACE=scylla
CLUSTER=my-cluster

for pod in $(kubectl -n "${NAMESPACE}" get pods \
  -l scylla/cluster="${CLUSTER}" \
  -l scylla-operator.scylladb.com/pod-type=scylladb-node \
  -o jsonpath='{.items[*].metadata.name}'); do
  echo "Setting log level on ${pod}..."
  kubectl -n "${NAMESPACE}" exec "${pod}" -c scylla -- \
    curl -s -X POST "http://localhost:10000/system/logger?level=debug"
done

Verify the change¶

Check the level of a specific logger:

kubectl -n scylla exec <pod-name> -c scylla -- \
  curl -s "http://localhost:10000/system/logger/compaction"

The response is the current log level (e.g., "debug").

Important notes¶

Caution

REST API log level changes are ephemeral — they are lost when the pod restarts. To make the change persistent, update the ScyllaCluster spec as described in Method 1.

  • Debug and trace levels generate significantly more log output and can impact performance. Revert to info once you have collected the needed diagnostics.

  • In a stuck rollout scenario, ScyllaDB Operator cannot process spec changes because the rollout is blocked. The REST API is the only way to change log levels on pods that are already running. See StatefulSets and racks for why a stuck rollout blocks further updates (partition-based rolling updates).

Related pages¶

  • Passing ScyllaDB arguments

  • StatefulSets and racks

Was this page helpful?

PREVIOUS
Investigate pod restarts
NEXT
Recover from a failed node replace
  • Create an issue
  • Edit this page

On this page

  • Change log level on a live cluster
    • When to use each method
    • Method 1: Spec change (rolling restart)
    • Method 2: REST API (no restart)
      • Change log level on a single pod
      • Change log level on all pods
      • Verify the change
      • Important notes
    • Related pages
ScyllaDB Operator
Search Ask AI
  • master
    • master
    • v1.21
    • v1.20
    • v1.19
    • v1.18
  • Get Started
    • What Is ScyllaDB Operator?
    • ScyllaDB Concepts on Kubernetes
  • Install Operator
    • Provision infrastructure
      • Set up a GKE cluster for ScyllaDB
      • Set up an EKS cluster for ScyllaDB
      • Set up an OKE cluster for ScyllaDB
      • Set up an OpenShift cluster for ScyllaDB
    • Install with GitOps
    • Install with Helm
    • Install on OpenShift
  • Deploy ScyllaDB
    • Before you deploy
      • Set up dedicated node pools
      • Configure CPU pinning
      • Configure nodes
      • Configure ScyllaDB Operator
    • Deploy your first cluster
    • Reference deployments
      • Reference deployment: GKE
      • Reference deployment: EKS
      • Reference deployment: OKE
      • Reference deployment: OpenShift
    • Install ScyllaDB Manager
    • Set up networking
      • Configure external access
      • IPv6 networking
        • Getting started with IPv6 networking
        • Configure dual-stack networking
        • Configure IPv6-only networking
        • Migrate clusters to IPv6
        • Troubleshoot IPv6 networking issues
        • IPv6 networking concepts
    • Set up monitoring
      • Set up ScyllaDB Monitoring
      • Set up ScyllaDB Monitoring on OpenShift
      • Expose Grafana
    • Production checklist
  • Connect Your App
    • Connect via CQL
    • Alternator (DynamoDB API)
    • Discovery endpoint
  • Understand
    • Storage
    • Tuning
    • ScyllaDB Manager
    • Networking
    • ScyllaDB Monitoring overview
    • Bootstrap synchronisation
    • Automatic data cleanup
    • Sidecar and pod anatomy
    • Ignition
    • Pod disruption budgets
    • Security
    • StatefulSets and racks
  • Operate
    • Scale, add, remove racks
    • Replace nodes
    • Expand storage volumes
    • Use maintenance mode
    • Back up and restore
    • Restore from backup
    • Perform a rolling restart
    • Migrate a rack to a new node pool
    • Pass additional ScyllaDB arguments
    • Configure precomputed IO properties
  • Upgrade
    • Upgrading ScyllaDB Operator
    • Upgrading ScyllaDB clusters
  • Troubleshoot
    • Investigate pod restarts
    • Change log level on a live cluster
    • Recover from a failed node replace
    • Troubleshoot performance
    • Collect debugging information
      • Collect data with must-gather
      • must-gather contents
      • Query system tables for debugging
    • Collect core dumps
  • Reference
    • API Reference
      • scylla.scylladb.com
        • NodeConfig (scylla.scylladb.com/v1alpha1)
        • RemoteKubernetesCluster (scylla.scylladb.com/v1alpha1)
        • RemoteOwner (scylla.scylladb.com/v1alpha1)
        • ScyllaCluster (scylla.scylladb.com/v1)
        • ScyllaDBCluster (scylla.scylladb.com/v1alpha1)
        • ScyllaDBDatacenterNodesStatusReport (scylla.scylladb.com/v1alpha1)
        • ScyllaDBDatacenter (scylla.scylladb.com/v1alpha1)
        • ScyllaDBManagerClusterRegistration (scylla.scylladb.com/v1alpha1)
        • ScyllaDBManagerTask (scylla.scylladb.com/v1alpha1)
        • ScyllaDBMonitoring (scylla.scylladb.com/v1alpha1)
        • ScyllaOperatorConfig (scylla.scylladb.com/v1alpha1)
    • Feature gates
    • IPv6 configuration reference
    • Releases
    • Known issues
    • Conditions reference
    • nodetool alternatives
  • Contributing to ScyllaDB Operator
Docs Tutorials University Contact Us About Us
© 2026, ScyllaDB. All rights reserved. | Terms of Service | Privacy Policy | ScyllaDB, and ScyllaDB Cloud, are registered trademarks of ScyllaDB, Inc.
Last updated on 22 May 2026.
Powered by Sphinx 9.1.0 & ScyllaDB Theme 1.9.2