OpenIM Monitoring with Vigilmon: API Gateway, Message Delivery & Admin Dashboard Checks

Your OpenIM deployment is the backbone of real-time communication for your users. At 3 AM, the push notification relay quietly crashes. Messages queue up. Users try to reconnect. The WebSocket endpoint stops accepting new connections. Nobody knows — because all your internal dashboards are still green.

OpenIM is an open-source instant messaging platform built on Go microservices. It provides a complete SDK and server stack for embedding IM functionality into applications — including group chat, file transfer, real-time presence, and push notifications. Self-hosting OpenIM means you own the infrastructure, but you also own the monitoring.

Vigilmon gives you external uptime monitoring that watches OpenIM from the outside, the way your users experience it. This tutorial walks you through monitoring every critical OpenIM service endpoint.

What You'll Build

• An HTTP monitor on OpenIM's API gateway health endpoint
• A WebSocket connectivity monitor for the message delivery pipeline
• A monitor for the user presence service
• A push notification relay availability check
• An admin dashboard monitor with keyword verification
• Alert channels for immediate notification when any service degrades

Prerequisites

• A self-hosted OpenIM server (v3.x recommended)
• Default ports: API gateway port 10002, WebSocket port 10001, admin port 11002
• A free account at vigilmon.online

Step 1: Monitor the API Gateway Health Endpoint

OpenIM's API gateway is the entry point for all client SDK calls — authentication, user management, and message sending all flow through it. OpenIM exposes a health check route you can poll without authentication.

Test it from your server or a machine with network access:

curl http://your-openim-host:10002/healthz

Expected response:

{
  "status": "ok"
}

A 200 response confirms the API gateway process is alive and its internal routing is functional. A non-200 or a connection refusal means clients cannot authenticate or send messages.

Set up the Vigilmon monitor:

1. Log in to Vigilmon and click New Monitor → HTTP.
2. Set URL to http://your-openim-host:10002/healthz.
3. Set Check interval to 60 seconds.
4. Set Expected status code to 200.
5. Under Advanced → Keyword check, add:
   • Keyword present: "ok"
6. Save the monitor.

If your API gateway is behind a reverse proxy (Nginx, Caddy, Traefik), monitor the proxied URL instead so you catch proxy-layer failures too.

Step 2: Monitor the WebSocket Message Delivery Pipeline

OpenIM clients maintain persistent WebSocket connections to receive real-time messages. If the WebSocket service on port 10001 goes down, users appear connected in the UI but stop receiving new messages — a silent failure that's hard to notice without external monitoring.

You can check WebSocket endpoint reachability with a simple HTTP HEAD or GET against the upgrade path:

curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Version: 13" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  http://your-openim-host:10001/

A 101 Switching Protocols or a 400 Bad Request (indicating the endpoint exists but rejected the incomplete handshake) both confirm the service is running and listening.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to http://your-openim-host:10001/.
3. Set Expected status code to one of: 101, 400, or 200 — whichever your OpenIM version returns on a bare GET to the WebSocket port.
4. Set Check interval to 60 seconds.
5. Save the monitor.

This catches the WebSocket process being down entirely. For deeper message delivery validation, route a synthetic test message through your integration test pipeline separately.

Step 3: Monitor the User Presence Service

OpenIM tracks which users are online through a dedicated presence service. If this service fails, online/offline status becomes stale — users appear online when they've disconnected, or offline when they're active. This breaks read receipts and delivery routing.

OpenIM's internal RPC services expose health checks that you can access via the gateway or directly if the ports are reachable:

curl http://your-openim-host:10002/user/user_info \
  -H "Content-Type: application/json" \
  -d '{"userIDs": ["health_check_probe"]}'

Alternatively, check whether the gateway routes presence-related API calls correctly by hitting the user check endpoint:

