Pfennig, Klaus (BIT B 3) wrote:
Hilist,
We're about to migrate from nagios to icinga. After dealing with some
kind of trouble, we now have a problem, which we - until now - can't
solve on our own. Before opening a new issue about the bug (?), I want
to ask you, if there is an error in our setup, I've missed an email
about this issue on the list or it's even a (new) bug in icinga:
Most of our host- and service-checks are being passively checked in a
regular interval (distributed monitoring). But some of our (passive)
checks receive no regular check results, they receive only a check
result if the state of the particular host/service changes. In many
cases, it is possible, that there is no state-change /
check-result-update for about 2 weeks or even longer.
The ClassicUI displays everything correct: last check, duration,
number of host-/service-checks etc. (In this case: last check was on
30-08-2011). All entries in status.dat and retention.dat are okay and
up-to-date.
could i get (also in a private mail) get some insights on such an example?
If we activate the "glorious three" (idomod/ido2db/mysql) and do a
'/etc/init-d/icinga start', the following scenario occurs: the
retained information seems to be only transferred to the database if
they're not too old (I guess, about a week or so and it matters both,
host- and service-checks).
retained data is being read from the core (retention.dat) and then
signalled via event broker callback to the idomod module, which then
dumps the config onto the database at that moment (this is what we call
core blocking by a config dump). although it would be interesting why
some data rushes into and some does not. could you then turn on
debuggong on idomod and ido2db (seperated files) and track the
hosts/services which are dumped correctly, to get an idea what might
happen over there?
So they're not written to our database (I've checked tables
icinga_servicechecks and icinga_servicestatus; in icinga_objects
everything is correct),
configs are written to the config tables, i.e. icinga_services. the
icinga_servicechecks table is only populated if a check happens and the
callback triggers that event in the event broker module. same goes for
the status update.
hence icinga-web doesn't display them and calculates a wrong number of
host-/service-checks.
are you speaking about "checks" meaning that a host / service shows up
in the interface e.g. on the status cronk? is the object in the database
flagged as is_active ?
And some more curious: if we submit passive service- and
host-check-results via interface or command-line, the results will be
displayed correct -- for about a week and then they're "gone"
(although max_age for service- and host-checks is one day)...
what are you exactly talking about? state history? check history? some
screenshots might be helpful.
At this time, we have a difference of about 800 service-checks between
ClassicUI and Icinga-web (or better: between status.dat/retention.dat
and ido) and this is the only problem that prevents us from migrating
to icinga.
For a better view on our setup, I've added some extracts of our config:
i would be interested in the
- os
- icinga, classicui, idoutils version
- mysql version, any performance tweaks for innodb applied?
. icinga web version
max_servicechecks_age=1440
max_hostchecks_age=1440
on what purpose you are saving the check data?
max_eventhandlers_age=10080
max_externalcommands_age=0
max_logentries_age=0
this table may grow and grow and grow - i hope you are aware of that.
max_acknowledgements_age=0
clean_realtime_tables_on_core_startup=1
clean_config_tables_on_core_startup=1
trim_db_interval=60
this means every 60 seconds - the new default in recent release was
changed to 3600s.
data_processing_options=-1
is there *any* logical reason to use -1 ?
config_output_options=2
so retained config ...
kind regards,
michael
Any ideas?
Thanks in advance and kind regards
Klaus
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/icinga-users
--
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
Icinga Core& IDOUtils Developer
http://www.icinga.org
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/icinga-users
