Understanding MySQL storage and clustering in QueueMetrics
| Revision History |
|---|
| Revision $Revision: 1.2 $ | $Date: 2010/04/23 10:27:06 $ | L |
1. 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
might 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.