On 29.07.2012 15:28, Carl R. Friend wrote: > On Sun, 29 Jul 2012, Marc Haber wrote: > >> I see. It should log this so that one can immediately know what is >> going on there. > > It does -- indirectly. If one examines the icinga.log file, > one will see a line of "Event loop started..."; this indicates that > the main event loop has started and scheduled events will now happen > as expected. Before that, they don't as the database is being > rebuilt (the first thing that ido2db does is delete much of the > data that matches its own instance_id).
ido2db does not log data insertions to syslog, but rather to the debug log, which is *very* verbose. within the config examples, you might also see a service named "Icinga Startup delay" which makes use of some macros showing the diff between start time and event loop start time (check_command check_icinga_startup_delay - mostly there for performance profiling while development). > > > The actual delay at startup is dependent on many factors > including, but not restricted to, the number of hosts/services in > the instance in question, network latency between the monitoring > host and the database host, and contention on the database proper. it also depends on various parameters set, especially on the data processing options. best is to have a read on the wiki on performance tuning. https://wiki.icinga.org/display/howtos/Performance+Tuning > > In my simple instance at home (9 hosts/43 services) with the > database running on the same host as Icinga, the delay is three > seconds; on the much bigger one I run at work (1271 hosts/7340 > services) that has contention on the database from three other > Icinga instances, the startup can take three or more minutes, > and, in the case where all instances are starting at the same > time (e.g. after a reboot of the system), close to fifteen. > >> That does not sound good. Is there a way to mitigate this? In a big >> installation, this means being blind for several minutes, or one would >> have to run multiple instances of Icinga, take care not to reload both >> at once and live with a number of weird issues that need explaining to >> end users. > > To the best of my knowledge, not at the moment; if one is using > the ido2db facility that's "just the way it works". there's been plenty of effort in making this a lot better, but given the design data input works in *DO, you have 2 possibilities: - let the core push to a kernel msg queue until it's full, waiting endless for data updates on the gui (and have the problem with queue full - drop data, like NDO 1.5 has) - let the core wait for data being processed, showing accurate and actual data on the gui, but a bit more wait time due to various dependencies on the data inserts/updates, parallel operations instead of a serialized flow is not possible. one would want such a change, but then you might just throw away the database schema, and rewrite the ido2db daemon. and while you're at it, change the idomod data schema as well. look on the dev tracker, there are some issues discussing that exact questions. > > >> Is a possibility to keep scheduler and event handler running while the >> IDO database is rebuilt on the Icinga roadmap? > > It might be possible if one eschews the use of ido2db directly and > periodically runs "log2db" using the icinga.log file as input. that method only imports logs into the logentries table, but nothing else. to target state and config information, this is NOT a safe way, as well as does not replace reporting information. > This, > however, would put a noticible delay into icinga-web that would not > be present in the "classic" CGIs (which use status.dat). I have NOT > tried this in any of the environments I manage and present it as pure > speculation, but it would remove the startup delay as the instance > would not wait for a database rebuild. well one could write a wrapper, reading retention.dat and objects.cache importing that into the database. then you have to make a decision - let the core wait until this operation is finished, and then start checks (generating new data), or would you want the core to start checking, spitting data at you, and you do not know how to handle that data correctly (data integration!). so you'll see - there are endless methods and workarounds, but the only correct one is imho to have all config/status data processed and _then_ start with new data, queued or not. i'm currently more into the idea of finding something completely new. though i do not have endless time - holidays are the time where you do maintenance and break stuff while others enjoy the beach. -- DI (FH) Michael Friedrich Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria email: [email protected] phone: +43 1 4277 14359 mobile: +43 664 60277 14359 fax: +43 1 4277 14338 web: http://www.univie.ac.at/zid http://www.aco.net Lead Icinga Core Developer http://www.icinga.org ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ icinga-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/icinga-users
