Browse OpenIMSDK Guides
Guides

Production Checks

Understand runtime failures, recovery order, and post-recovery checks.

Copy

This page describes the runtime impact of production environment failures, the recommended recovery sequence, and post-recovery verification procedures.

General recovery sequence

  1. Restore external backing components first.
  2. Restore OpenIMServer next.
  3. Restore ChatServer last.

External component failures

Component failureRuntime impactRecovery procedure
MongoDB unavailableOpenIMServer 10002 may still respond, but ChatServer and App Administrator APIs usually failRestore MongoDB; immediately retest 10002, 10008, and 10009, restarting OpenIMServer and ChatServer only if anomalies persist
Redis unavailableOpenIMServer authentication path breaks; source deployments typically log auth-rpc-service down, while integrated Docker deployments report Redis connection or resolution failuresRestore Redis; wait 30-60s, and restart OpenIMServer only if authentication remains abnormal
Kafka unavailableBasic health probes may still pass, but message routing and push pipelines failRestore Kafka, then execute end-to-end verification across message sending, consumption, and push delivery
Etcd unavailableCurrently running service instances often continue serving briefly, but service restarts failRestore Etcd; restart OpenIMServer and ChatServer only if service discovery fails to recover automatically
MinIO unavailableFile uploads and downloads fail; integrated Docker deployments may also experience cascading probe failures across 10002, 10008, and 10009Restore 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 minio

OpenIMServer source deployment:

cd /path/to/open-im-server
docker compose up -d mongodb redis kafka etcd minio
openim-docker defaults to service name mongo, whereas open-im-server defaults to mongodb.

OpenIMServer failures

Service failureRuntime impactRecovery procedure
openim-apiPort 10002 is typically unreachableRestart services from the open-im-server directory
openim-rpc-authOpenIMServer authentication probes fail; ChatServer probes may remain accessibleRestart services from the open-im-server directory
openim-msggatewayReal-time WebSocket connectivity is interruptedRestart services from the open-im-server directory
openim-msgtransfer / openim-pushMessage transfer or push pipelines degrade without necessarily triggering basic probe failuresRestart services, then execute end-to-end message verification
openim-crontaskScheduled background tasks haltRestart services from the open-im-server directory
cd /path/to/open-im-server
mage check
mage stop
mage start
mage check

ChatServer failures

Service failureRuntime impactRecovery procedure
chat-apiApplication business API 10008 is typically unreachableRestart services from the chat directory
chat-rpcCore ChatServer business calls fail, even if the basic HTTP port remains openRestart services from the chat directory
admin-apiApp Administrator API 10009 is typically unreachable, though 10008 may remain functionalRestart services from the chat directory
admin-rpcApp Administrator business calls failRestart services from the chat directory
bot-api / bot-rpcBot-related capabilities malfunctionRestart services from the chat directory
cd /path/to/chat
mage check
mage stop
mage start
mage check

Post-recovery verification

  1. Confirm that mage check or docker ps outputs healthy status.
  2. Verify that all three core health probes (10002, 10008, 10009) have recovered.
  3. 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.