Nagios Support Forum

My concern is this open source product has been around for some time. This "forum" doesn't seem to care, or you don't know.

I already have another way to pull this off, I just thought that former open-source, now supported product, tons of books, yet one person answering the thread. The initial information given, removing the back slash from the end?

<Select Path="System">*[System[(EventID=4625)]]</Select>\

For example? Told to remove all the backslashes? I add them back it works?

Do I need to join the support team? Fine, $400.00 per 1/2 hour.

This is close to the last chance because I simply am running out of time.

It sounds great, on paper - no delivery. The documentation online, extremely simple. Nothing real-world.

The books I've found, no different.

With that said, I've seen this product work (Nagios Core) in a Top Secret Security (FIPS) environment.

I am, after all, Top Secret Classified Security Clearance. Someone out there, knows what they are doing.

Brian Murphy
Chief of Technology
https://www.linkedin.com/in/vitalservices (click the link....might just learn something)

Ask yourself, do you belong in this industry at all.

Someone out there must have an answer.

Yes or No.

This product either works or it doesn't. If it doesn't do the job, tell me.

Nothing beats honesty. Brutal honesty. Save us all some time.

Did you ever have any luck filtering out events on the Nagios Log Server end of things? Using this aforementioned filter rule: I've always found the fine-tuning of modules within nxlog to be finicky at best. I'm sure someone will be along shortly to address the rest of your concerns, I just wanted to offer that up once again as a potential solution that doesn't involve arguing with nxlog.

The nice thing about filtering out events in Nagios Log Server is that all you're really doing is writing Logstash rules. Elastic has been pretty good about documenting all the things you can do with Logstash modules and you can usually find a lot of pre-fabricated stuff out in the community for specific use-cases. That and Logstash supports Grok where a more elegant solution cannot be found.

A buddy of mine wrangles the Elastic stack for Target and has a general rule of not solving client-side that which can be solved server-side. I think keeping everything in Logstash configurations and leveraging Nagios Log Server's configuration management is a better solution overall than maintaining a bunch of client-side configurations via something like Chef or Puppet. Just one guy's opinion

Hm. I really appreciate the information. I wanted to come at this as only getting the data I needed from each server. Particularly, event logs. I suppose I could always adjust GPO to some degree to get rid of those.

I really appreciate the different perspective, gives me something to contemplate. Is this logstash, and Grok something that is relative to Linux and works with Logger. That is my impression but in all honesty, I've not had much time to spend on this POC.

I can look those items up, read more. I appreciate the information.

vcissgroup wrote:I wanted to come at this as only getting the data I needed from each server.

I definitely get that; Why shotgun all the things at Nagios Log Server? But if this eventually meant to be a large environment with multiple instances/nodes, you'll likely want to chuck a load balancer in front of it anyway which can let the "logging server" worry about making log decisions and free up some clock cycles on your infrastructure to do the things the server's were commissioned for. You may have a bit more network traffic as a result of this design choice though, which is definitely a consideration.

vcissgroup wrote:Is this logstash, and Grok something that is relative to Linux and works with Logger.

Logstash is part of the Nagios Log Server stack. Think of Logstash like the "transport layer" of Nagios Log Server. It's just a cog in the broader machine of Nagios Log Server responsible for receiving logs, processing/filtering them in some way, then shoving them into long-term storage. Logstash's pipeline works on an Input -> Filter -> Output basis. An Input would be something like nxlog configured to ship logs to a remote server. A Filter would be something like Grok (or my previous "drop these specific events" rule) where the log received is being manipulated in some way. An Output is where you are sending the data, could be a MySQL server, flat-file, RabbitMQ, or in the case of Nagios Log Server an Elasticsearch database.

Grok is a module/plugin that exists under Logstash. Grok is nice because you can do regular expression matches on specific parts of your log messages and store those specific parts as individual, searchable fields. So if I had some grotesque bit of Cisco log that looked like this:
I could pull out the gaddr, faddr, laddr, etc into individual fields. The main benefit of this would be situations where you might want to say "ok, show me all the traffic from the last 6 hours from machine 192.168.0.1". Doing that without first being able to isolate the gaddr (or laddr or whatever) field that is associated with the 192.168.0.1 address would be tricky. Grok is a tool that would allow you to do a regular expression match on something like this: And store that in it's own field called gaddr (or whatever you want to label it with).

Hope that all sort of makes sense, let me know if it's a bit rambly or needs clarification.

Geez. Where do you find this stuff. I've looked all over.

Very much appreciated, I will definitely check it out.

Exacty what I needed. Now I just need to read more "stuff"

So above, your referencing a router and a PIX Firewall? Which is not an issue. Just wondering. This customer has 1700 nodes (switches, routers). SNMP RO string set on ally. Netflow configured to hit Nagios Network Monitor.

I feel as if I'm missing something about this Logger product. I really just want to have these events from AD Controllers. I have four POCs. XI, Logger, Fusion, Network Monitor.

All in my new Data Center which is Cisco UCS/Nimble/VMWare/Veeam Back and Recovery/Veeam One.

Ultimately, I am looking for a way to map all processes to data source For now, I would settle for the logs.

vcissgroup wrote:Geez. Where do you find this stuff. I've looked all over.

Lots of Googling over lots of months and lots of unique use cases

vcissgroup wrote:I feel as if I'm missing something about this Logger product. I really just want to have these events from AD Controllers.

And you can either discard the unwanted events client-side (via nxlog, rsyslog, syslog-ng, whatever agent you prefer) or server-side. The specifics of any given client-side agent might be fuzzy and depend on the environment. In my experience (and i'm hardly an authority) nxlog has some consistency issues (backslash / no-backslash is just one example) due to their slightly unconventional configuration structures.

vcissgroup wrote:Ultimately, I am looking for a way to map all processes to data source For now, I would settle for the logs.

If you can expand on this a bit, I might be able to offer some suggestions. But for right now, is the nxlog backslash/no-backslash situation resolved?

@vcissgroup Any updates?

If you can expand on this a bit, I might be able to offer some suggestions. But for right now, is the nxlog backslash/no-backslash situation resolved?