You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the logs would give insight on the failure exit code and the reason in one message.
The counter argument to this would be that alerts would happen on hard states and the user would know about it - but there are checks which go in and out of soft states which can only be viewed through historical log parsing + it gives more power to the developer to build his own analysis tools without resorting to any custom UIs.
Also some thought process around using structured logging (e.g. json) which is friendlier to elasticsearch would help in doing a lot of historical data extraction.
The text was updated successfully, but these errors were encountered:
This issue has been migrated from Redmine: https://dev.icinga.com/issues/12611
Created by saurabh_hirani on 2016-09-01 09:35:07 +00:00
Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-09-01 09:35:07 +00:00 (in Redmine)
icinga2 debug logs are immensely useful for viewing historical information via log monitoring tools.
As of now a check execution leads to the following debug logs:
[2016-08-31 06:47:57 -0700] notice/Process: Running command '/usr/lib/nagios/plugins/check_nrpe' '-H' '1.2.3.4' '-c' 'check_service' '-t' '30': PID 2847
[2016-08-31 06:47:57 -0700] debug/CheckerComponent: Check finished for object 'hostname!check_service-0'
[2016-08-31 06:47:57 -0700] notice/Process: PID 2847 ('/usr/lib/nagios/plugins/check_nrpe' '-H' '1.2.3.4' '-c' 'check_service' '-t' '30') terminated with exit code 0
This makes finding failed commands easy but doesn't give clarity on the following:
e.g.
[2016-08-31 06:47:57
0700] debug/CheckerComponent: Check finished for object 'hostname!check_swap-0'exit code - 2 - output - SSL handshake failure.the logs would give insight on the failure exit code and the reason in one message.
The counter argument to this would be that alerts would happen on hard states and the user would know about it - but there are checks which go in and out of soft states which can only be viewed through historical log parsing + it gives more power to the developer to build his own analysis tools without resorting to any custom UIs.
Also some thought process around using structured logging (e.g. json) which is friendlier to elasticsearch would help in doing a lot of historical data extraction.
The text was updated successfully, but these errors were encountered: