Tracking timing and time-zone problems in QueueMetrics
2009-01-12It sometimes happens that a new QueueMetrics install has time-zone problems on a specified box.
Generally speaking, the local time for the QueueMetrics instance should be the same as your own
local time, and so should be for the MySQL server and the Asterisk server it relies on.
Small timing discrepancies can cause many problems, like calls not shown, wrong call duration and wait times on the realtime page, or even calls not showing at all on the realtime page.
Generally speaking, the first thing you should do if you suspect a timing problem is run a command that will sync the system clock with an high-precision atomic clock on all involved machines, for example:
As harware clocks tend to "drift" in the long period, it is a good idea to add this command to a nightly cron job that will keep the clocks of all involved systems below a one-second difference.
If you want to see the current clock and time zone for the QueueMetrics server and its MySQL instance, just click on the Licence page and those values will be shown. It's important that there is no difference between those values.
If one of the clocks is very different from the current time, it is usually a time zone problem on your box. This can usually be solved/detected running the following commands:
If everything seems correct and still the QueueMetrics server will insist on using the wrong time zone, you should try the following options:
Small timing discrepancies can cause many problems, like calls not shown, wrong call duration and wait times on the realtime page, or even calls not showing at all on the realtime page.
Generally speaking, the first thing you should do if you suspect a timing problem is run a command that will sync the system clock with an high-precision atomic clock on all involved machines, for example:
ntpdate ntp.ien.it
As harware clocks tend to "drift" in the long period, it is a good idea to add this command to a nightly cron job that will keep the clocks of all involved systems below a one-second difference.
If you want to see the current clock and time zone for the QueueMetrics server and its MySQL instance, just click on the Licence page and those values will be shown. It's important that there is no difference between those values.
If one of the clocks is very different from the current time, it is usually a time zone problem on your box. This can usually be solved/detected running the following commands:
[root@asterisk1 ~]# hwclock --show
[root@asterisk1 ~]# date -R
[root@asterisk1 ~]# date
[root@asterisk1 ~]# more /etc/sysconfig/clock
If everything seems correct and still the QueueMetrics server will insist on using the wrong time zone, you should try the following options:
- Set the TZ environment variable, like export TZ="US/Eastern" in the startup script you use for the QueueMetrics server
- Add the following option to the JAVA_OPTS environment variable: -Duser.timezone=US/Eastern
in the startup script you use for the QueueMetrics server.
For example, if you live in a place that is GMT+5, you could change the /etc/init.d/queuemetrics init script so that it has an options line like:export JAVA_OPTS="-Xms128M -Xmx128M -server -Duser.timezone=GMT+05:00"
After saving and restarting QM, if you go to the Realtime page, you should see that the time is now correct.