OKPing-Network-Monitor/rabbitmq

RabbitMQ for TCPTest

This directory provides a RabbitMQ deployment for TCPTest 1.0 node dispatch and WebSocket result consumption.

Start

chmod +x deploy-rabbitmq.sh
./deploy-rabbitmq.sh

The deployment script validates the Compose configuration, starts RabbitMQ without deleting its data volume, waits for the health check, and verifies the Prometheus metrics endpoint. The Compose stack also runs a one-time rabbitmq-init container to create TCPTest exchanges, queues and bindings through the RabbitMQ management API.

To deploy without pulling images again:

./deploy-rabbitmq.sh --skip-pull

If RabbitMQ previously failed with no_such_user, <<"ping">>, deploy the latest files and recreate the failed local volume once:

docker compose down -v
docker compose pull
docker compose up -d

Only run docker compose down -v when this is a fresh deployment or you do not need the existing RabbitMQ data.

If you deployed an older version of this directory, make sure the server no longer has definitions.json mounted in docker-compose.yml, and rabbitmq.conf no longer contains management.load_definitions.

You can also run the included reset script on a fresh failed deployment:

chmod +x reset-rabbitmq.sh
./reset-rabbitmq.sh

The script refuses to start if old definitions.json boot-import settings are still present.

Access

• AMQP: http://YOUR_SERVER_IP:5672 for backend connections
• Management UI: http://YOUR_SERVER_IP:15672
• Prometheus metrics: http://YOUR_SERVER_IP:15692/metrics
• Default user: guest
• Default password: guest
• VHost: /

Predefined Resources

• Exchange: ping_node
• Exchange: ping_logs
• Queue: ping_dev_node_result
• Queue: master
• Queue: ping_logs_python
• Binding: ping_logs -> ping_logs_python, routing key python

ping_node is the default node task exchange. Node-specific queues and bindings can still be generated by the TCPTest node configuration flow. These resources are created by the rabbitmq-init service after RabbitMQ becomes healthy.

RuoYi Dev Environment

Use these environment variables when starting the backend:

export RABBITMQ_HOST=127.0.0.1
export RABBITMQ_PORT=5672
export RABBITMQ_USERNAME=guest
export RABBITMQ_PASSWORD=guest
export RABBITMQ_VIRTUAL_HOST=/
export PING_NODE_RESULT_QUEUE=ping_dev_node_result

For production, set PING_NODE_RESULT_QUEUE=master or another isolated queue name that matches your node workers.

Change Password

Copy .env.example to .env, then edit ports if needed:

cp .env.example .env
docker compose up -d

This compose intentionally uses RabbitMQ's built-in guest user for first boot stability. Remote guest login is allowed by loopback_users.guest = false in rabbitmq.conf.

If your server has an old .env file with RABBITMQ_DEFAULT_USER=ping or RABBITMQ_DEFAULT_PASS=..., remove those lines before starting. They can make RabbitMQ try to set permissions for a user that does not exist during boot.

After RabbitMQ is running, change the password or create a dedicated user from the management UI for production use.

Open inbound 5672 and 15672 on the server firewall or security group if you need remote access.

Prometheus Metrics

The rabbitmq_prometheus plugin is enabled persistently by enabled_plugins. Queue-level metrics are enabled so TCPTest node queue consumers can be shown in Grafana.

Verify the endpoint after deployment:

curl http://127.0.0.1:15692/metrics

Port 15692 is published because the Prometheus and RabbitMQ stacks are separate Compose projects. Restrict inbound access to the Prometheus server IP in the cloud security group when RabbitMQ is deployed on another server. If both stacks run on the same server, the security group does not need to expose 15692 publicly.