-----Ursprüngliche Nachricht-----
Von: Michael Friedrich [mailto:[email protected]]
Gesendet: Dienstag, 27. September 2011 16:07
An: [email protected]
Betreff: Re: [icinga-users] retained states of hosts and services will not
transfered via ido2db to database ?
Pfennig, Klaus (BIT B 3) wrote:
Hi list,
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?
You should have received an email with 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?
In the email mentioned above I've attached some debug-files, which are reduced
to the example. I hope it will help you.
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 ?
I mean the host-/service checks in the total status (see my screenshot in the
separate email) and the "checks" which are displayed in Hoststatus-Ccronk or
ServiceStatus-Cronkl. The object is flagged as "is_active = 1" in
icinga_objects.
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.
I try to explain: if we submit a passive check result for a host- or
service-check, it will "appear" in icinga-web (it is written to
icinga_servicechecks / icinga_hostchecks). And after some time (I guess one
week, but I couldn't state this), they are "gone" ... it sounds strange, I
know, but that's the behaviour ....
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
sorry for not adding our environment in the first email:
icinga-core,classicui = latest git-version on debian lenny
idoutils = latest git-version on debian squeeze
icinga-web = latest git-version on debian squeeze
each compiled/installed on a separate host
mysql-version = 5.1.49-3, up to now, our dba hasn't done any innodb performance
tweaks because our database runs on a temporarely system and all databases are
under /dev/shm ... it's quite fast ....
max_servicechecks_age=1440
max_hostchecks_age=1440
on what purpose you are saving the check data?
We are playing around with some parameters, it's not the final setup.
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.
Yes, we hope, we know what we are doing ;) but as i said, it's not the final
setup.
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.
thanks for the advice, i will correct this setting.
data_processing_options=-1
is there *any* logical reason to use -1 ?
at least, just one: so we can ensure, that "everything" have to be written to
ido - in normal case and to ensure, that we've no error in our setting by
defining some other value.
We will never use this setting in production.
config_output_options=2
so retained config ...
kind regards
klaus
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
