Scenario
A microservices platform relies on Redis for caching, RabbitMQ for async messaging, and Kafka for event streaming. Suddenly, the platform experiences latency spikes, message processing failures, and data inconsistencies.
Redis Reliability
Symptoms
- Cache hit rate drops below 80%
- Command timeouts (e.g.,
GETlatency > 10ms) - Memory usage exceeds 80% (high used_memory_rss in
INFO memory)
Diagnosis
- Check slow queries:
SLOWLOG GET 10 - Check memory fragmentation:
INFO memorymem_fragmentation_ratio (>1.5 indicates fragmentation) - Check persistence issues:
INFO persistenceshows long rdb_last_bgsave_time_sec
Commands & Risk Controls
# View slow queries
redis-cli -h localhost -p 6379 SLOWLOG GET 10
# Analyze memory fragmentation
redis-cli MEMORY PURGE
# Note: MEMORY PURGE can block; run during low traffic.
Rollback
- If caused by config changes, revert config and restart:
redis-cli CONFIG SET save ""to revert persistence. - Use
REPLICAOF NO ONEto stop replication, then resync.
Verification
- Re-check slow queries:
SLOWLOG RESETthen benchmark. - Verify memory:
redis-cli INFO memory | grep used_memoryshould be stable.
When to Submit an OpsGlobal Ticket
- When slow queries or memory issues persist despite internal optimization.
- When cluster resharding or upgrade is needed.
RabbitMQ Reliability
Symptoms
- Message backlog: queue messages grow continuously (
rabbitmqctl list_queuesshows increasing message count). - Connection drops:
rabbitmqctl list_connectionsshows many unexpected disconnections. - High memory alarm:
rabbitmqctl statusshows vm_memory_high_watermark_paging_ratio > 0.5.
Diagnosis
- Check queue details:
rabbitmqctl list_queues name messages consumers memory - Check logs:
/var/log/rabbitmq/rabbit@host.logfor "alarm" - Check network:
netstat -an | grep 5672
Commands & Risk Controls
# View all queues
rabbitmqctl list_queues --silent name messages consumers memory
# Force purge a queue (destructive)
rabbitmqctl purge_queue <queue_name>
# Note: Purge loses all messages; use only if certain it's safe.
Rollback
- If memory threshold was changed, revert:
rabbitmqctl set_vm_memory_high_watermark 0.4 - If queue mirroring was added, remove:
rabbitmqctl set_policy ha-all "" ".*" '{"ha-mode":"exactly","ha-params":1}'
Verification
- Confirm message consumption rate recovers: use
rabbitmqctl list_queuesand see message count decreasing. - Test publish and consume with sample code.
When to Submit an OpsGlobal Ticket
- When message backlog impacts business and internal tuning fails.
- When migration or upgrade of RabbitMQ cluster is required.
Kafka Reliability
Symptoms
- Consumer lag increases:
kafka-consumer-groups --bootstrap-server localhost:9092 --group <group> --describeshows LAG growing. - Replicas out of sync:
kafka-topics --describe --topic <topic>shows ISR missing or smaller than replication factor. - High disk usage: Broker logs report "Disk usage exceeds threshold".
Diagnosis
- View consumer group lag:
kafka-consumer-groups --bootstrap-server localhost:9092 --all-groups --describe - Check replica sync:
kafka-topics --describe --topic <topic> - Check disk:
df -hand Kafka logs for disk warnings.
Commands & Risk Controls
# View specific consumer group
kafka-consumer-groups --bootstrap-server localhost:9092 --group my-group --describe
# Change retention to purge old data (risky)
kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name <topic> --alter --add-config retention.ms=604800000
# Note: Shorter retention loses data; confirm necessity.
Rollback
- If retention was changed, revert:
retention.ms=original_value - If partition reassignment was done, stop and revert to original.
Verification
- Check lag decreases: re-run
--describe. - Check ISR restored:
kafka-topics --describeshows all replicas in-sync.
When to Submit an OpsGlobal Ticket
- When consumer lag persists despite consumer optimization.
- When cluster expansion or disk I/O bottleneck resolution is needed.
Use cases
Useful for teams handling NoSQL issues and needing a clear troubleshooting and delivery workflow.
Problem background
Learn how to diagnose and resolve common reliability issues with Redis, RabbitMQ, and Kafka in production environments. This guide covers real-world scenarios, symptoms, diagnostic commands, risk controls, rollback procedures, and verification steps for each middleware.
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.