The Plugin Management Module provides unified viewing and management of plugins supported by the TDMQ RabbitMQ Edition cluster.
This article introduces how to view supported plugins on the TDMQ RabbitMQ Console.
Viewing extension
1. Log in to RabbitMQ Console.
2. In the left navigation bar, select Cluster Management, choose the region, click the "ID" of the cluster you want to view, and enter the cluster details page.
3. At the top of the Cluster Detail Page, select the Plugin Management tab to access the plugin management list.
After creating the TDMQ RabbitMQ Edition cluster, the following plugins are enabled by default:
Plugin Name | Plugin Descriptions |
rabbitmq_event_exchange | The rabbitmq_event_exchange plugin can publish various events about the RabbitMQ server, such as connection creation and closure, channel creation and closure, queue creation and deletion, etc. These events are sent as messages to a special exchange named amq.rabbitmq.event. |
rabbitmq_management | The rabbitmq_management plugin provides a web-based user interface and a set of HTTP APIs for managing and monitoring the RabbitMQ server. |
rabbitmq_peer_discovery_k8s | The rabbitmq_peer_discovery_k8s plugin allows RabbitMQ nodes to auto-discover and connect to other RabbitMQ nodes in a Kubernetes environment, forming a cluster. |
rabbitmq_prometheus | The rabbitmq_prometheus plugin is a monitoring plugin provided by RabbitMQ. It can export RabbitMQ metrics in a format understandable by Prometheus, allowing you to use tools like Prometheus and Grafana to monitor and visualize RabbitMQ’s performance and health status. |
rabbitmq_tracing | The rabbitmq_tracing plugin can trace messages passing through RabbitMQ and persist them to disk, logging them to files, thereby saving time in problem localization and debugging. |
Note:
TDMQ RabbitMQ has defaulted off the "rabbitmq_delayed_message_exchange" delayed message plugin because of the following risks and restrictions:
1. The current plugin design is not suitable for scenarios with a large volume of delayed messages (hundreds of thousands or even millions of un-scheduled messages). In a production environment, please carefully assess the message volume to avoid unexpected long delays and message loss.
2. Delayed messages have only one persistent replica on each node. If the node cannot run properly (e.g., due to continuous OOM caused by message accumulation, leading to a restart and failure to recover), the delayed messages on that node cannot be consumed by the consumer.
3. The delayed exchange does not support setting mandatory, and the producer cannot sense unroutable messages through the basic.return event. Therefore, please ensure the corresponding exchange, queue, and routing relationships exist before sending delayed messages.
The risks and restrictions can be found in the official usage limitations of the RabbitMQ delayed message plugin.
Additionally, refer to the Tencent Cloud Documentation TDMQ for RabbitMQ > Development Guide > Delayed Messages for descriptions of the two implementation methods for delayed messages.