Peter Tribble wrote: > On Tue, Jun 17, 2008 at 10:09 PM, Liane Praza <liane.praza at sun.com> wrote: >> Peter Tribble wrote: >>> As I was reading this, I started to wonder - why does SMF have to build >>> in snmp traps, or email. Doesn't the 'execution of a shell script' cover >>> those >>> (and any other sorts of actions that you may wish to trigger)? >> For SNMP trap, we'd want to use a standard MIB by default. Email, we'd want >> a standard template. Shell scripts would allow people to deviate from the >> standard form if they wanted, but that doesn't mean we shouldn't have a >> standard form. > > Sure, but I would have those as canned shell scripts that people could hook > up, rather than built in to SMF itself.
Canned scripts (or, more abstractly, actions) might well be a good part of the puzzle, but I would worry about embedding too much into procedural code. One of the great gains of SMF is moving a bunch of stuff *out* of procedural code and into declarative data, where you can do things like build general queries and reports. As an example, we might well have an "snmptrap" action for a transition (which might or might not be implemented as an snmptrap script), but the actual SNMP parameters (OID, don't know what else because I don't have a PhD in SNMP) should be in SMF properties. You should be able to ask "what SNMP traps might I get from this system" or "what service is associated with this SNMP trap" and get reasonable answers. If the SNMPisms are buried in user-provided shell scripts, those questions can't be answered. Similarly for e-mail notification: you should be able to get a list of all addresses that will get e-mail notifications.