curl -o /dev/null -s -w "%{http_code}" \
  http://your-openim-host:10002/user/get_users_online_status \
  -H "Content-Type: application/json" \
  -d '{"userIDs": []}'

An empty user list query returns a structured JSON response (not an error) when the presence service is healthy.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to http://your-openim-host:10002/healthz (the gateway health endpoint also validates internal RPC connectivity).
3. Alternatively, if you have a dedicated presence probe endpoint, monitor it directly.
4. Set Check interval to 120 seconds.
5. Add a keyword assertion to confirm the response body is valid JSON.
6. Save the monitor.

Step 4: Monitor the Push Notification Relay

OpenIM routes push notifications through a dedicated relay service that forwards messages to APNs (Apple) and FCM (Google) for mobile clients. If this relay goes down, mobile users stop receiving push notifications — but won't notice until they open the app and see missed messages.

The push relay is part of the OpenIM microservice stack. Monitor it by checking whether the API gateway returns a healthy status for notification-adjacent endpoints:

curl http://your-openim-host:10002/msg/send_msg \
  -H "Content-Type: application/json" \
  -d '{"sendID": "probe", "recvID": "probe", "content": "healthcheck"}'

Even an authentication rejection (401/403) confirms the message routing pipeline — including the push relay — is alive. A 502 or connection refusal means the pipeline is broken.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to http://your-openim-host:10002/msg/send_msg.
3. Set Method to POST.
4. Set Request body to:

   {"sendID": "probe", "recvID": "probe"}
   

5. Set Expected status code to any of 400, 401, 403 — these indicate the pipeline is up but rejected an invalid/unauthenticated probe request. A 502 or timeout is the failure case.
6. Save the monitor.

Step 5: Monitor the Admin Dashboard

OpenIM ships with a web-based admin panel on port 11002 for managing users, groups, and platform configuration. If the admin panel becomes unreachable, your operations team loses the ability to manage the platform during an incident.

curl -o /dev/null -s -w "%{http_code}" http://your-openim-host:11002/

The admin dashboard should return 200 with HTML content.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to http://your-openim-host:11002/.
3. Set Expected status code to 200.
4. Under Advanced → Keyword check, add:
   • Keyword present: "OpenIM" or the title string visible in the admin panel HTML source.
5. Set Check interval to 120 seconds.
6. Save the monitor.

The keyword check catches cases where the web server is up but the admin app is serving an error page instead of the real dashboard.

Step 6: Alert Channels

Go to Notifications → New Channel in Vigilmon and configure:

• Email — immediate alerts to your platform operations team
• Webhook — post to Slack, Discord, or PagerDuty

For Slack, a failing API gateway alert looks like:

🔴 DOWN: openim-api-gateway (HTTP monitor)
Expected status 200, got connection refused
Region: US-East
Triggered: 2026-03-10 03:42 UTC

When the service recovers:

✅ RECOVERED: openim-api-gateway
Downtime: 7 minutes

Set escalation policies for critical monitors (API gateway, WebSocket) to page on-call immediately, and use lower-urgency channels for the admin dashboard.

What You've Built

| Scenario | How Vigilmon catches it | |---|---| | API gateway process crash | HTTP monitor on :10002/healthz returns connection refused | | WebSocket service down | HTTP monitor on :10001 fails to reach the endpoint | | User presence RPC failure | Gateway health check fails; presence API returns 502 | | Push notification relay crash | Message send endpoint returns 502 instead of auth rejection | | Admin dashboard unavailable | HTTP monitor on :11002 detects non-200 or missing keyword | | Reverse proxy failure | Public-URL monitor catches 502 from Nginx/Caddy layer | | Server out of disk/memory | All monitors start timing out simultaneously |

OpenIM handles real-time communication at scale — but microservice architectures have many failure points. An external monitor from Vigilmon gives you the user's-eye view that internal dashboards miss, and catches silent failures before your users notice.

Start monitoring your OpenIM deployment today — register free at vigilmon.online.