Subject: Applmib logging capability revisited?

From: Randy Presuhn <[email-masked]>
Date: Wed, 3 Feb 1999 11:37:54 -0800 (PST)

Hi - 

I'm forwarding this to the application mib list, since this
was a past topic here.  Begging Bob Natale's, Jon Saperia's,
and Cheryl Krupczak's pardon, can we for the time being
limit the follow-ups to the <[email-masked]> list?  (See
http://www.ietf.org/html.charters/disman-charter.html for
subscription instructions.)

PLEASE note that we're on the verge of working group last call for
the disman log MIB work, and as WG chair I'm reluctant to entertain
proposals that would further delay its completion.  However, I think
the issue Lauren raises does merit prompt discussion and decision.

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------

> From [email-masked] Wed Feb  3 10:30:03 PST 1999
> From: "Heintz, Lauren" <[email-masked]>
> To: "[email-masked]'" <[email-masked]>,
>         "[email-masked]'"
> 	 <[email-masked]>
> Subject: AgentX Log Table
> Date: Wed, 3 Feb 1999 12:24:35 -0600 
> 
> I am x-posting this to disman and AgentX.
> 
> As co-editor of the AgentX MIB draft, one of the
> issues I am dealing with is to come up with a specific
> recommendation to instrument appropriate AgentX errors or
> events.
> 
> Ideally, I think a generic (non-AgentX) log mechanism
> would solve the problem, but I know of no such mechanisms
> except perhaps the disman LOG MIB.
> 
> The disman LOG MIB allows applications to define notifications
> that map to interesting events and which can then be logged once
> the notification is transmitted, but this seems too complex for
> the indended purpose (simple debugging of AgentX situations).
> 
> Instead, what I would like to propose is that in addition to
> the existing LOG MIB, the disman WG create a more simplified
> remote logging mechanism, implemented as a table and a single scalar
> variable, something like:
> 
> 	logSize - scalar could be set by a manager to control the
> 	maximum number of log entries.
> 
> 	logTable would have the following two columns:
> 
> 		logIndex (incrementing int type)
> 		logEntry (SnmpAdminString, application generated LOG entry)
> 
> logEntry would have max len of, say, 255.  Applications could then
> generate human-readable log entries for any event it chooses.  Richness
> of reporting could be implementation-specific or, in some cases, specified
> in RFCs.  The AgentX MIB RFC, for example, could specify which kinds of
> AgentX events SHOULD be reportable and could even recommend the format of
> the
> each logEntry so that it could be parsed by manager applications.  AgentX
> MIB
> could even provide one or two additional variables that enabel/disable
> AgentX log
> reporting or set a log severity level (kinds of AgentX events to be
> reported).
> 
> Manager-side parsing of logEntry is not necesarrily intended, although
> not precluded on a case-by-case basis.  Rather, the disman log MIB
> should instead be considered for most events that REQUIRE parsing.
> 
> Lastly, this simpler logging mechanism is intended for applications
> that require an easy-to-implement-and-use remote debug capability, and
> it would preclude the need for AgentX to define its own specialized
> table.
> 
> Thoughts?  Agreements?  Objections?  Suggestions?
> 
> Thanks,
> Lauren
> 
> -------------------------------------------------------------------------
> Lauren Heintz                 BMC Software, Inc. (Formerly PEER Networks) 
> Voice: +1 408 616-3169        Silicon Valley Division 
> Fax:   +1 408 616-3339        965 Stewart Drive 
> Email: [email-masked]  Sunnyvale, California 94086 USA 
> -------------------------------------------------------------------------
>

---

From: Jon Saperia <[email-masked]>
Date: Thu, 04 Feb 1999 07:31:45 -0500

Randy, Lauren

The idea of remote logging is attractive but if you want to use it for
debugging purposes I would have to ask if this is the right tool for the
job.  You should carefully look at the number of messages per second you
think the system might have to deal with.  If it is one that you think
could be dealt with then go for it, otherwise you may want a to use some
other mechanism for debugging.

I make a distinction between NOTIFICATIONS and logging information.  Log
information in my view is of a much finer level of granularity than
might be found in most NOTIFICATIONS.  I think of a log as a nearly,
sometimes high volume, continuous stream of data.  Examples that come to
mind are database transactions logs or the log date you might get from
gated in debug mode.

Bottom line, if you think it can do the job go for it, but not as a
generalized log facility.

/jon