Add more useful data into rabbitmq_cluster_vhost_status metric

[jonsbun]

Is your feature request related to a problem? Please describe.

When a new virtual host is being created, a user can provide not only name, but also description and tags. Description and tags later are not visible in the GUI, but can be retrieved via /api/definitions/{vhost} API endpoint:

    "name": "test",
    "description": "testDescription",
    "tags": [
        "testTags"
    ],
    "default_queue_type": "quorum",
    "metadata": {
        "description": "testDescription",
        "tags": [
            "testTags"
        ],
        "default_queue_type": "quorum"
    },
    "tracing": false,
    "cluster_state": {
        "rabbit@server.local": "running"
    }
}

However, the same data is not available using RabbitMQ monitoring tools like Prometheus. This limitation allows filtering only by vhost name. Sometimes that is a big disadvantageous when creating Prometheus alerting rules because filtering is only available by vhost name and can't be achieved by vhost tags or description.

Describe the solution you'd like

Get RabbitMQ virtual host tags and description data when querying rabbitmq_cluster_vhost_status metric via Prometheus.

Describe alternatives you've considered

No response

Additional context

No response

[michaelklishin]

I don't know how collections are usually exposed as labels in Prometheus, #10670 uses a comma-separated list of tags.

[jonsbun]

@michaelklishin good point. Prometheus allows only string type labels. So exposing them as a comma-separated list of tags probably is the only option. Furthermore, RabbitMQ virtual host tags field doesn't have any strict rules. The same is for the description field, so these both fields are nothing more than string.

Also would be nice to expose another metric (e.g. rabbitmq_cluster_vhost_tag_status) which would allow to get vhosts by parsed tag from the list.

rabbitmq_cluster_vhost_status{vhost="test", description="testDescription", tags="dev=true,team/name,domain.local"} 1
rabbitmq_cluster_vhost_tag_status{vhost="test", tag="dev=true"} 0
rabbitmq_cluster_vhost_tag_status{vhost="test", tag="team/name"} 0
rabbitmq_cluster_vhost_tag_status{vhost="test", tag="domain.local"} 0

Then users are able to append only the required tag or a comma-separated list of tags into metrics:

rabbitmq_detailed_queue_consumers + on(vhost) group_left(tag) rabbitmq_cluster_vhost_tag_status{tag="team/name"}
---
{instance="node-exporter:9100", job="node-exporter", queue="queue.name", tag="team/name", vhost="test"} 4
{instance="node-exporter:9100", job="node-exporter", queue="one-more-queue", tag="team/name", vhost="test"} 0


rabbitmq_detailed_queue_consumers * on(vhost) group_left(tags) rabbitmq_cluster_vhost_status{tags=~".*team.*"}
---
{instance="node-exporter:9100", job="node-exporter", queue="queue.name", tags="dev=true,team/name,domain.local", vhost="test"} 4
{instance="node-exporter:9100", job="node-exporter", queue="one-more-queue", tags="dev=true,team/name,domain.local", vhost="test"} 0

[michaelklishin]

RabbitMQ virtual host tags do have rules: the provided value can either be a list (when created programmatically) or a comma-separated list of values (on the CLI).

[michaelklishin]

There is no such thing as a "virtual host tag status" in RabbitMQ. Virtual host status, sure. Virtual host metadata? OK. But tags do not have any status, they are either present or not.

Honestly, I haven't signed up for reworking our metrics around virtual hosts. If tags as a collection are not practically useful then the issue should be rewritten to explain what format would be.

The more different it is from what we currently have, the higher are the changes that it will have to wait for 4.0 or won't be addressed at all.

[jonsbun]

Add "tags" as a collection and "description" is practical. It would allow identify virtual host by more parameters. What is very useful when creating alerting rules in Prometheus.

[michaelklishin]

Moved to a discussion because this is not an actionable issue as it is.

rabbitmq_cluster_vhost_status{tags=~".team."

suggests that if the list of tags were a single string, this would still be practical for the sake of filtering/alerting. Am I correct about this? if so, a command-separated list for label value would do, and #10670 can be finished largely as it is.

[jonsbun]

Yes, you are correct. Then user able to use regular expressions and match required virtual host not only by name but also by tag value in Prometheus.

[mkuratczyk]

I'd vote for solving this externally. If there's no natural way of mapping this info, there's always an option to build a separate source of data/metrics that provide vhost-owner mapping and then "merge" (multiply/rewrite) the data to enrich the metrics exposed by RabbitMQ with additional labels, similar to how rabbitmq_build_info is used to enrich other metrics in the dashboards (but this can be done in the rewriting rules, to avoid doing this on every PromQL query).

[michaelklishin]

I think that adding a description label is a no-brainer. Tags are trickier but in some cases, just filtering on the description string might be enough.