Context Navigation

NSClient++ Help (#1) - service name for real-time event log filter? (#928) - Message List

service name for real-time event log filter?

Hello. I am trying to use the real-time event log monitoring, but I'm having trouble figuring out how to associate a filter with a service name to return to Nagios. For example, the scheduled checks allow you to specify alias = ServiceX. This will insert ServiceX as the service name in the NSCA message. I can't seem to find an equivilant setting for the real-time filters.

I have tried the following.

[/settings/eventlog/real-time/filters/ServiceX]
alias = ServiceX
filter = id = 1000 AND source = 'ServiceX'

The event is getting picked up by the filter and the NSCA message is sent. But the service is set to blank in the NSCA message.

Can you explain what I'm doing wrong?

Thanks.

mikep

Tree View Flat View (newer first) Flat View (older first)

Message #2440
Wow, someone actually using this :) I was planing to go through it this weekend actually and create a few samples and documentation and such :)

But whats sent should be whats in the "message" so checking the syntax parameter is a good place to start...

And as always:
```
nscp test
```
Is also a good place to start :)

I would probably wait till Monday though and let me validate that everything works as expected :)

But please do give me some insight into what you are planing and I will make sure I get that in as an example...

Michael Medin
mickem

03/15/12 15:30:09 (14 months ago)
- Message #2442
  For example, there is an application named Application X. When the application fails to process a request, it logs an error event with eventid 1000 and a message saying that it failed to process the request.
  
  I want to to create a service monitor in Nagios that will accept the passive checks.
```
define service{
        use                     generic-service
        hostgroup_name          windows-servers
        service_description     Application X
        display_name            Application X
        }
```
  Then I would configure real-time event log monitoring to monitor for the eventid 1000 from source AppX.
```
[/settings/eventlog/real-time/filters/Application X]
alias = Application X
filter = id = 1000 AND source = 'AppX'
```
  When nscp sends the event to NSCA, I would want it to insert Application X in the NSCA as the service parameter. It would look like this.
```
 \trunk\modules\NSCAClient\NSCAClient.cpp:416  Sending (data): host: server1, service: Application X, code: 2, time: 1331852045, result: error AppX: Failed to process request.
```
  But today, it leaves the service parameter blank.
```
 \trunk\modules\NSCAClient\NSCAClient.cpp:416  Sending (data): host: server1, service: , code: 2, time: 1331852045, result: error AppX: Failed to process request.
```
  So I'm hoping the alias parameter can work like it does with scheduled monitors, or you have some other solution to fill in the service parameter.
  
  Thanks!
  
  mikep
  mikep
  
  03/16/12 07:15:17 (14 months ago)
  - Message #2449
    Havent had time to write up the blog post yet but will try to do so tomorrow... In the mean time this is what I use in my unit test case (which is the basis for the blog post-yet-to-be-written)
