Understanding MySQL storage and clustering

QueueMetrics works by parsing an ACD event file called queue_log that Asterisk produces during its normal operations. QueueMetrics is built to run with two different storage models:

  • The Flat File storage model lets the data reside in a file on the Asterisk server, and is the default mode;

  • The MySQL storage model uploads the data to a database using a small loader script called Qloaderd and has QueueMetrics read it back from that database.

Running through a flat-file storage is usually enough for small call centers having both Asterisk and QueueMetrics living on the same server. This is okay for small setups (like 10-20 agents) where the size of the queue_log file will hardly ever reach the tens of megabytes.

On the contrary, if you run a larger setup, the advantages of the MySQL storage model become more important and worth the extra setup:

  • You can install QueueMetrics on a separate server from the main Asterisk server. This means that as your Asterisk server grows busier, you don’t want to risk that someone running a monster analysis through QueueMetrics may slow it down.

  • You get a lot of added flexibility: you can have MySQL, Asterisk and QueueMetrics live on different servers, and choose the best deployment model according to your actual usage load. You can also create hot-backup scenarios with a secondary QueueMetrics server that will take over in case the primary server should be down, and you can take full advantage of the database’s replication model to handle high load and high-availability requirements.

  • You get better efficiency: MySQL is optimized to maximize disk access efficiency when dealing with a subset of the whole data (e.g. getting today’s information for just one queue will not need scanning your whole ACD history)

  • You can have multiple Asterisk servers sending data to the same QueueMetrics instance and you can use that one instance to report on all activity through all servers: we call this clustering. This makes it possible to build very large call centers in a simple way, just by adding more inexpensive hardware to handle more calls and by putting yourself in a situation where a problem on a server will not take down the whole call center but just a fraction of it.