Guides
Production Checks
Understand runtime failures, recovery order, and post-recovery checks.
This page describes the runtime impact of production environment failures, the recommended recovery sequence, and post-recovery verification procedures.
General recovery sequence
- Restore external backing components first.
- Restore OpenIMServer next.
- Restore ChatServer last.
External component failures
| Component failure | Runtime impact | Recovery procedure |
|---|---|---|
| MongoDB unavailable | OpenIMServer 10002 may still respond, but ChatServer and App Administrator APIs usually fail | Restore MongoDB; immediately retest 10002, 10008, and 10009, restarting OpenIMServer and ChatServer only if anomalies persist |
| Redis unavailable | OpenIMServer authentication path breaks; source deployments typically log auth-rpc-service down, while integrated Docker deployments report Redis connection or resolution failures | Restore Redis; wait 30-60s, and restart OpenIMServer only if authentication remains abnormal |
| Kafka unavailable | Basic health probes may still pass, but message routing and push pipelines fail | Restore Kafka, then execute end-to-end verification across message sending, consumption, and push delivery |
| Etcd unavailable | Currently running service instances often continue serving briefly, but service restarts fail | Restore Etcd; restart OpenIMServer and ChatServer only if service discovery fails to recover automatically |
| MinIO unavailable | File uploads and downloads fail; integrated Docker deployments may also experience cascading probe failures across 10002, 10008, and 10009 | Restore MinIO and verify externalAddress; if basic probes do not recover after 30-60s, restart the application stack |
Restore external components
openim-docker deployment:
cd /path/to/openim-docker
docker compose up -d mongo redis kafka etcd minioOpenIMServer source deployment:
cd /path/to/open-im-server
docker compose up -d mongodb redis kafka etcd minioopenim-dockerdefaults to service namemongo, whereasopen-im-serverdefaults tomongodb.
OpenIMServer failures
| Service failure | Runtime impact | Recovery procedure |
|---|---|---|
openim-api | Port 10002 is typically unreachable | Restart services from the open-im-server directory |
openim-rpc-auth | OpenIMServer authentication probes fail; ChatServer probes may remain accessible | Restart services from the open-im-server directory |
openim-msggateway | Real-time WebSocket connectivity is interrupted | Restart services from the open-im-server directory |
openim-msgtransfer / openim-push | Message transfer or push pipelines degrade without necessarily triggering basic probe failures | Restart services, then execute end-to-end message verification |
openim-crontask | Scheduled background tasks halt | Restart services from the open-im-server directory |
cd /path/to/open-im-server
mage check
mage stop
mage start
mage checkChatServer failures
| Service failure | Runtime impact | Recovery procedure |
|---|---|---|
chat-api | Application business API 10008 is typically unreachable | Restart services from the chat directory |
chat-rpc | Core ChatServer business calls fail, even if the basic HTTP port remains open | Restart services from the chat directory |
admin-api | App Administrator API 10009 is typically unreachable, though 10008 may remain functional | Restart services from the chat directory |
admin-rpc | App Administrator business calls fail | Restart services from the chat directory |
bot-api / bot-rpc | Bot-related capabilities malfunction | Restart services from the chat directory |
cd /path/to/chat
mage check
mage stop
mage start
mage checkPost-recovery verification
- Confirm that
mage checkordocker psoutputs healthy status. - Verify that all three core health probes (
10002,10008,10009) have recovered. - Following Kafka or MinIO outages, conduct comprehensive end-to-end validation of messaging and media upload/download pipelines.
All basic health check probes for OpenIMServer and ChatServer must include the operationID HTTP header.