Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On 10/27/06, Mike Gerdts [EMAIL PROTECTED] wrote: What if zoneadm monitor -a (all zones) had the ability to spit syslog entries and/or SNMP traps? Perhaps if the SNMP route is taken, a subagent to snmpd(1M) would be the right approach. Speaking as an admin and customer and not a developer, if the SNMP route is taken, then a SunMC agent module should also be available for sites like ours that have adopted SunMC as our overall monitoring tool. Having a 'Zone Management' module that monitors non-global zones and allows you to initiate state changes via SunMC (similar to the SMF module) would be a very useful tool. Down zones could generate Critical Alarms, which would percolate (sp ?) up the chain of objects and have visibility. As a side not, I have often wondered why there is not better integration between the tools that Sun markets and the code Sun writes. Seeing this discussion gives me some insight into some of those decisions (or the lack thereof)... This is meant as an observation and _not_ a criticism. -- Paul Kraus ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
Mike, To get it to link, I needed to create a symbolic link at /usr/lib/libzonecfg.so - libzonecfg.so.1. Time to go searching for linker options that I haven't needed before... I haven't looked into it, but for some reason I seem to get some useless events. Consider the following reboot: # ./notify foo 6 shutting_down running foo 6 shutting_down shutting_down foo 6 shutting_down shutting_down foo 6 shutting_down shutting_down foo 6 uninitialized shutting_down foo 7 ready uninitialized foo 7 ready ready foo 7 running ready I'm not sure why the newstate and oldstate would be the same. This is a known problem. See bug 6377283. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6377283 Thanks, Nick In order for an approach using a program like the one above to be useful there would need to be some way to indicate what the desired state for the zone is in addition to the the state that it has just transitioned to. Mike ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On 10/27/06, Dan Price [EMAIL PROTECTED] wrote: A (large) customer recently asked me to implement a feature whereby they could monitor zone activity via syslog. The motivation is that for this customer, any zone state change not during maintenance windows is a cause for alarm. I've had a similar request in my organization as a means of helping to identify which physical machine a zone is on by viewing centralized syslog data. Arguably, my use case is of limited value unless zones are rebooting all the time (hence no RFE for my use case). So here are my questions: - Do you think this is useful? Yes. - Do you think the log level (Info) is right? daemon.info is *not* logged by default, whereas notice is. (So basically: do you want these messages in /var/adm/messages by default, or not?) Info is OK for normal state transitions. If a reboot fails and it ends up installed rather than running, I would expect that is an daemon.err (or is it daemon.error...) because something went wrong. - Do you think the facility of 'daemon' is OK? With Solaris syslog you can't AFAIK route messages based on the value of 'program' (which in this case is 'zoneadmd'). There's a good RFE! :) 'daemon' works for me. - Any comment about whether the info provided is sufficient? For example, when a zone reboots it goes through numerous state transitions, but I chose to express this as one big transition-- does that work for everyone? Perhaps if zoneadmd is running in a debug or verbose mode (selected by zonecfg(1M) property or /etc/default/zones?) then it could log detailed state transition info to daemon.debug. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On Fri 27 Oct 2006 at 09:11PM, Peter Memishian wrote: So here are my questions: - Do you think this is useful? - Do you think the log level (Info) is right? daemon.info is *not* logged by default, whereas notice is. (So basically: do you want these messages in /var/adm/messages by default, or not?) - Do you think the facility of 'daemon' is OK? With Solaris syslog you can't AFAIK route messages based on the value of 'program' (which in this case is 'zoneadmd'). - Any comment about whether the info provided is sufficient? For example, when a zone reboots it goes through numerous state transitions, but I chose to express this as one big transition-- does that work for everyone? Encouraging programmatic use of syslog seems a step in the wrong direction to me. Surely we can provide a better mechanism to notify them of state changes? Such as? We went down this road with Sun Cluster and arrived at a fairly complex C API which I was never very happy with; as a result we have thus far kept it private. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On Fri 27 Oct 2006 at 06:21PM, Dan Price wrote: Encouraging programmatic use of syslog seems a step in the wrong direction to me. Surely we can provide a better mechanism to notify them of state changes? Such as? I guess my larger point is that I haven't seen us take steps in the right direction. Maybe we have and I'm just not aware of them. To expand a little, the such as? could be SMF, which already has the ability to monitor property values. However, we're a ways off from having each zone appear as a service (and even then, you'd have to know that a particular zone exists in order to be monitoring some particular property in the repository which represents its state). I think that some minimal syslogging is warranted (I've tried to keep it simple here) because we do know that customers have a degree of comfort with syslog, and because it fits readily into various existing 3rd party monitoring packages. As for GPEC, that's what our existing C api is based upon. Take a look at zonecfg_notify_*() in libzonecfg. It's a real horror show but it does solve the get the state and then subscribe to future changes and don't miss anything in between problem. We could potentially build this up into some new command like 'zoneadm monitor' but I don't necessarily see that as being in conflict with doing something in the short term with syslog-- and 'zoneadm monitor' can't be consumed by upper level monitoring agents without a lot of work by lots of other vendors-- I don't see an unconsolidated but versioned and structured messaging strategy as gaining much traction. If we want to do versioning and structured messages *and* tackle the networking and security parts and make a consolidated stream of messages, then I think that could be interesting. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On 10/27/06, Dan Price [EMAIL PROTECTED] wrote: As for GPEC, that's what our existing C api is based upon. Take a look at zonecfg_notify_*() in libzonecfg. It's a real horror show but it does solve the get the state and then subscribe to future changes and don't miss anything in between problem. We could potentially build this up into some new command like 'zoneadm monitor' but I don't necessarily see that as being in conflict with doing something in the short term with syslog-- and 'zoneadm monitor' can't be consumed by upper level monitoring agents without a lot of work by lots of What if zoneadm monitor -a (all zones) had the ability to spit syslog entries and/or SNMP traps? Perhaps if the SNMP route is taken, a subagent to snmpd(1M) would be the right approach. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] feedback requested: syslogging zone state transitions...
On Fri, 27 Oct 2006, Mike Gerdts wrote: On 10/27/06, Dan Price [EMAIL PROTECTED] wrote: As for GPEC, that's what our existing C api is based upon. Take a look at zonecfg_notify_*() in libzonecfg. It's a real horror show but it does solve the get the state and then subscribe to future changes and don't miss anything in between problem. We could potentially build this up into some new command like 'zoneadm monitor' but I don't necessarily see that as being in conflict with doing something in the short term with syslog-- and 'zoneadm monitor' can't be consumed by upper level monitoring agents without a lot of work by lots of What if zoneadm monitor -a (all zones) had the ability to spit syslog entries and/or SNMP traps? Perhaps if the SNMP route is taken, a subagent to snmpd(1M) would be the right approach. This sounds extremely useful. If someone decided to persue this path, would it be possible to integrate the monitoring piece into zoneadmd? Since it's already started to manage the zone, I reckon it could send state changes and errors to the fault manager or an SNMP trap host. - Ryan -- UNIX Administrator http://prefetch.net ___ zones-discuss mailing list zones-discuss@opensolaris.org
