On Tue, 22 Nov 2005 16:31:22 +0000 Dave wrote:
DS> On Mon, 2005-11-21 at 13:57 -0500, Robert Story wrote:
DS> > Currently snmptrapd will register a syslog handler OR a print handler
DS> > after processing arguments. Both handlers call snmp_log() to log the
DS> > final formatted result, so the if even if multiple logs and different
DS> > formats are configured, only one format will be used for all logs.
DS>
DS> I'm not sure that's true.
DS>
DS> But checking the code, both handler routines use the same basic
DS> code structure - essentially:
DS>
DS>
DS> syslog_handler( pdu, handler )
DS> {
DS> if (handler->format)
DS> buf = format_trap( handler->format, pdu );
DS> else
DS> buf = format_trap( syslog_format, pdu );
DS> snmp_log( buf );
DS> }
DS> [...]
DS> So although the same routine is used to log the formatted buffer,
DS> the *contents* of that buffer will depend on the format string
DS> defined for that particular handler.
But the point is that both end with snmp_log(), which will send the message,
whatever the format, to ALL logs. Thus if a filelog is registered but the
syslog_handler is running (possible if no command line options specified but
logOptions set a file to log to), then syslog and the file will get the same
formatted message, regardless of the the format was decided upon.
DS> And in principle, this could be different for each individual
DS> handler entry (though I don't think that's currently configurable).
Actually, I couldn't even find any code that assigned data to the handler
format. There is no way to configure it!
DS> I don't agree that the same log format would currently be used
DS> for both syslog and file-style handlers.
I'd check again before making any large bets. ;-)
DS> > I'd like to remove the distinction, and have 1 format for all log types.
DS>
DS> And I *definitely* don't agree with this suggestion.
DS> One of the aims of the handler-based mechanism was to introduce as much
DS> flexibility as possible - hence the per-handler format string. I would
DS> be *very* loth to see this disappear.
Ok, I won't push to hard on that, but I don't really see how it's supposed to
work. First off, as I said above, I don't see how a custom format can ever get
set. Second, the syslog or print handler is *always* registered, and it will
log the traps once (using print[12]/syslog[12] format). So, even if there were
a way to register a handler with a custom format, *that* format would be used
and sent to *all* logs.
Any way you slice it, all open logs will receive the same format from the
traps.
DS> Hmmm... how about the following strawman proposal:
DS>
DS> Have a single "format" directive (or "format1"/"format2" pair) to set
DS> the default format structure.
I don't think we want to remove the v1/v2 distinction, so definitely a pair.
DS> When a trap handler entry is read, the
DS> currently active format string is copied into the handler's format
DS> field (so will be used thereafter).
DS>
DS> That would allow something like:
DS>
DS> traphandle thistrap // using default format
DS> format "first format string"
DS> traphandle thattrap // using first format
DS> format "second format string"
DS> traphandler theothertrap // using second format
DS>
DS> How does that sounds as a basic model?
I like it.. but while looking at the code, I found another issue. (<shrek
voice>snmptrapd is like and onion</shrek voice>).
It turns out that there is yet another format string, EXECUTE_FORMAT, which is
used to run a command handler. This code will also use the handlers format, if
defined. With the above scheme, setting the format will change the log format
*and* the parameters passed to the trap handler. That will surely break
things. It seems that the custom format is overloaded, and we've painted
ourselves into a corner (or would have, if there was a way to set the custom
formats.)
So I like the idea of per-trap log formatting, but am not quite sure how to
reconcile that with the execute parameter format. The best idea I can come up
with is to change the trap handler structure to have a log_format and
execute_format. But, as with the log file append/truncate options, it feels a
bit late in the game for such a change.
--
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