```
/modules
pytest_eventlog=CheckEventLog
[/settings/pytest_eventlog/real-time]
enabled=true
filter=id = 1000 and category = 0
maximum age=5s
destination=pytest_evlog
language=english
debug=true
enable active=true
/settings/pytest_eventlog/real-time/filters
test=id = 1000 and category = 1
```
    UPDATE I fixed an issue with reading multiple filters in build 145 or some such so grab latest build if you want to specify "filters"... Also added a debug option and a lot of new filters so grab that build anyways :)
    
    Michael Medin
    mickem
    
    03/19/12 08:13:06 (14 months ago)
    - Message #2451
      Thanks for the update Michael. I'm still not clear if this doesn't work as I expect it to work, or if I'm still doing something wrong. I have updated my files to try to meet your format.
      
      [/modules] AppX_eventlog = CheckEventLog [/settings/AppX_eventlog/real-time] enabled=true filter=id = 1000 and severity = 'warning' maximum age=5m destination=NSCA language=english debug=true enable active=true [/settings/AppX_eventlog/real-time/filters] test=id = 1000 AND source = 'AppX'
      But the results are still not what I'm expecting. The filter appears to be working. An alert is send to NSCA when I create a corresponding event log entry.
      
      The problem is that the NSCA event is still missing a "service:" name.
      
      d \trunk\modules\NSCAClient\NSCAClient.cpp:391 Sending (data): host: server01, service: , code: 2, time: 1332156360, result: error AppX:
      So when this reaches the Nagios server, it looks like a host check instead of a service check.
      
      Mar 19 11:29:50 nagiosdev3 nagios: PASSIVE HOST CHECK: server01;2;error AppX: Mar 19 11:29:50 nagiosdev3 nagios: HOST ALERT: server01;UNREACHABLE;HARD;1;error AppX:
      What I was expecting to see was "service: test" in the NSCA message nscp sends. I assumed "test" would be inserted, since we started the filter line with "test=".
      
      I was also expecting the event log message to be sent in the NSCA message after "error AppX".
      
      d \trunk\modules\NSCAClient\NSCAClient.cpp:391 Sending (data): host: server01, service: test, code: 2, time: 1332156360, result: error AppX: Failed to process request.
      This capability is very important to me. But to make it useful, I need to be able to associate the defined filters with services in Nagios. You allow us to do this in your scheduled monitors, by the use of the "alias=" parameter.
      
      Am I misunderstanding how this capability should work, or am I not writing my config properly?
      
      Thanks!
      
      mikep
      mikep
      
      03/19/12 20:59:57 (14 months ago)
      - Message #2452
        
        Yeah I noticed I had completely forgotten about it late yesterday when I was writing my blog. When I was writing this code I was writing my eventlog-to-syslog forwarder which doesn't use the service_name so I "added it on the TODO list" but forgot about it :)
        
        I have added (but note tested) it in the build which is building now (hopefully out in a bit). I shall run some more tests and publish the blog post and a new "last RC" tonight... please let me know if there are any other issues/things I have forgotten about :)
        
        BTW so you know how it works, just copy-pasting the NSCA section of the blog post here for reference: This has not been tested and/or proof read so don't take it to seriously
        
        If we are planning to use this with NSCA (and we are) there are a few things to extra to configure. First we have a concept called service_name which we need to define. A service name is the way Nagios (or Icinga) associates the result with a check. So if you have multiple checks you need to be able to configure multiple service names for different filters. The way this is handled is using aliases. Aliases can be configured in two ways:
        
        Locally by settings the key for the filter query under […/filters].
        Globally in the […/real-time] section (All filters without an alias will use this alias.)
        So if you in Nagios have two different service_checks (eventlog_1 and eventlog_2) you need to set this using the […/filters] section like so:
        
        [/settings/eventlog/real-time/filters] eventlog_1=id = 1000 and category = 1 eventlog_1=id = 1000 and category = 0
        The other thing we need to configure is the NSCA client it self which for simple scenarios is pretty straight forward to configure as well:
        
        [/modules] ; ... NSCAClient = 1 [/settings/NSCA/client/targets/default] address=nsca://127.0.0.1:5667 encryption=aes256 password=YL04nBb14stIgCjZxcudGtMqz4E6NN3W
        Finally we need to tell CheckEventlog? to send messages to NSCA which is done by specifying the destination:
        
        [/settings/eventlog/real-time] ; ... destination=NSCA
        Michael Medin
        
        mickem
        
        03/20/12 07:47:11 (14 months ago)
        
        Message #2457
        
        This is great! The service name is now set correctly, so Nagios is happy.
        
        My test was the following.
        
        [/settings/AppX_eventlog/real-time/filters] AppX=id = 1000 AND source = 'AppX' AppY=id = 1000 AND source = 'AppY'
        And I got the expected results.
        
        d \trunk\modules\NSCAClient\NSCAClient.cpp:391 Sending (data): host: server01, service: AppX, code: 2, time: 1332238250, result: error AppX: d \trunk\modules\NSCAClient\NSCAClient.cpp:391 Sending (data): host: server01, service: AppY, code: 2, time: 1332238256, result: error AppY: d \trunk\modules\NSCAClient\NSCAClient.cpp:391 Sending (data): host: server01, service: AppX, code: 2, time: 1332238491, result: warning AppX:
        This is going to be a very good capability to have.
        
        Can I suggest two possible enhancements?
        
        1) Allow me to configure the severity that will be sent on a per filter basis. For example, I could create two filters, the first matches on source = 'AppX' and severity = 'warning', the second matches on source = 'AppX' and severity = 'error'. The first filter would set the "code:" parameter in the NSCA message to 1 (warning), while the second filter would set the "code:" parameter to 2 (critical). I think you let us specify warning vs error criteria in the normal event log monitoring. But I don't know of this option in the real-time version.
        
        2) Pass the evetn log message in the NSCA message under the "result:" parameter. Today, it looks like you pass the severity and filter alias. (i.e. "error AppX:") I think it'd may be useful to pass the event log message with that data. (i.e. "error AppX: Could not connect to resource.")
        
        Thanks for your great work Michael!
        
        mikep
        
        mikep
        
        03/20/12 18:34:23 (14 months ago)
        
        Message #2458
        
        First one is "sort of planned" but not till next major version (ie. after 0.4.0). Since this is the first version of real time filters the idea is to keep it reasonably simple to see what people would want and then extend it more.
        
        The second one sounds like you want to set syntax. Which default should be %type% %source%: %message% (but can be configurable)...
        
        Michael Medin
        
        mickem
        
        03/20/12 20:43:58 (14 months ago)
        
        Message #2459
        
        By the way for you first enhancements you can achieve that with either python or lua scripts I think.
        
        Something along the lines of:
        
        AppX_w=id = 1000 AND source = 'AppX' and level = 'warning' AppX_e=id = 1000 AND source = 'AppX' and level = 'error' ...
        And then send it off to your script (ie:
        
        destination=my_lua_subscriber
        And in the lua script truncate the _w and _e and turn that into status codes and then push it on wards to NSCA...
        
        Michael Medin
        
        mickem
        
        03/20/12 22:49:34 (14 months ago)
        
        Message #2460
        
        BTW: I have now posted my blog post which briefly explains how to use real-time filters: http://blog.medin.name/2012/03/20/real-time-event-log-monitoring-with-nsclient/
        
        mickem
        
        03/20/12 22:50:11 (14 months ago)
        
        Message #2475
        
        Hi Michael,
        
        When no matching events are found within the maximum age timeframe, the message sent to NSCA has a CRITICAL state. I believe this should be an OK state.
        
        I found this function in the code.
        
        void real_time_thread::process_no_events(std::wstring alias) { std::wstring response; if (alias.empty()) alias = info.alias; if (!nscapi::core_helper::submit_simple_message(info.target, alias, NSCAPI::returnCRIT, info.ok_msg, info.perf_msg, response)) { NSC_LOG_ERROR(_T("Failed to submit evenhtlog result: ") + response); }
        I believe that
        
        NSCAPI::returnCRIT
        should be
        
        NSCAPI::returnOK
        Can you confirm this to be the case?
        
        Thanks!
        
        mikep
        
        mikep
        
        03/23/12 19:19:54 (14 months ago)
        
        Message #2476
        
        Indeed you are correct, thanks!
        
        Fixed in next build...
        
        Michael Medin
        
        mickem
        
        03/25/12 21:24:24 (14 months ago)

Tree View Flat View (newer first) Flat View (older first)

Subscriptions

Download in other formats:

RSS Feed