RE: Request for comments

Hi,

it was very interesting comment. As I can imagine it now:

1. Policy is a set of rules, where each rule is either a direct matching
rule (i.e. if message text matches to regexp, send event, as described
in first post), or a link to predefined set of rules (ruleset). This
will allow administartor to create some common sets of rules an reuse
them in different policies. Policy may have default file name set
(probably also allowing usage of environment variables), which can be
overrided when policy being applied to host. Import/export of rulesets
and policies should be easy, with one exception - if one uses custom
events in the ruleset, how they should be exported and imported? Should
event in the rule be replaced with standard event (not very good
solution) or exported with the ruleset?

2. Policy applies to host/file pair, so one policy can be applied to
more than one file on a target system. Probably it also will be good to
allow applying policies to host groups via container or subnet obects.

3. Policies and rulesets can be organized into hierarchical structure
with folders.

For the user this can be represented as a tree with three subtrees:

1. Policies - tree structure with optional folders and policies as
leafs.
2. Rulesets - same as policies (or policies and rulesets may be in one
tree?)
3. Current bindings - Nodes on first level and associated policies on
second.

Like this:

* Policies
        [Folder 1]
                policy 1
                policy 2
        [Folder 2]
                policy 3
* Rulesets
        [UNIX]
                bind logs
                squid logs
        [Windows]
                Exchange
                SQL Server
        some_common_rules
* Current bindings
        Node 1
                policy 1: /var/log/squid
                policy 1: /var/log/postfix
                policy 3: /var/log/messages
        Node 2
                policy 2: {EventLog:System}
                policy 3: C:\squid\squid.log

Policy may look like this:

Policy 1
Default file: /var/log/messages
Report unmatched records: no
Rules:
        1. if match "^sshd.*" send event 1
        2. call ruleset "/UNIX/bind logs"

What do you think?

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 - 17:26:35 EEST