Date: Wed, 21 Jan 2009 16:00:24 +0000 (UTC) From: Stef <stef-list@memberwebs.com> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: Shteryana Shopova <syrinx@freebsd.org>, freebsd-jail@freebsd.org Subject: Re: bsnmp module for monitoring jails: bsnmp-jails Message-ID: <20090121160023.960DC8C2862@mx.npubs.com> References: <20090120011951.D26228C282E@mx.npubs.com> <4975B8F3.7010008@quip.cz> <20090121032610.548568C2A3D@mx.npubs.com> <497719E9.1080107@quip.cz> <20090121131105.P45399@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Bjoern A. Zeeb wrote: > I see a few problems with the module (and I haven't investigated a lot > yet): Hi. BTW, thanks for the work you've put into jails on HEAD. Really looking forward to that. The bsnmp-jails module certainly could be improved a lot. As my clients migrate to newer versions of FreeBSD, that would happen naturally. Or if anyone interested wants to participate, please do. I'm open to better ideas, code and implementations. bsnmp-jails was born out of necessity. Some answers to your points below, but this doesn't mean that I don't think they're valid. > - the entire pcap stuff in there Yes, at first glance not the most efficient. It'd be awesome if there were kernel counters for this. But the big benefit to using pcap is that allows us to exclude certain traffic (see jailNetworkFilter config) such as local site traffic, from the counters. > This is all going to break on the assumption that jails do use things > exlusively. For example there can be 10 jails all sharing the same IP. > There can be jails all sharing the same fs, nullfs mounts, ... Certainly. Jails can be configured in a multitude of ways. Obviously, one can even use them as a chroot. I don't think bsnmp-jails makes sense for every possible use of jail(2). The module doesn't follow mounts when calculating disks and files. In the future I'm thinking of moving to ZFS for my jails, one fs per jail, and that'd make it far quicker and easier to calculate disks and file usage. That is, if the top level path of a jail is a mount point, then bsnmp-jail could just use info straight from that mount point instead of walking the tree inefficiently. > And to my understanding the cpu usage reported is at best a snapshot > guess but no clean statics value. I'm centainly no expert at this, however I've thought that the CPU usage is one of the more accurate parts of bsnmp-jail. It monitors ki_childtime + ki_runtime for all the processes. In addition when a process that has a parent outside the jail exits (ie: a daemon restarting), it keeps track of that process's ki_childtime + ki_runtime and keeps it in the counters. The above opens a small window of time when CPU usage may be missed. The time between the last monitoring cycle (3 seconds by default) and the when a daemon process exits, may be missed. In reality this happens very rarely and the CPU statistics have been usable. > I admit that those things (apart from traffic which really belongs > elsewhere) can become interesting with resource limit patches where we > get get proper values from elsewhere w/o having to do guess-math. Yes, it goes without saying, that kernel counters for CPU usage on the xprison structure then that'd make things far simpler and more accurate. > - no support for jails in HEAD (and soon in 7) So far only two versions of xprison structure are supported. The original single IP, and those patches that have been floating around. But it'd be easy to add support for the new jails. > - does the MIB list the IP address(es)? Nope, but it could be done easily, given the need. > - private copies of xprison structures Not sure I understand what you mean here. bsnmp-jail tracks jails by hostname, not by jid, since those are volatile. It also has to do strange gymnastics to get around the 'phantom jail' effect on FreeBSD 6.x (and other versions?) where a jail hangs around in the kernel due to TCP TIME_WAIT. > I have the feeling that this will need a bit of polishing and > separation of things... Yup certainly, and it's my hope that it will become more useful over time. Thanks for your advice. Cheers, Stef
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090121160023.960DC8C2862>