[Xymon] Xymon PowerShell Windows client

Mon Feb 23 09:54:49 CET 2015

Hi

Q1

You're right, BBWin does not have an equivalent server sent config for what
event logs are wanted. It can be configured locally on the client in the
registry if I recall correctly. This is why we added eventlogswanted - I
wanted to be able to send that from the server.

I think your two methods look correct (either way). This is a problem we
have been thinking about for a while as we have no need to collect all logs
(hence eventlogswanted) but managing all the configs can become a problem.

Q2

Yes, they add to the raw data. They were in the original Powershell client,
I added the switches to turn them off and be off by default but left them in
as presumably someone does use them or did have a requirement for them.

I wouldn't recommend enabling Win32_Product on any current Windows server -
it has some nasty side effects (http://support.microsoft.com/kb/974524). 

Q3

You're right, the original Powershell client sent back Error and Warning
events only. Not sure how this compares to BBWin. I can put this on the todo
list - maybe as an additional option on eventlogswanted.

Thanks

Zak 

From: Brandon Dale [mailto:BDale at kitchengroup.com.au] 
Sent: 20 February 2015 02:55
To: Beck, Zak; xymon at xymon.com
Subject: RE: Xymon PowerShell Windows client

Hi Zak,

I have been testing this on a few machines and playing around with it.

I'm trying to work out how best to handle the rules for filtering and
alerting on event logs if there are both bbwin and PowerShell clients being
used as the PowerShell client is slightly different in the way it collects
the event logs.

Question 1:

In bbwin the raw data contains:

[collector:]

client testserver01.bbwin win32

In the updated PowerShell client it contains:

[collector:]

client testserver01.powershell PowerShell XymonPS

on the xymon server in client-local.cfg I have a setup like this.

[win32]

eventlog:security:10240

ignore blahblahblah

eventlog:system:10240

ignore blahblahblah

eventlog:application:10240

ignore blahblahblah

and then in analysis.cfg:

CLASS=win32

        LOG     %.*  %^critical.* COLOR=red

        LOG     %.*  %^error.* COLOR=red

        LOG     %.*  %^failure.* COLOR=yellow

        LOG     %.*  %^warning.* COLOR=yellow

I don't think Bbwin has an equivalent to the
eventlogswanted:event_log_name:max_size command it seems to just pull all
the event logs by default (all the logs listed in Get-EventLog -List | FT
log). 

Now because bbwin pulls all the logs by default, if I have a situation like
the example below I get all the event logs on both servers and filters
listed in client-local.cfg apply to the security,application,system logs
which are the ones that contain most of the noise.

Example two servers, event logs collected in bbwin by default:

Server 1 (generic member server, nothing special)

[msgs:eventlog_application]

[msgs:eventlog_hardwareevents]

[msgs:eventlog_internet explorer]

[msgs:eventlog_key management service]

[msgs:eventlog_security]

[msgs:eventlog_system]

[msgs:eventlog_windows PowerShell]

Server 2 (Domain Controller)

[msgs:eventlog_application]

[msgs:eventlog_dfs replication]

[msgs:eventlog_directory service]

[msgs:eventlog_dns server]

[msgs:eventlog_file replication service]

[msgs:eventlog_internet explorer]

[msgs:eventlog_security]

[msgs:eventlog_system]

You can see the extra event logs present on the domain controller.

In the PowerShell client I can't work out how I can replicate this behaviour
as by default it only collects Application,System,Security logs. I know I
can specify additional logs using wantedeventlogs but I can't see how I can
do that in a single general rule It seems like I would need to either

1.       Have an entry in client-local.cfg under [PowerShell] with
eventlogswanted and list every possible event log, this would mean on all
clients these would display under msgs even if the log doesn't exist on the
client

2.       Create a separate entry with the [hostname] in client-local.cfg for
each server where I want to collect anything outside of the three default
logs and then list the ignore filters each time.

Have I misunderstood how this works or is there an easy way to replicate the
same behaviour as bbwin? 

Question 2:

I read through the documentation but I can't work out what is the advantage
of setting any of these to 1: EnableWin32_Product,
EnableWin32_QuickFixEngineering, EnableWMISections ? I understand they are
disabled by default for performance but what do you actually gain if you
enable them? I can see you get more info in the raw data but how is this
used for the tests in xymon?

Question 3:

Would it be worth adding a filter to the client so get-winevents only
returns critical,error,failure,warning events rather than everything. That
would remove the need to have as many ignore rules in the client-local.cfg
and I am guessing most people don't alert on events that are
level=information. From memory I think that is how the original PowerShell
client worked. I think ideally you should be able to specify this in the
config xml or something similar.

Regards, 

Brandon 

From: Xymon [ <mailto:xymon-bounces at xymon.com>
mailto:xymon-bounces at xymon.com] On Behalf Of
<mailto:zak.beck at accenture.com> zak.beck at accenture.com
Sent: Friday, 13 February 2015 8:53 PM
To:  <mailto:xymon-developer at lists.sourceforge.net>
xymon-developer at lists.sourceforge.net;  <mailto:xymon at xymon.com>
xymon at xymon.com
Subject: [Xymon] Xymon Powershell Windows client

Hi all,

Today I have uploaded a new version of the Xymon Powershell client to SVN
(in sandbox/WinPSClient). We (Accenture) are very pleased to be contributing
these changes to the open source community. I've been working on this now
for around 8 months on and off and hopefully the changes made will be of
benefit to everyone!

Whilst making changes, we have focussed mainly on making it work, improving
reliability and most importantly improving performance.

In most cases, on our 64 bit OS virtual machines, a data collection now
takes around 5 seconds. On heavily loaded (CPU load or event log load)
servers, the script is now considerably faster than originally. Key to this
has been reducing the amount of WMI usage as this was a major culprit. 

We have also implemented some new features, largely based on our in-house
requirements but hopefully useful to others:

*         Showing the process owner and command line in [procs]. This has
been implemented using c# code, compiled at runtime.

*         Adding Active Directory replication test, Terminal Services
sessions test

*         Ability to restart any stopped Windows service

*         Client self-update

*         Dirsize and dirtime checks (which were originally external
scripts)

Some things have changed slightly; for example, the local configuration
which was registry-based is now XML-based (you can still use registry
settings if you prefer).  In the SVN repository I have also uploaded a Word
document which describes how to install and the configuration options.

I have uploaded all the revisions we have made to SVN so there is a history
of development. Whilst we will endeavour to continue contributing changes
and improvements in coming months, this is an open source project and as
such we are not offering any formal support. If anyone wishes to bugfix,
branch or whatever, please do so!

Zak Beck
Accenture

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20150223/13ea2351/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6831 bytes
Desc: not available
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20150223/13ea2351/attachment.bin>