By using the Qloaderd mechanism, it is possible to have a number of distinct Asterisk servers, each uploading data to a different partition of the same QueueMetrics database. This makes it possible to run an analysis that spans the whole cluster, and not just one single Asterisk server.
To set up a cluster of Asterisk servers to be monitored through QueueMetrics, you should adhere to the following deployment rules:
- Agent names must be unique throughout the call center; that is, you cannot have an Agent/101 working on Asterisk server A and another Agent/101 working on Asterisk server B, as their data would be mixed and it would be quite hard to tell who did what.
- Queue names may be shared over more than one server, and QUEUEMETRICS will report on that queue as if it had been processed on one big, single box.
- As the real-time monitoring is per-queue, you can run real-time monitoring on a queue by queue basis, no matter on which physical servers those queues are hosted on, or if they are hosted on more than one server.
This deployment makes it possible to grow your call center by adding more Asterisk servers as needed to handle the traffic.
![[Important]](../images/icons/important.png){kind=icon} | Important |
|---|---|
in order to run a clustered version of QueueMetrics, you need to use a special cluster licence key. If you need to test this feature before purchasing, you should ask for a cluster temporary key, as the ordinary temporary keys do not natively support cluster mode. |
To get started, you must install Qloaderd on each Asterisk server and get sure that it is uploading data to the main QueueMetrics database. Each server must uploading data to a distinct partition, e.g. if you have three servers, you could upload to partitions named "S1", "S2" and "S3". In short, each instance of Qloaderd is configured exactly as if it was in the single-server MySQL storage model.
Setting QueueMetrics to work with clustering requires a little effort, as we must provide it with all information necessary to contact and distinguish each Asterisk server and perform its duties, e.g. logging on agents. We have to edit the configuration.properties file and define the machines that make up our cluster by giving each a short name. This name might be the same as the partition name or might be different - as you best see fit. In the following example, we will setup a cluster of two machines - one called "aleph" with its data uploaded on partition "P001" and one called "trix" with its data uploaded to partition "P002".
# Cluster to poll for RT data # list of pipe-separated members of the cluster cluster.servers=aleph|trix
This sets up a cluster made up of two Asterisk servers, called "aleph" and "trix". For each box, we then create an entry like the following one for "aleph":
cluster.aleph.manager=tcp:dial:12345@10.10.3.5 cluster.aleph.queuelog=sql:P001 cluster.aleph.monitored_calls=z:/qm_streamcall/server_aleph cluster.aleph.callfilesdir= cluster.aleph.audioRpcServer= cluster.aleph.agentSecurityKey=
And weâll do the same for the other server "trix".
cluster.trix.manager=tcp:admin:amp111@127.0.0.1 cluster.trix.queuelog=sql:P002 cluster.trix.monitored_calls=z:/qm_streamcall/server_trix cluster.trix.callfilesdir= cluster.trix.audioRpcServer= cluster.trix.agentSecurityKey=
The explanation of the entries is:
- The manager entry refers to the Asterisk manager API interface for that machine, and is written as tcp:[login]:[password]@[server]. This is needed for Live monitoring and to login/logoff/pause agents. Make sure there is a matching entry in the file /etc/asterisk/manager.conf on each server!
- The queuelog file refers to which partition the data for this server will be pulled from. The format is the same as the sql:partition format we previously encountered.
- The monitored_calls entry points to a disk share where call recordings for this machine are found. This makes it possible to listen to calls through the QueueMetrics browser interface.
- The other entries should be left blank.
Now change the following property:
# This is the default queue log file. default.queue_log_file=cluster:*
And restart QueueMetrics. Now all queries you run are run on the whole cluster, and the real-time monitoring is run on the whole cluster as well.
For more detail on clustering in QueueMetrics, see the section "Monitoring clusters with QueueMetrics" in the QueueMetrics user manual.