Hello
Am 01.11.2014 um 22:14 schrieb [email protected]: > > Am 01.11.2014 um 21:32 schrieb Darko Hojnik: >> Hi there, >> >> Since some days ago I am trying to configure notifications properly on our >> demands. Without success. I write this first for help but as an feedback >> also. Not about for bullshit storming and another kind of stupid flamewars. >> So I am asking me now are these maybe bugs, missing features, an >> misconfiguration? Should I give up? It?s Icinga2 stable and good enough for >> my company? >> >> The first task is thats on 97% of our Infrastructure it?s necessary that >> people gets notified only if an service is going in an critical state and >> gets notified again even the event has been acknowledged or has gone back to >> the state OK. That sounds like an simple task but it is not. > > I do understand that it's sometimes frustrating when something does not > work, and noone is there to take a look or help out. > > But you should also consider what others might be doing, or why there is > no simple answer. > > I for myself am in the middle of writing Icinga 2 documentation (yes, > right now too, just because we're behind our time schedule for the 2.2 > release), planning 1.12 release, and organizing a talk for OSMC in 2,5 > weeks. Other Icinga developers might just have enough to do on their own. > > And your problem doesn't sound simple. If I got that correctly, you're > using an 8 node cluster (did you see my reply to your thread some hours > ago? there was a question there too). > > When a problem is not simple, it will take everyone _time_. Time to > read, understand, reproduce, writing an answer you're enjoying, or > getting an idea from. > > Still, it's open source software, and many of us do it for fun, when not > at work (still, at netways it's also fun at work, but that's different). > Nagging us down or bumping questions won't help much - unless it sounds > mission critical, or one finds it challenging to stumble into the > problem - like the 1.x core reload problem recently. > > Nevertheless, you should consider that answers may last over here. > > If you think you've found a bug, then please do report one. The > developers (not only me) appreciate any feedback and possible issues. > > Still, the same as before applies - if noone looks into it or doesn't > comment on it, it's a matter of todos and time. If you want to sponsor > development time for resolving bugs - sure, just do it. > No flames, blames or another punker-stuff… I write it honestly The mostly once whats confusing me is that we have several years running an Nagios 3 install where we are able to filter the notifications. I believed Icinga 1.x is not only a fork from nagios. It’s the legitim successor of Nagios. And Icinga 2 is the improvement to make the software holy, mighty and absolutely awesome. notification_options u,c,r ; Send notifications about unknown, critical, and recovery events notification_interval 120 ; Re-notify about service problems every hour notification_period 24x7 ; Notifications can be sent out at any time So it seems my problem if if I have it right understanded, that Icinga 2 can not distinguish between the states Unknown, Critical and Warning about Recovery notifications. It would always sent an recovery-notification if an service switches from an bad state to OK. Or even you have configured out recovery-notifications. Then notifications with the state Critical would been send only. Even you wanna have noting to do with the state Warning in your notifications. So if Icinga has not an functionality about filtering notifications from states what is the sense about Icinga? Ok the first mission critical mission to collecting data about the Infrastructure works like a charm. But in my opinion, to be unable to define exactly which kind of notification has to send and which not makes the project in my point of view absolutely useless. My conclusion I have learned the new syntax and Icinga 2 and after testing and configuring the last three weeks. My current state is I am 98% ready before rollout Icinga 2 to 500 servers. And yes its frustrating me totally that my work may have been useless because while with this showstopper would the project canceled completely. Trivago would like to be one of the first company’s who is willing to bring Icinga 2 as an mission critical application in there infrastructure. We are willing to share our experience and sometimes could be code written on one of our hackathons for this project also. In short my setup works with three nodes and an master above. The master only is reporting and storing stuff to an Postgresql-database. Because the master has the modules ido-postgresql and notifications activated only. So all issues are stored in a database. I could not believe that this project is unable to implement something what is so important. And I don’t think that I am alone with this issue. thanks all for reading Darko Hojnik Datacenter Operations [email protected] www.trivago.com Court of Registration: Amtsgericht Duesseldorf, Registration Number: HRB 51842 Managing directors: Rolf Schroemgens • Malte Siewert • Peter Vinnemeier trivago GmbH • Bennigsen-Platz 1 • 40474 Duesseldorf, Germany * This email message may contain legally privileged and/or confidential information. You are hereby notified that any disclosure, copying, distribution, or use of this email message is strictly prohibited. _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
