Details
-
New Feature
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
apollo-99-trunk-20120810.034513-80
Description
Apollo provides aggregated messages metrics via /broker/dest-metrics.
There are for instance enqueue_item_counter and dequeue_item_counter that look like the total number of messages received and sent by the broker. Unfortunately, they represent something else. For instance, using a single topic and two consumers, one message received by the broker (and therefore two messages sent by the broker to the two consumers) will, in our environment, result in enqueue_item_counter+=3 and dequeue_item+=4 instead of the expected +1 and +2.
This can be explained by looking at Apollo's internals. We use slow_consumer_policy=queue so Apollo will create two temporary queues attached to our two subscriptions. One message in (at topic level) will result into two messages out (topic -> queue) plus one message in and out of each queue. So the numbers seen are somehow consistent.
For monitoring purposes, it is much more useful to get the number of messages in and out of the broker, considered as a black box. We do have these numbers at connection level (messages_received and messages_sent) but we miss aggregation. Would it be possible to have these counters aggregated at connector level? Of course, this should represent the number of messages ever seen by a connector, not only the ones from the existing connections.
In addition, connections also have byte counters (read_counter and write_counter), it would be good to have these too aggregated at connector level.
Finally, just like connection_counter at connector level is aggregated at broker level (via /broker), it would be nice to have these connector counters also aggregated at broker level. This way, messages_received under /broker would really represent the number of messages received by the broker...
Attachments
Issue Links
- relates to
-
APLO-240 Aggregate destination metrics invalid when using topic slow_consumer_policy="queue"
-
- Resolved
-