[Xymon] Xymon PowerShell Windows client

[Brandon Dale]

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] On Behalf Of zak.beck at accenture.com
Sent: Friday, 13 February 2015 8:53 PM
To: xymon-developer at lists.sourceforge.net; 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/20150220/5cfb3a3a/attachment.html>