Event log data notification

Jun 29, 2012 at 12:28 AM
Edited Jun 29, 2012 at 12:30 AM

AS discussed have log parser data for a specific even log health check be sent to growl or as email notification.

Example: have a log parser health check use this command

logparser "SELECT EventID,Sourcename,Computername,TimeGenerated,Message FROM System WHERE EventTypeName='Error event'" -i:EVT

Lets say run every hour and send any errors either to growl or as email.I found this http://www.blat.net/ seems to be open source not sure how easy it would be to implement on the agent side.
I also found this http://mlichtenberg.wordpress.com/2011/02/03/log-parser-rocks-more-than-50-examples/on example 21 it creates a html file with the report, i think that could be adaptedand somehow be sent out using blat.
Im not a coder so just bouncing some ideas.

Jun 29, 2012 at 6:14 PM

I think i found the email solution http://gluegood.blogspot.ca/2009/05/freeware-logparseremail.html :D Maybe that would make it easier for you jimbobdog

Jul 4, 2012 at 8:13 PM

I have been doing some research on how to implement this in a easier way and it looks like powershell is the way, it even has its own built in send information through smtp, as well as the option to output data as a html template and so on, you can also do monitoring of azure, vm, servers and so on in a much easier way,

so ill think ill wait to see how your going to integrate the powershell module plugin for wolfpack, as long as i can tie the scripts into the scheduler in wolfpack and use sidewinder to push updates to them will make things incredibly easy to develop for.

Jul 9, 2012 at 2:41 PM

I was also about to make a change on the email publisher by creating an "attachments" feature. Any HealthCheck can drop additional files relating to a HealthCheck alert into a special folder and the email publisher would scan for these and if any existed add them as attachments to the email. I will put this on feature on hold and dust off the PowerShell plugin - been meaning to do this for ages now.

With respect to updates, I think you are on the right track - if you have multiple sites you want to update at once with the same script then Wolfpack can also act as an automated deployment agent too....you just need to bundle your scripts as a NuGet package and publish the package - Wolfpack will take care of detecting the update, downloading and unpacking it for you - this approach would save you a lot of time as all installations would effectively be pushed the update.

More info here: http://wolfpackcontrib.codeplex.com/wikipage?title=Wolfpack.Contrib.Deployment

I'll update with the status of the PowerShell plugin soon.

Jul 9, 2012 at 9:06 PM

That sounds great, ya i think a powershell plugin is the best way to go, pretty much everything thats coming out of microsoft can be manipulated with powershell so it would expand wolfpacks toolbox in a huge way, thanks for the status update.

Jul 11, 2012 at 9:51 PM

Ok, I have a working Powershell plugin - it will execute a PS1 script and also provides some objects to generate an alert back in Wolfpack.

Now, it all "works on my machine" (I'm a local admin) but I might need some help fine tuning it to work on a typical setup (security-wise) server - I can make a beta release available if anyone wants to try this out? Alternatively grab the latest Wolfpack and Wolfpack Contrib source code from the codeplex repos

Jul 12, 2012 at 2:09 AM

Ya drop the beta files somewhere and ill help you out, i can drop into a couple vms to see how it behaves, if you want to pass some general info on how the plugin interacts with wolfpack that would be nice as well.

Jul 12, 2012 at 10:59 AM
Edited Jul 12, 2012 at 2:10 PM

The beta zip is here...You might need to "Unblock" the zip once you get it (or the content once unzipped).

https://dl.dropbox.com/u/31496111/wolfpack-powershell-beta-20120712.zip

Just unzip it and run wolfpack.agent.exe - it already has the powershell plugin installed and the check enabled. 

It runs a script in the \powershell folder - it's a simple script to return an alert to Wolfpack. If you have Growl installed you should see an alert popup from "MyFirstPowershellAlert".

The beta docs for the plugin are here...

http://wolfpackcontrib.codeplex.com/wikipage?title=Wolfpack.Contrib.Checks.Powershell

Let me know if there are any suggestions/feedback on the docs etc - any holes in it, missing or confusing stuff. I am keen for this to be tested in a "real" scenario with credible/typical security/permissions in operation - as I say its works fine on my machine but that is admin and unrestricted scripts etc.

Jul 18, 2012 at 11:24 PM
Edited Jul 18, 2012 at 11:25 PM

So far its working good, im still playing around with it and wrapping my head around it lol, you do seem to have to set this in powershell or else it wont run unless your admin, I will post some more feedback once im done playing with it but great job so far, thanks for the hard work.

Enable running unsigned scripts by entering:

set-executionpolicy remotesigned
Jul 19, 2012 at 11:24 AM

Excellent - I have also added a note to the docs to remind people about the set-executionpolicy command.

Thanks for helping out with this, next release v2.5 (codename "PowerTrip") will land soon! 

Oct 3, 2012 at 4:02 PM

Is there anything I can do to help this feature to release? I was about to start writing a Powershell scheduler when I found Wolfpack.

I've read through the docs and looked at the example. I have a couple comments on what exists so far.

First, since you released the Beta, PowerShell 3 has been officially released which has a couple key differences: native .Net 4 support; Snap-Ins have fallen out of favor and Import-Module is the new standard.

From the MS docs: "Beginning in Windows PowerShell 3.0, modules are imported into the session automatically the first time you use a cmdlet in the module. As a result, you just find the command you need and use it. Windows PowerShell takes care of the importing. However, if you prefer, you can use the Import-Module cmdlet to import a module at any time."

I'm getting an exception trying to use use this with the Execution Policy error even through I have it set to RemoteSigned.

PS C:\temp> Get-ExecutionPolicy
RemoteSigned
Does TopShelf run outside of the current user context when in Console mode? Not sure why else I would be getting a System.Management.Automation.PSSecurityException. The WolfpackDemo1.ps1 script executes fine from the PowerShell console.

Oct 3, 2012 at 4:18 PM

Topshelf should run in the same context.

Did you grab the beta zip from dropbox? You might need to unblock it before you unzip it - this causes all sorts of odd errors. I will try to replicate this here.

As for releasing it - just need to put some effort in and get v2.5 out the door! It's largely done and I've just got some housekeeping/docs to do on it (plus those tweaks to the healthchecks). I'm not a powershell expert so I might need some help fixing this - I'll update here later today once I've had a chance to replicate the issue. 

Oct 3, 2012 at 4:58 PM

I grabbed wolfpack-powershell-beta-20120712.

The Zip was Blocked so I unblocked it and extracted the files again, but no change. The script doesn't show an option to Unblock.

I have PowerShell 3 installed.

How are you referencing System.Management.Automation? I've never executed a script from C# but I've written a Posh cmdlet. Originally I referenced the System.Management.Automation.dll in the \ReferenceAssemblies folder, but that seems to be an old version that shipped with the PowerShell 1 SDK.

According to Doug Finke in Windows PowerShell for Developers,

 You’ll need to add a reference to PowerShell to follow along with these examples. To do so, open the project file as a text file and add the following line into the <ItemGroup> section:

<Reference Include="System.Management.Automation" />

In my project, that changed the Runtime Version and Version parameters to match PowerShell 3.

Oct 3, 2012 at 5:12 PM

Same results on a machine with v2 installed.

Oct 3, 2012 at 10:26 PM

Ok, so my dev machine has v2 installed and the only System.Management.Automation assembly I could find was in the \ReferenceAssemblies folder - so I copied this to the References\Binary local solution folder - I guess it is the same one for PS v1 & v2? I'll see what happens with v3 installed.