Files

master 152c1b1357 doctor: complete runtime check documentation sprint

Signed-off-by: master <>

2026-03-31 23:26:24 +03:00

1.7 KiB

Raw Blame History

checkId, plugin, severity, tags

checkId

plugin

severity

Message Queue Connectivity

What It Checks

Reads RabbitMQ:Host or Messaging:RabbitMQ:Host plus an optional port, defaulting to 5672, and attempts a TCP connection.

The check skips when RabbitMQ is not configured and fails on timeouts, DNS failures, or refused connections.

Why It Matters

Release tasks, notifications, and deferred work often depend on a functioning message broker. A dead queue path turns healthy APIs into backlogged systems.

Common Causes

RabbitMQ__Host is unset or points to the wrong broker
The broker container is down
AMQP traffic is blocked between Doctor and RabbitMQ

How to Fix

Docker Compose

services:
  doctor-web:
    environment:
      RabbitMQ__Host: rabbitmq
      RabbitMQ__Port: "5672"

docker compose -f devops/compose/docker-compose.stella-ops.yml ps rabbitmq
docker compose -f devops/compose/docker-compose.stella-ops.yml logs --tail 100 rabbitmq
docker compose -f devops/compose/docker-compose.stella-ops.yml exec doctor-web sh -lc "nc -zv rabbitmq 5672"

Bare Metal / systemd

nc -zv <rabbit-host> 5672

Kubernetes / Helm

kubectl exec deploy/doctor-web -n <namespace> -- sh -lc "nc -zv <rabbit-service> 5672"

Verification

stella doctor --check check.servicegraph.mq

check.servicegraph.valkey - cache and queue connectivity usually fail together when service networking is broken
check.servicegraph.timeouts - aggressive timeouts can make a slow broker look unavailable

1.7 KiB Raw Blame History