NSClient++ Help (#1) - CheckEventLog syntax=%message% is returning bad chars thusly fails (#852) - Message List
Hello,
I am in the middle of implementing event log monitor on some Windows server and would like to further understand why syntax='%message%' returns special chars that have special meaning in the shell?
For instance, if I use %message%, I get an error:
"We cant handle 13 arguments so you wont get argList her" in place how what I can only image is what something is considering the be additional arguments. It's quite obtuse.
How can I avoid this and have the message contents rendered and returned?
Thanks,
Matt
[edit]: Solution is to upgrade to 0.3.9+ see: http://www.nsclient.org/nscp/discussion/topic/801
-
Message #2296
Another "solution" is to use strings as it is the "same" but much much faster...
Michael Medin
mickem08/30/11 09:28:18 (21 months ago)-
Message #2298
Thanks for the response, Michael.
Does %strings% simply not contain the "volatile" strings used in the Event Log Message?
For example in the following event:
Event Type: Failure Audit Event Source: Security Event Category: Logon/Logoff Event ID: 534 Date: 8/29/2011 Time: 12:44:30 PM User: NT AUTHORITY\SYSTEM Computer: SERVER Description: Logon Failure: Reason: The user has not been granted the requested logon type at this machine User Name: theuser Domain: LOCAL.CORP Logon Type: 10 Logon Process: User32 Authentication Package: Negotiate Workstation Name: SERVER Caller User Name: SERVER$ Caller Domain: LOCAL.CORP Caller Logon ID: (0x0,0x3E7) Caller Process ID: 5036 Transited Services: - Source Network Address: 192.168.100.20 Source Port: 6650
%strings% include literals: theuser, LOCAL.CORP, 10, User32, Negotiate, SERVER, SERVER$, LOCAL.CORP, (0x0,0x3E7), 5036, -, 192.168.100.20, and 6650
%strings% does NOT include any of the built-in strings, like "Reason:" (or it's reason :D ), "User Name:", etc.
Can you confirm this is the case?
I assume the increased latency is because CheckEventLog.dll is referring to the Event Log definition DLL, and "resolving" some things? %strings% is simply made up of some strings that are present in the Event Log file itself? Is this correct?
Therefore, saying that %strings% contains the same thing that %message% contains is wrong. I'm looking to literally obtain the message, since I'm not qualifying per Event ID, but by all of severity Warning, Error, auditFailure, etc.
Thanks for your work Michael!
Matt
mbrownnyc08/30/11 14:59:55 (21 months ago)-
Message #2299
It depends, the "uniqueness" of the message is contained in the strings. So any filtering can (and should) be used against the strings as that is faster. Using message is slower and yields no added benefit (apart from a pretty syntax) or am I missing something.
ie.:
message: "Hello: world" would come from:
- format specifier: "Hello %string1%"
- data: world
message: "Hello: foobar" would also come from:
- format specifier: "Hello %string1%"
- data: foobar
So the format specifier is the same for both messages, the only difference is the strings which is the unique part of the message.
The overhead message incur comes from:
- Read which DLLs are used from the registry
- loading the list of DLLs
- In each DLL looking up the format specifier
- If the format specifier is found render the message
- compare the message against the filter
Where as using strings is only:
- compare the message against the strings
Michael Medin
mickem08/30/11 16:42:23 (21 months ago)-
Message #2301
I see, so internally you have CheckEventLog process using either %strings% or %message%?
I simply want to include the %message% in the syntax that is returned to nagios.
I could be wrong, but it seems that you forget that some people would want the %message% returned, and that they will make a decision to deal with overhead that using %message% incurs.
For instance, I'll likely be polling once every five minutes for errors in something that when errors are logged, it is seriously broken (DFS-R). Since there are many different error events, with different %arguments%**, returning the entire contents of %message% in the human readable format would be quite useful.
(**maybe make a cache list of %arguments% per "file," and instead of searching through the definition DLL, you can just check the definition DLL file version... if the same as in the cache, okay, if not or if that file property doesn't exist, regenerate %arguments% cache)
Regardless, it seems that in 0.3.9 you've raised the amount of Event Log Message arguments that CheckEventLog can handle. This is great news, as it lets users make a decision as to how they want to utilize the software.
How many arguments does CheckEventLog handle now?
Again, thanks for your work! It is greatly appreciated!
Thanks,
Matt
mbrownnyc08/31/11 16:12:52 (21 months ago)-
Message #2302
Absolutely that's why it is there... And the impact on rendering is most likely order of magnitudes less then filtering. As filtering is matching every single entry in the record where as rendering is only on the selected items. Hence my saying filtering using messages is mainly for "lazyness" as you can do the same filtering using strings.
If you have 100.000 entries in your log (not uncommon) and you filter out 5 specific errors the difference between opening 100.000*n (n being the average number of dlls:s a provider has registered) dll:s and rendering 100.000 messages and then comparing them versus opening 5*n dlls:s and render 5 messages for the 5 you want is massive.
And I think it is 15 or something like that, but if you have a scenario where you need more let me know and I will extend it...
Michael Medin
mickem08/31/11 18:59:57 (21 months ago)
-
-
-
