<div>
<div><br><span><br></span>
<p style="color: #a0a0a0;">On Friday, June 3, 2011 at 6:02 AM, Simon MacMullen wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div>On 02/06/11 21:35, Brian K. Jones wrote:<br><blockquote type="cite"><div>I'm testing a Python module that provides an easy way to work with the<br>RabbitMQ Management HTTP API. I'm testing against various different<br>broker instances, and I'm finding that, although they're the same<br>version, there are apparently circumstances that exist which make the<br>same call return different collections of attributes across different<br>servers.<br></div></blockquote><br>Hi Brian. You're right, this isn't very well documented. I'll try to <br>give an overview here.<br></div></div></span></blockquote><div><br></div><div>This would likely be a lot to document, but perhaps a start would be to document just the base attributes that should be in every single request for a given resource, and then build the docs up from there. So, what should be in an /api/queues response if: </div><div><br></div><div>You're not an admin and:</div><div>a) there are no queues</div><div>b) there are queues, but no events</div><div>c) there are queues and events</div><div><br></div><div>You *are* an admin and:</div><div>a) there are no queues</div><div>b) there are queues, but no events</div><div>c) there are queues and events</div><div><br></div><div>That'd be a good start, and you can build from there to include attributes with object values that also differ and all the corner case-ish things. </div><div><br></div><div>If there were some kind of collaborative doc project with a moderator or a passthrough for commits, I'd love to know about that, btw.</div><div>Let me know!</div><div><br></div><div>brian</div><div><br></div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><br>There are two reasons why different attributes appear: relevance and <br>permissions.<br><br>The first derives from the fact that internally the mgmt plugin works by <br>receiving statistics events from the various entities (connections, <br>channels, queues) inside the broker. If a certain entity has never done <br>something it'll never emit an event related to that - for example if the <br>queue has only just been created and never received or delivered any <br>messages, it won't have a message_stats attribute. This could also <br>happen if fine-grained stats are disabled - the broker simply isn't <br>emitting the events in this case. Therefore for stats-related <br>attributes, you should always bear in mind that any given metric might <br>be unknown.<br><br>However, that's not what you are seeing. The presence or absence of <br>listeners / nodes etc comes down to the principle that non-administrator <br>users are not meant to be able to see any of the structure of the broker <br>- so they can't learn about which nodes exist other than the one they <br>connect to. They also don't see message rates for vhosts they can't <br>access, even when looking at "global" rates, while administrators do.<br><br>tl;dr: it depends whether you connect as an administrator or not.<br><br>Of course, for monitoring, lots of people want to be able to have a <br>monitoring user which does not have administrator rights but can still <br>see everything. This will hopefully bubble towards the top of the to-do <br>list soon.<br><br>Cheers, Simon<br><br>-- <br>Simon MacMullen<br>Staff Engineer, RabbitMQ<br>SpringSource, a division of VMware<br><br>_______________________________________________<br>rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br></div></div></span>
</blockquote>
<div>
<br>
</div>
</div>
</div>