Scenarios
One Asterisk instance, one local QueueMetrics instance
You want to use Uniloader for your local QueueMetrics instance.
In this case you should use the MySQL back-end. You would not usually use the AMI feedback as QueueMetrics is able to connect directly to the PBX.
You may also use the HTTP back-end, but there are currently no advantages in doing so.
One Asterisk instance, one hosted QueueMetrics Live instance
You want to use Uniloader for a QueueMetrics-Live instance.
In this case you should use the HTTP or HTTPS backend, and turn on AMI feedback, as the QueueMetrics Live instance has no way to connect directly to your PBX.
In order to make your life easier, QueueMetrics Live actions are pre-configured to send actions back via HTTP; you just need to make sure that the AMI credentials specified in the property 'callfile.dir' in 'configuration.properties' match the ones used on your PBX.
Multiple Asterisk instances, one hosted QueueMetrics-Live instance
You have multiple Asterisk boxes and want to consolidate all their activity into a single QueueMetrics-Live instance.
QueueMetris-Live supports up to 5 Asterisk instances in a cluster for a total of 50 agents per instance. Each Uniloader instance must upload data to a different partition. Each cluster member should be defined in the QueueMetrics-Live instance.
For example, this is how you would configure three Asterisk instances on a QueueMetrics-Live system:
default.queue_log_file=cluster:* cluster.servers=srva|srvb|srvc cluster.srva.manager=tcp:dial:12345@127.0.0.1 cluster.srva.queuelog=sql:A cluster.srvb.manager=tcp:dial:12345@127.0.0.1 cluster.srvb.queuelog=sql:B cluster.srvc.manager=tcp:dial:12345@127.0.0.1 cluster.srvc.queuelog=sql:C
In this case, you would run Uniloader with the token "srva" on server A, and it would upload data to partition A:
./uniloader --src=/var/log/asterisk/queue_log
upload --uri https://my.queuemetrics-live.com/MYINSTANCE
--login webqloader --pass CHANGEME --token=srva
The same goes for servers "srvb" and "srvc" that would upload to B and C respectively.
As you can see, each cluster member in QueueMetrics defines its own AMI credentials; so you can safely use the AMI feedback mode with no further configuration. Please note that it’s common for all AMI instances to just point to "127.0.0.1" because Uniloader runs on the same box as Asterisk itself.
| When configuring agents, make sure that you set the server for each agent, so when they log in to queues they already point to the right server. |
Multiple Asterisk instances, one QueueMetrics instance
You have multiple Asterisk boxes and want to consolidate all their activity into a single QueueMetrics instance.
In this case, you need a cluster-enabled QueueMetrics instance, and each Uniloader instance should upload data to a different partition. Each cluster member should be defined in the QueueMetrics instance (if you use the MySQL back-end, you set the token to the name of the partition; if you use HTTP you should set it to the name of the cluster member).
| The names for cluster members are the ones you use in the property 'cluster.servers' of your QueueMetrics 'configuration.properties' file. |
Each cluster member in QueueMetrics defines its own AMI credentials; so you can safely use the AMI feedback mode with no further configuration.
One Asterisk instance, multiple QueueMetrics-Live instances
You run multiple different clients on one Asterisk instance, and you want to send each of them to their own QueueMetrics Live instance.
In this case, you need to set up splitting rules so that data for each client is uploaded to the right QueueMetrics Live instance.
For example, your ''splitter.json'' file could look like:
[
{
"uri": "http://my.queuemetrics-live.com/client3",
"login": "webqloader",
"pass": "CHANGEME",
"token": "",
"matcher": ["client3-"],
"match": "any",
"removematch": true,
"disabled": false,
"noactions": false,
"clientname": "client3-"
},
....other clients...
]
In order to make sure that Asterisk performs the correct actions at the AMI level, you must specify a "clientname" for each client and use that string in the Asterisk dialplan (where it is returned under the variable "UNILOADER_CLIENT") in order to build the actual queue / agent / channel name to be used on Asterisk.
So you would edit the stanzas you want to use in ''extensions_queuemetrics.conf'' to use the client name, like e.g.:
; extension 37: agent removequeuemember with hotdesking (for asterisk v1.4+)
exten => 37,1,Answer
exten => 37,2,NoOp( "QM: RemoveQueueMember (asterisk v1.4+) Agent/${AGENTCODE}
at extension SIP/${QM_AGENT_LOGEXT} on queue ${QUEUENAME}
made by '${QM_LOGIN}' for '${UNILOADER_CLIENT}'" )
exten => 37,3,RemoveQueueMember(${UNILOADER_CLIENT}${QUEUENAME},SIP/${UNILOADER_CLIENT}${QM_AGENT_LOGEXT})
exten => 37,4,Hangup
So if this action is performed on "client3" removing extension "127" from queue "300", the actual action performed would be:
RemoveQueueMember(client3-300,SIP/client3-127)
That would produce a queue_log record like:
1487239051|1487239051.123|client3-300|SIP/client3-127|REMOVEMEMBER
But the splitter would then upload it to QueueMetrics as if it was:
1487239051|1487239051.123|300|SIP/127|REMOVEMEMBER
Because it would match the string "client3-" in both the queue and agent fields. This way each QueueMetrics-Live instance is blissfully unaware of the physical names for queues and agents that are used at the Asterisk level.
Also, as for some actions (chanspy and originate) QueueMetrics need to originate calls directly within your diaplan, you should edit the configuration.properties file so that channels where the client is required appear as:
callfile.monitoring.channel=SIP/$EM-!UNILOADER_CLIENT callfile.outmonitoring.channel=SIP/$EM-!UNILOADER_CLIENT callfile.customdial.channel=SIP/$EM-!UNILOADER_CLIENT
Multiple Asterisk instances, multiple QueueMetrics instances
If you have multiple Asterisk instances on which calls are processed, and calls for any client can be processed on each cluster member, you need to set up rewriting rules and create a cluster member (and related partition) on each destination QueueMetrics instance.
Make sure you use the "clientname" variable to have Asterisk perform the correct AMI calls.