October 31, 2011 1:56 PM
Workaround for "ODW_STATUS WARNING - No update since" Notification in Opsview
This week's post is a technical workaround, from Opsview Community edition user Matthew White, for anyone experiencing an ODW_Status Warning in Opsview due to heavy server load.
Over to you Matthew...
For a while I have been seeing a daily ODW_STATUS_WARNING about no updates since 03:59:59 on my master opsview server. I was 90% sure this was due to the load that I put on the server (load average sits around 6 and goes up to 13 at certain times of the day) but still got bored of running cleanup_import and then import_runtime -i 1. I started off by manually clearing out all but 1 week of data from the runtime database (this is run as part of opsview_master_housekeep for various tables) and this didn't resolve the issue. In the end I modified my cron table so that the rc.opsview cron_daily task runs 30 minutes later (at 41 minutes past the hour instead of 11 minutes past). Since changing that I seem to have had no further re-occurrences of the No update prompt.
I am aware that each time I update Opsview I am going to have to make this change until I manage to move the databases to their own host and rebuild the master server onto new hardware. But its a workaround for now!
For reference the crontab now looks like:
Do you have technical experience of using Opsview that you would like to share with Opsview's community? We'd love to hear from you! Contact us at marketing@opsview.com or @opsview on Twitter.
Over to you Matthew...
For a while I have been seeing a daily ODW_STATUS_WARNING about no updates since 03:59:59 on my master opsview server. I was 90% sure this was due to the load that I put on the server (load average sits around 6 and goes up to 13 at certain times of the day) but still got bored of running cleanup_import and then import_runtime -i 1. I started off by manually clearing out all but 1 week of data from the runtime database (this is run as part of opsview_master_housekeep for various tables) and this didn't resolve the issue. In the end I modified my cron table so that the rc.opsview cron_daily task runs 30 minutes later (at 41 minutes past the hour instead of 11 minutes past). Since changing that I seem to have had no further re-occurrences of the No update prompt.
I am aware that each time I update Opsview I am going to have to make this change until I manage to move the databases to their own host and rebuild the master server onto new hardware. But its a workaround for now!
For reference the crontab now looks like:
# OPSVIEW-START # Do not remove comment above. Everything between OPSVIEW-START and OPSVIEW-END # will be automatically installed as part of an Opsview install/upgrade 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/nagios/bin/mrtg_genstats.sh > /dev/null 2>&1 41 3 * * * /usr/local/nagios/bin/rc.opsview cron_daily > /dev/null 2>&1 22 2,6,10,14,18,22 * * * . /usr/local/nagios/bin/profile && /usr/local/nagios/bin/opsview_cronjobs 4hourly > /dev/null 2>&1 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/nagios/bin/call_nmis nmis.pl type=collect mthread=true > /dev/null 2>&1 34 0,4,8,12,16,20 * * * /usr/local/nagios/bin/call_nmis nmis.pl type=update mthread=true > /dev/null 2>&1 4 * * * * . /usr/local/nagios/bin/profile && /usr/local/nagios/bin/import_runtime -q # NMIS reports 0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day health 0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day top10 0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day outage 0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day response 0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day avail 0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day port 0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week health 0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week top10 0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week outage 0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week response 0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week avail 0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week port 0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month health 0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month top10 0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month outage 0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month response 0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month avail 0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month port # OPSVIEW-END
About the Author
Matthew has been working in IT for 5 years after graduating from the University of Durham with a Degree in Software Engineering. He currently works for an IT outsourcing company in London, working with a range of including Microsoft, VMWare, Citrix, Juniper, Cisco, CheckPoint, RSA, Lumension.Legal Disclaimer
This blog post is contributed by a member of the Opsview community. The Opsview project and Opsera Ltd. accept no responsibility for the accuracy of its content and are not liable for any direct or indirect damages caused by its use.Do you have technical experience of using Opsview that you would like to share with Opsview's community? We'd love to hear from you! Contact us at marketing@opsview.com or @opsview on Twitter.
Subscribe to this blog
Email
Permalink
Print
Contact Us
