I understand your problem and i cant help in that case :/ In our organization that is not a problem because the email is sent to the TTS and it has to be verified... And we base this notifications on icinga due to some restrictions on remote machines, and some other problems :)
Maybe some other user can help you in this case ;) Best, João Graça On 19/06/2015 15:56, Shay Rojansky wrote: > 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 > <mailto: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 >> <mailto: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 >> <mailto:icinga-users@lists.icinga.org> >> https://lists.icinga.org/mailman/listinfo/icinga-users >> >> >> >> >> _______________________________________________ >> icinga-users mailing list >> icinga-users@lists.icinga.org <mailto:icinga-users@lists.icinga.org> >> https://lists.icinga.org/mailman/listinfo/icinga-users > > > _______________________________________________ > icinga-users mailing list > icinga-users@lists.icinga.org <mailto: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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
