This seems to be a good topic to share some work we have been doing

here at LANL.  ibmon is an app that I developed that is currently

monitoring our IB production systems.  It's small, written in c and

perl  and follows the standalone model and is SM independent.  It can

be found at <a href="http://sourceforge.net/projects/ibmon" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://sourceforge.net/projects/ibmon</a>.<br><br>Key features:<br>- SM independent<br>- Reports "interesting" events via syslog, email or console

<br>- Events can be reported in detailed and/or "high-level" form

- Detailed events are reported as a "point-to-point" link.         - Makes for easier transformation to "high-level" form - Fast, query on a ~4000 node network is < 5s. - Uses sqlite for internal temp storage and archival storage.

<br>- Modular design: discover, query and reporting are separated.  Can move towards distributed model.<br>- Built for crontab.<br>- Can clear counters on query or when pegged.<br>- Keeps historical performance and topoloy data

- Gathers and stores most of the IB tables:         nodeinfo, switchinfo, sminfo, portinfo, perfcounters, lfdb (optional) - Reports changes in SMs Known issues: - Does not receive SM traps, needs to rediscover every so often.

<br>- Threshold values for errors need to be moved to a config file, currently in a db.<br>- Does not clear counters when "nearly" pegged.<br><br>Todd<br><div><span class="gmail_quote">On 11 Jul 2007 12:21:51 -0400, 

<b class="gmail_sendername">Hal Rosenstock</b> <<a href="mailto:halr@voltaire.com">halr@voltaire.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Wed, 2007-07-11 at 11:00, Mark Seger wrote: > Hal Rosenstock wrote: > > >On Wed, 2007-07-11 at 10:15, Mark Seger wrote: > > > > > >>My basic philosophy, and I suspect there are those who might disagree,

> >>is that you can't use the network to monitor the network, at least not > >>in times of trouble. > >> > >> > > > >Right, in times of certain troubles.

<br>> ><br>> ><br>> and that is the key.  since you can't know apriori when you're about to<br>> have troubles, you need to be collecting the data locally before they occur.<br>><br>> >>That's why I insist on having to query the HCAs

<br>> >>directly since I can't always be sure the network is there and/or<br>> >>reliable.  If you are willing to concede that this can indeed happen<br>> >>than the question becomes one of how do you reliably get data from an

<br>> >>HCA and that's the basis for my (re)starting this discussion.<br>> >><br>> >><br>> ><br>> >The reliability comes from timeout/retry mechanisms. If performance data<br>> >cannot be obtained on an IB network, it needs to be trouble shooted at a

<br>> >lower level (by SMPs).<br>> ><br>> >In any case, a rearchitecture of the PMA was proposed and seems<br>> >reasonable to me in that it can accomodate either approach. All that is<br>> >needed now is for someone to step up and champion an implementation of

<br>> >this. Unfortunately, I do not have time to do so.<br>> ><br>> ><br>> I don't know if what I've been proposing requires any rearchitecting as<br>> I see is as something local to each node.  Specificially, and there is

<br>> already an implementation of this in an earlier voltaire stack, is to<br>> export wrapping HCA counters to /proc.  The module that does this<br>> read/clears the counters on every access but since no local applications

<br>> are accessing the counters directly, clearing them doesn't hurt anyone.<br>> Alas, anyone else who wants to query the counters will find them reset.<br><br>No local application but perhaps a remote one. This is the reason for

<br>the proposed rearchitecture (along with synthesizing the wider<br>counters).<br><br>-- Hal<br><br>> The other side benefit of exporting these counters is such a way is now<br>> lots of others can collect/report this info.  In other words is someone

<br>> chose to add IB stats to sar, it would become very easy to do!<br>><br>> If this is the type of thing people are interested in, I might be able<br>> to supply some code to do it.<br>><br>> >>As for querying the switch for counters, what do you do on a very large

<br>> >>network, say 10s of thousands of nodes if you want to get performance<br>> >>data every second?  I also realize this is an extreme situation today<br>> >>(the node count not the frequency of monitoring) but I'm sure everyone

> >>would agree systems of these sizes are not that far off. > >> > >> > > > >You have a distributed performance manager to handle this. A hierarchy > >of performance managers has been discussed on the list before.

<br>> ><br>> ><br>> ahh, I see.<br>> -mark<br>><br>><br><br>_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openfabrics.org">general@lists.openfabrics.org

</a><br><a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br><br>To unsubscribe, please visit <a href="http://openib.org/mailman/listinfo/openib-general">

http://openib.org/mailman/listinfo/openib-general</a><br></blockquote></div><br>