João, thanks for your answer. Yeah, I know about check_logilfes. My concern with this approach is that after an error log there will invariably be completely unrelated non-error logs, about something completely different in the application or system, especially in systems producing lots of logs. At that point the service becomes green again in my dashboards although nothing the error log hasn't been examined or acknowledged.
It's true that an email notification has been sent, but the service is now green in the webui (simply because some other non-critical event has been logged). In effect, that means I'm not using the web dashboards, and icinga2 is simply translating log error messages into emails; that seems like a shame (there are many other simpler methods for doing this). It seems to me that there's a fundamental event/state mismatch here... Shay On Fri, Jun 19, 2015 at 5:20 PM, João Graça <joao....@gmail.com> wrote: > Hello Shay, > > What i use for querying logs is the check_logfiles check... just google > it... > When it finds and error in a log file (it only checks errors based on diff > from last check) the state become critical and send an email, then, in the > next check and if there is no more NEW errors, it becomes OK. > > Hope it helps. > > > João Graça > > > > On 19-06-2015 15:03, Shay Rojansky wrote: > > Daniel, I may be misunderstanding this (the docs on volatile are extremely > light), but I don't see how that helps... A service that goes into CRITICAL > state because of an error log would be passive only (I think) - something > like logstash with its nagios_nsca plugin - what does volatile mean for > passive-only service? > > To recapitulate, I'm looking for a meaningful transition back to OK > state for a passive-only service that becomes critical because of an > application error log. There isn't an application-generated log that > expresses a return to OK state (since application logs are generally about > events and not about state transitions). So I guess I'm looking for some > way for an *operator* to acknowledge that an error log has investigated and > the service should go back to OK - it's pretty much a GUI question. Or if > someone has a different approach to managing states with regards to > application log events... > > Shay > > On Fri, Jun 19, 2015 at 8:16 AM, Daniel Parthey <p...@posteo.de> wrote: > >> You might have a look at "volatile services". >> >> >> http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/advanced-topics#volatile-services >> _______________________________________________ >> icinga-users mailing list >> icinga-users@lists.icinga.org >> https://lists.icinga.org/mailman/listinfo/icinga-users >> > > > > _______________________________________________ > icinga-users mailing > listicinga-users@lists.icinga.orghttps://lists.icinga.org/mailman/listinfo/icinga-users > > > > _______________________________________________ > icinga-users mailing list > icinga-users@lists.icinga.org > https://lists.icinga.org/mailman/listinfo/icinga-users > >
_______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
