RE: Request for comments

Hello,

syslog data stored into database in a separate table with the following
structure:

CREATE TABLE syslog
(
        msg_id SQL_INT64 not null,
        msg_timestamp integer not null,
        facility integer not null,
        severity integer not null,
        source_object_id integer not null,
        hostname varchar(127) not null,
        msg_tag varchar(32) not null,
        msg_text SQL_TEXT not null,
        PRIMARY KEY(msg_id)
) TABLE_TYPE;

where msg_id is an internal unique message identifier, timestamp is a
message timestamp (either specified in the message or generated at
message arrival), facility and severity are values extracted from syslog
message PRI part, source_object_id is a NetXMS object ID if message
comes from host which is added to NetXMS, hostname is a hostname field
from message (can be empty), msg_tag is a tag extracted from message
(according to syslog RFC), and msg_text is a message text (with tag
included, if any).

You can access this data via ODBC, for example. It is also possible to
access collected syslog data programmatically via NetXMS client library.

Best regards,
Victor

-----Original Message-----
From: Rune Nilssen [mailto:rune_at_directconnect.no]
Sent: Friday, October 21, 2005 6:41 PM
To: NetXMS Users
Subject: Re: [netxms-users] Request for comments

Hello again,

Is the syslog data available through a different interface than the
client? I was thinking, if I were to forward syslog data to the CVS
version, will this data still be available outside of netxms?

Best regards,
Rune Nilssen
rune_at_directconnect.no

-----Opprinnelig melding-----
Fra: Victor Kirhenshtein [mailto:victor_at_opticom.lv]
Sendt: 20. oktober 2005 21:56
Til: NetXMS Users
Emne: Re: [netxms-users] Request for comments

Hi,

1. CVS version already has built-in syslog server, so you will be able
forward your syslogs directly to NetXMS server. It can be an option to
apply policy not to specific node/file, but to syslog messages from
specific node collected by NetXMS server.

I will think about other points and reply a bit later.

Best regards,
Victor

-----Original Message-----
From: Rune Nilssen [mailto:rune_at_directconnect.no]
Sent: Thursday, October 20, 2005 8:11 PM
To: NetXMS Users
Subject: Re: [netxms-users] Request for comments

Hi,

1. Today I gather my logs on a common log server for all syslog enabled
units. Have you considered how agents would deal with such enviroments?
I guess theres several approaches that could be done by the user in such
a situation. The advantage however is that I would be able to parse
syslogs from Cisco routers etc.

2. Sounds resonable enough, I would suggest however that one is able to
group rules/policies togeather.. It would make it easier to apply
certain sets of predefined rules, say one special set for handling
kernel messages, one set of rules for handling bind log entries etc. It
would sure be handy not having to set up everything from scratch each
time, also if one takes importing/exporting into account it would help
people get up and running faster if say, someone made a few default
rulesets or similar. This might be what you had in mind in the first
place considering your opening line. :)

3 & 4. I would suggest a multi-multi approach. Meaning that one ruleset
can apply to anything from one to several or all logfiles a client
monitors aswell as across clients. Also it would make sense if a ruleset
has default files it applies to, and this beeing a default value that
can be overridden on a host or host-group basis.

As far as the interface goes, I can only imagine some sort of
tree-structure. Maybe one could have a set of default rules in a
"rulebook" that's set up as a tree with rulesets as folders. One would
doubleclick any rule to edit its default values and restrictions about
what kind of units it can be applied to(?). Further one would have a
different tree for applied rules/rulesets or maybe this belong in the
nodetree? Anyway, one could apply a rule/ruleset to a folder in the tree
and all units this is applicable for would automagically adapt these
rules, and if needed tweak this on a folder or unit level. Im not sure,
this is really just loose thoughts.

What do you think?

Sorry about the delayed response, work is taxing, as it should. :)

Best regards,
Rune Nilssen
rune_at_directconnect.no

-----Opprinnelig melding-----
Fra: Victor Kirhenshtein [mailto:victor_at_opticom.lv]
Sendt: 8. oktober 2005 22:35
Til: NetXMS Users
Emne: [netxms-users] Request for comments

Hi all!

Currently we are working on a log processing functionality. It's based
on the following key concepts:

1. All log processing should be done by agents.
2. Agent processes log files according to "log processing policy", which
is a set of matching rules for log records. If log record match to the
rule, agent either generate an event specified in the rule, or ignores
the record. It is also possible to generate special event for unmatched
records. 3. Agent can have multiple log processing policies installed,
usually one per file. 4. One log processing policy can be installed on
multiple agents, allowing to configure monitoring of similar files on
different hosts only once. 5. All log processing configuration should be
done from the management console in centralized way.

Does anybody have any comments on that scheme? Also, I'll be very happy
to see suggestions, how user interface for log processing configuration
can looks like.

Best regards,
Victor
Received on Fri Oct 21 2005 - 19:18:25 EEST