REST API / queue_log / Logging und Provisionierung eines Beronet-GW

Support
1

Hallo Zusammen,

ich beschäftige mich zur Zeit detailiert mit Mobydick und Asterisk, dabei sind mir bisher folgende Fragen aufgefallen:

  • Gibt für /var/log/asterisk/queue_log keinen logrotate?

  • Kann man die REST API mit eigenene Ansichten erweitern? Wenn ja, wie?

  • Werden beim Provisioning vom Beronet-Gateway deren Logging-Settings überschreiben? Wie konfiguriere ich das Logging beim Beronet-Gateway-Provisioning.

  • Welchen Username/Passwort verwendert Mobydick für Postgres?

Danke,
Sebastian

2

Hallo Sebastian,

  • das queuelog wird per default nicht rotiert. Je nach 3rd party Statisksystem (etwa Queuemetrics) kümmert sich gerne mal andere Software um diese Datei. Man kann jedoch in /etc/logrotate.d/ eine entsprechende Konfiguration vornehmen. Diese Änderung bleibt natürlich auch bei Updates erhalten.
  • die Frage mit der REST API verstehe ich nicht ganz. Was ist eine Ansicht? Die API ist dazu gedacht in eigenen Programmen benutzt zu werden, die Views im Browser sind nur für ein schnelles ausprobieren gedacht.
  • die Beronet Frage kann ich Dir leider nicht beantworten
  • die Postgres Credentials werden - so wie viele andere interne Passwörter - aus Sicherheitsgründen bei der Installation zufällig erzeugt. Das Postgres Schema sollte nicht durch Kunden angefasst werden. Viele unserer Daten stehen über die REST bzw. XMPP API’s zur Verfügung. Schreibzugriffe können über den Connector abgewickelt werden.

Gruß,

Thomas

3

Hallo Thomas,

danke für deine Hilfe.

Ich hatte mich wegen des queue_logs gewundert, weil ich mich da selbst draufsetzen möchte und die Datei auswerten mag. Ohne Rotate ist das dann etwas einfacher, aber ich fands wunderlich. Die Idee ist die queue_log per Deamon zu überfachen und Events auszuwerten und in eine Datenbank zu schreiben. Die DB würde ich dann gerne per REST anbieten, damit die Daten wohldefiniert extern weiter verarbeitet werden können. Ich könnte selbst eine REST-Schnittstelle schreiben, aber ich fände es schicker, wenn ich die vorhandene Schnittstelle irgendwie nutzen könnte. Den Begriff “Ansicht” habe ich verwendet, weil ich das in einem MVC-Schema gesehen habe.

Zufällige Passwörter gefallen mir, ich mag halt nur gerne auch auf die Daten zugreifen - das geht aber auch über sudo und den postgres-user.

Grüße,
Sebastian

4

Gern.
Bzgl. der queue: schau dir den queuemetrics loader in /var/queuemetrics/qloaderd/ ( http://manuals.loway.ch/QLoader-chunked/ ) an. Der liest das queuelog und klopft es geparst in eine remote mysql Datenbank. Vielleicht ist es das was Du selber bauen möchtest.

Das mit der wohldefinierten Form bei einem selbstgebauten REST Service ist nicht so leicht. Bei unseren API’s abstrahieren wir halt weg von der Datenbank damit wir diese fast beliebig zwischen den Releases verändern können ohne Integrationen kaputt zu machen. Es genügt eben nicht das Schema 1:1 zu veröffentlichen - genau deshalb ist es auch schlau nicht auf die DB zuzugreifen.

Mit dem postgres-user hast Du recht - jedoch **“Aus großer Macht folgt große Verantwortung” **:slight_smile:

5

Hi Thomas,

ich wusste gar nicht, dass queuemetrics mit euch ausgeliefert wird :confused:

Ich find QM nicht so schlau, weil ich lieber eine DB pflege als zwei und die Daten daher gerne in pg hätte. Davon abgesehen sieht mir das Script so aus, dass einfach “nur” die Logs in die Datenbank schreibt und hätte gerne pro Call-ID nur einen Eintrag. Das finde ich sauberer und dann habe ich relativ einfach die Möglichkeit mit MD bzw einem Asterisk-Script über eine Schnittstelle den geloggten Status eines Anrufs zu beeinflussen - dass z.B geloggt wird, wenn der Caller nach einer Warteschlange auf ein IVR-Menu abgeworfen wird und sich dort für eine automatische Rückrufbitte entscheidet.

Mit Hilfe eurer CDR-API eroffe ich dann irgendwann die Frage beantworten zu lassen, welche Rückrufe noch “offen” sind.

Da fällt mir ein: Kann ich die Nummer aus der Logdatei irgendwie von Mobydick oder Asterisk parsen lassen? Das wäre interessant, weil man dann das Ämter-Prefix halbwegs vernünftig verarbeitet bekommt und gut interne von externen Nummern unterscheiden kann, hab da aber auch noch nicht großartig nach gesucht, daher nur am Rande :slight_smile:

LG,
Sebastian

6

Hallo nochmal,

tatsächlich schreiben wir unter der Haube pro Call mindestens 2 Records, i.d.R. jedoch wesentlich mehr in die DB weg. Jeder “Hop”/Teilanruf eines Gespräches wird separat verbucht und mit einer weiteren “Chain-ID” verkettet. Man kann dadurch Weiterleitungsketten, gestaffelte Queues, Agenten-Rückfragen, IVR-Menüs etc. tracken. Leider gibt es dazu noch keine GUI. Du kannst auf die Daten per services/cdr zugreifen wenn Du den Query-Parameter “rawdata=1” und evtl. auch “chaindata=1” mit gibst. Alle weiteren Parameter sind mit der unter “Informationen-Rufauswertung” verfügbaren Filter kompatibel. Dort sind auch die Rufnummern schon geparst und mit intern/extern Flags sowie echten Usernamen versehen.

Gruß,

Thomas

7

Hallo Thomas,

“rawdata=1” gefällt mir! Danke! Ist der Befehl “stabil”?

“chaindata” hat in dem Datensatz, den ich hier zur Verfügung habe, keine Auswirkungen.

Sebastian

8

Ja, die API ist stabil.
Das verhalten von Chaindata erschließt sich erst wenn Du einen Filter setzt. Du kannst z.B. sagen: “ich will alle Gespräche die an eine bestimmte Person gingen” und bekommst dann aber auch alle vorherigen und nachfolgenden Stationen der selben Chain.

Thomas