Thanks for the response Raf. Yes the Nagios cgi pages are correct - I assume that is because its reading that info from files. My opsviewd.log does have a few import issues that seem to co-incide with when we see problems - I am concerned about the one at the top of this list [2009/07/08 17:44:54] [import_ndologsd] [WARN] Import of 1247068819470548, size=35240212, took 2674.88318109512 seconds > 5 seconds [2009/07/08 17:45:02] [import_ndologsd] [WARN] Import of 1247068821483999, size=86727, took 8.11954402923584 seconds > 5 seconds [2009/07/08 17:45:34] [import_ndologsd] [WARN] Import of 1247068834758987, size=2306127, took 28.0002701282501 seconds > 5 seconds [2009/07/08 17:45:51] [import_ndologsd] [WARN] Import of 1247068844539990, size=1401907, took 16.6511950492859 seconds > 5 seconds [2009/07/08 17:46:07] [import_ndologsd] [WARN] Import of 1247068852496928, size=1386952, took 16.3429758548737 seconds > 5 seconds [2009/07/08 17:46:32] [import_ndologsd] [WARN] Import of 1247068863620525, size=2233089, took 25.1329939365387 seconds > 5 seconds [2009/07/08 17:46:45] [import_ndologsd] [WARN] Import of 1247068871060241, size=1083300, took 13.0434839725494 seconds > 5 seconds [2009/07/08 17:47:10] [import_ndologsd] [WARN] Import of 1247068949423567, size=537320, took 6.85540199279785 seconds > 5 seconds [2009/07/08 17:52:54] [import_ndologsd] [WARN] Import of 1247070234375124, size=100348, took 5.26332020759583 seconds > 5 seconds We are using a remote server for the mySQL database which is of a very high spec, hardware is Sun, it has 16GB of RAM etc, so I dont think the database server is the issue - so although we dont have the innodb optimisations on it (it hosts a few databases) I dont think this is the problem. I am currently thinking that it may be a network issue between the Master and the Database server - is this likely? Also are we just over-doing it with the set up - we have? We have 12 slaves, which are not pooled. Slave 1 103 Hosts 398 Checks Slave 2 367 Hosts 779 Checks Slave 3 58 Hosts 180 Checks Slave 4 223 Hosts 404 Checks Slave 5 143 Hosts 242 Checks Slave 6 429 Hosts 856 Checks
Slave 7 327 Hosts 827 Checks Slave 8 341 Hosts 818 Checks Slave 9 142 Hosts 190 Checks Enabled Slave 10 185 Hosts 948 Checks Slave 11 195 Hosts 950 Checks Slave 12 227 Hosts 329 Checks For a total of 2764 hosts and 7080 checks. In the short term is there anyway of changing the importndo interval to 10 seconds rather than 5 to see if that eases anything. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Rafael Luis Carneiro Sent: 09 July 2009 14:12 To: Opsview Users Subject: Re: [opsview-users] Hostgroup Caching ? David, Are you seeing the correct state in the nagios (cgi) pages? If that's the case your ndoimport is behind, and you can easily see in the opsviewd.log file (you will see something like "[import_ndologsd] [WARN] Import of <number>, size=<number>, took XXX seconds > 5 seconds". http://docs.opsview.org/doku.php?id=opsview3:faq#import_took_5_seconds Raf On Thu, Jul 9, 2009 at 6:30 AM, David Bell <[email protected]> wrote: Hi there. I have an issue with the Hostgroup Hierarchy under the View section. If I have some checks that have gone to Unknown, it can take up to 30 minutes for them to clear to OK after they recover. At this time you can click into the Hostgroup, and the hosts will still show as Unknown, but if you then go into the host you see the true status. You probably recognise the name, yep I am the guy stuck with 12.2 on SLES10 Enterprise, so I know support is limited, but if you can give me some insight into the mechanism for generating what I assume are these cached views, it would be appreciated, I am working on persuading the people that need to be persuaded to let me rebuild this on Debian (and getting somewhere at last) but the users are starting to question the choice of Opsview because of what they perceive as bugs as they cannot understand where problems actually come from. Thanks David David W Bell Systems Developer UK Infrastructure Maxima PLC MailScanner has detected a possible fraud attempt from "wlmailhtml:{a0c5521f-79f0-4676-a608-69984109f564}mid:" claiming to be www.maxima.co.uk Tel: +44 (0) 20 7579 8100 DDI: +44 (0) 20 7579 8129 Fax: +44 (0) 20 7579 8200 24 Chiswell Street London EC1Y 4TY P Please consider the environment before printing this e-mail _______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/lists/listinfo/opsview-users -- Rafael Carneiro Computer Engineer ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
_______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/lists/listinfo/opsview-users
