Es gibt ein Callcenter. Es gibt Asterisk / FreePBX mit konfigurierten Warteschlangen. Es gibt Agenten, die Anrufe bedienen sollten. Aber es gibt so viele potenzielle Kunden und es gibt so wenige Agenten, dass die ersteren die letzteren in keiner Weise erreichen können - sie hängen, sie hängen eine Minute in der Schlange und sie schalten sich aus.Aber aus irgendeinem Grund haben sie angerufen! Vielleicht wollen sie Geld in die Firma bringen? Versuchen wir, anhand des FreePBX-Beispiels sowohl Kunden als auch deren Geld zurückzugeben.In den Warteschlangeneinstellungen können Sie das Failover-Ziel angeben - wohin der Anruf gesendet werden soll, wenn die Warteschlange voll ist, die Zeitüberschreitung abgelaufen ist usw. Es kommt jedoch häufig vor, dass der Anrufer die Verbindung trennt, bevor er zum Failover-Ziel umgeleitet werden kann. Sie wissen nie, dass die Verbindung unterbrochen wurde. Für solche Fälle gibt es keine fertige Lösung. Deshalb gehen wir unter den Schnitt und schreiben Ihre eigenen - mit dem Senden einer Warnung an Telegramm / Slack / E-Mail / woanders.Und das erste, was wir verstehen müssen, ist, wie FreePBX Warteschlangenprotokolle schreibt. Im einfachsten Fall ist dies die Textdatei / var / log / asterisk / queue_log.Daher wird ein regelmäßiger Anruf vom Teilnehmer 8964467XXXXX in das Protokoll geschrieben, der 302221XXXX anrief und sich in Zeile 603 an der ersten Position befindet, die Agent Girl 8 Sekunden später beantwortete. Sie sprachen 133 Sekunden und der Abonnent war der erste, der auflegte - jeder würde so höfliche Manager haben!1584318765|1584318747.89449|603|NONE|DID|302221
1584318765|1584318747.89449|603|NONE|ENTERQUEUE||8964467|1
1584318774|1584318747.89449|603|Agent Girl|CONNECT|9|1584318765.89450|8
1584318907|1584318747.89449|603|Agent Girl|COMPLETECALLER|9|133|1
Und hier ist eine etwas andere Geschichte, als ein Teilnehmer 8996453XXXXX 302257XXXXX anrief, 10 Sekunden in Zeile Nr. 210 an der ersten Position hing und die Verbindung trennte. Ich habe nicht einmal das Sprachmenü gehört!1581728710|1581728690.59367|210|NONE|DID|302257
1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453|1
1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10
Das ist über ihn, wir werden in den Boten schreiben.Dazu müssen wir das Auftreten des ABANDON-Ereignisses in der Protokolldatei abfangen. Ich habe lange gerätselt, wie das geht, aber dann bin ich ganz zufällig auf ein wunderbares Werkzeug gestoßen - MONIT . In unserem Fall wird das Warteschlangenprotokoll überwacht, und sobald die Zeile "ABANDON" darin angezeigt wird, wird das Skript zur Verarbeitung dieses Ereignisses aufgerufen.Gehen Sie dazu nach der Installation des Pakets folgendermaßen vor:yum install monit
Richten Sie es ein - erstellen Sie die Datei /etc/monit.d/queue_log und schreiben Sie buchstäblich drei Zeilen hinein:check file queue_log with path /var/log/asterisk/queue_log
if content = "ABANDON" then
exec "/var/lib/asterisk/agi-bin/qlogevent.sh $EVENT"
Wenn also das Wort "ABANDON" im Warteschlangenprotokoll erscheint, das uns auffordert, den Abonnenten vorzeitig zu trennen, wird das Skript /var/lib/asterisk/agi-bin/qlogevent.sh mit dem Parameter $ EVENT aufgerufen, was nichts anderes als vollständig ist die Zeile, in der dieses Wort erschien.Das ist einfach.Und jetzt beginnt nicht mehr Schach - Sie müssen darüber nachdenken.Die an das Skript übergebene Zeile enthält keine Informationen zur Nummer des Anrufers:1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10
Es enthält nur den Zeitstempel (1581728720), eine eindeutige Anruf-ID (1581728690.59367), eine Warteschlangennummer (210), das Ereignis selbst und einige andere nicht wesentliche Parameter. Jene. Wir müssen selbst nach der Teilnehmernummer suchen. Und auf welche Weise? Und es ist sehr einfach, weil wir eine UID eines Anrufs haben!Wenden wir uns noch einmal dem Protokoll dieses Anrufs zu, insbesondere der Zeile, in der der Teilnehmer in die Warteschlange fällt:1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453|1
Wenn das Ereignis „ENTERQUEUE“ auftritt, ist einer der Parameter die benötigte Teilnehmernummer. Wir können diese Zeile nur in der Datei queue_log finden. Genau das macht das Bash-Skript, das MONIT sorgfältig für uns aufgerufen hat:#!/bin/bash
timedate=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2 | gawk '{print strftime("%d.%m.%Y %H:%M:%S",$0);}')
call_id=$(echo $MONIT_DESCRIPTION | cut -d\| -f2)
qnum=$(echo $MONIT_DESCRIPTION | cut -d\| -f3)
case $qnum in
210)
qname=" 1"
;;
220)
qname=" 2"
;;
esac
str=$(grep "|$call_id|$qnum|.*|ENTERQUEUE" /var/log/asterisk/queue_log)
caller_id=$(echo $str | cut -d\| -f7)
time_enter=$(echo $str | cut -d\| -f1)
time_abandon=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2)
data=" $caller_id $timedate $qname, $(($time_abandon-$time_enter)) ."
/usr/bin/curl -X POST -H 'Content-type: application/json' --data '{"text":"'"$data"'"}' "https://hooks.slack.com/services/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Eigentlich ist das alles!Es stimmt, es gibt einen Vorfall - MONIT, der alles und jeden überwachen soll, und selbst muss überwacht werden, weil fällt regelmäßig.