Scenario
You are an SRE on call. Your team's e-commerce platform experiences order processing delays during flash sales. The architecture uses Redis for session caching, RabbitMQ for order queueing, and Kafka for event streaming. After a recent scaling event, latency spikes occur.
Symptoms
- Redis: Increased latency > 100ms, CPU high, evictions.
- RabbitMQ: Queue depth growing, consumers idle, disk alarm.
- Kafka: Consumer lag increasing, broker CPU high, replication underreplicated partitions.
Diagnosis
Redis
redis-cli info statscheck evicted_keys.redis-cli slowlog getfor slow commands.redis-cli client listfor connections.- Use
memory doctorif OOM.
RabbitMQ
rabbitmqctl list_queues name messages consumers memory.- Check disk and memory alarms via
rabbitmqctl status. - Enable trace logs if needed.
Kafka
kafka-consumer-groups --bootstrap-server <server> --describe --group <group>for lag.kafka-topics --describe --under-replicated-partitions.- Check broker logs and JMX metrics.
Commands (with safety notes)
Redis
- To clear slow commands, consider scaling read replicas or optimizing data structures. Use
CLIENT KILLcautiously.
RabbitMQ
- To unbind queues temporarily:
rabbitmqctl set_policyto limit queue length orrabbitmqadmin delete queuewith caution. Userabbitmqctl set_disk_free_limitto adjust alarms.
Kafka
- To throttle consumers: increase partitions or use consumer group rebalancing. For hot partitions,
kafka-reassign-partitions.sh. Never delete topics without backup.
Risk Controls
- Always snapshot Redis RDB/AOF before changes.
- For RabbitMQ, backup definitions with
rabbitmqadmin export. - For Kafka, back up offsets and topic configs. Use racks awareness.
Rollback Procedures
Redis
- Restore from RDB or AOF backup. Ensure no pending writes lost.
RabbitMQ
- Re-import definitions, purge queues if needed.
Kafka
- Reset consumer group offsets via
kafka-consumer-groups --reset-offsets. For data loss, replay from last committed.
Verification
- Redis:
redis-benchmarktest latency. Monitor evictions and hits/misses. - RabbitMQ: Publish test messages, verify consumption rate.
- Kafka: Produce and consume test records, check lag reduced.
When to submit an OpsGlobal ticket
- If root cause unclear after checks.
- If data loss occurred or risk of data loss.
- If Kubernetes pod restarts or persistent volume issues persist.
- If you need help with fine-tuning configurations or security hardening.
Use cases
Useful for teams handling NoSQL issues and needing a clear troubleshooting and delivery workflow.
Problem background
Production outages often originate from misconfigured or overloaded middleware. This guide walks through real-world scenarios, diagnostic commands, and rollback procedures for Redis, RabbitMQ, and Kafka, with Kubernetes deployment considerations.
Troubleshooting steps
Confirm impact and recent changes, collect logs, configuration and metrics, then apply fixes from low to high risk.
Command examples
Replace sample resource names with real values and store passwords, tokens and keys in environment variables.
Risks
Before production changes, confirm backups, access boundaries, change windows and rollback paths.
Rollback plan
Keep original configuration and release versions; roll back config, images or database changes if metrics degrade.
Deliverables
Root-cause notes, key commands, remediation steps, verification results and follow-up recommendations.
Need help with a similar technical issue?
If your servers, Kubernetes, Docker, CI/CD, databases or monitoring systems have similar issues, submit logs and config files for remote diagnosis.