Common problems and solutions

Avoiding queue_log file rotation

On most Asterisk PBXs, the queue_log file is rotated daily or weekly along with the other Asterisk logs found in /var/log/asterisk. The queue_log file contains essential information on how the call center is working. It is used by QueueMetrics to report on the status and the actual work being performed in your call center, and you surely want to keep that data in a safe place for cross-period analysis.

Although QueueMetrics keeps its own copy of that data set in its own database and will automatically detect file rotations, if the call center process is critical to you, we advise to keep a backup of those files, just in case.

Stopping and starting QueueMetrics

You can stop and restart the QueueMetrics application by issuing the commands

/etc/init.d/queuemetrics stop
/etc/init.d/queuemetrics start
/etc/init.d/queuemetrics restart

Setting QueueMetrics memory limits

QueueMetrics is a complex application and it is designed to be used by multiple parallel users. This means that if you have a large data set and many users running queries on it, it is possible that you start getting "Out of memory" errors.

To fine-tune the amount of memory used by your system, you can edit the file /etc/sysconfig/qm-tomcat6 and modify JAVA_OPTS to:

JAVA_OPTS="-Xms1G -Xmx1G"

The Xms parameter is the amount of memory that Java uses on startup for its object heap; and the Xmx is its maximum allowed size. For best speed, keep both to the same value unless you have experience in tuning Java memory requirements.

Installing QueueMetrics on a different server

Installing on a different server can be a good idea if your call center has more than 20 or 30 agents and you don’t want to slow down the main Asterisk box when running statistics.

It’s very easy to do:

  • Install QueueMetrics on the new server and install a local copy of the database

  • Create a rule on the new QueueMetrics database that allows for connection to MySQL from a client that is located on the Asterisk server.

  • Tell the uniloader on the PBX to send data to the new server.

Go to the FreePBX server and edit the file /etc/sysconfig/uniloader.

It should look like the following:

QUEUELOG=/var/log/asterisk/queue_log
LOGFILE=/var/log/asterisk/uniloader.log
LOCKFILE=/var/lock/subsys/uniloader
PIDFILE=/run/uniloader.pid

# On-premise QueueMetrics instance
URI="mysql:tcp(127.0.0.1:3306)/queuemetrics?allowOldPasswords=1"
LOGIN=queuemetrics
PASS=javadude
TOKEN=P001

Edit the variable URI, to point to the new QueueMetrics server.

Then issue the command:

/etc/init.d/uniloader restart

Check the log file to make sure that there are no errors and data is being uploaded correctly to the QM server.

You should also change the callfile.dir property in order to point to the Asterisk server and, on the Asterisk server itself, allow Asterisk Manager (AMI) access from the QueueMetrics server.

As a last warning, you should make sure that the Asterisk server and the QueueMetrics server have clocks aligned to a sub-second difference; otherwise the real-time page may show strange information, e.g. by displaying negative wait times. In order to avoid this, you should install ntpd on both servers.