Sinnvolles Monitoring für VoIP PBX
Hallo,
ich habe mal ein Projekt / Auftrag, wo ich eine hosted PBX kontrollieren und den Usern helfen sollte.
Um nicht nur erst dann reagieren zu können, wenn Probleme schon aufgetreten sind, überlegen wir uns die Servertätigkeit umfassend auszuwerten.
Dafür stehen uns im Prinzip drei Möglichkeiten zur Verfügung:
- Wir sehen natürlich die Verbindungen auf dem WebGUI der PBX.
- auf dem Server Wireshark mitlaufen zu lassen und live SIP, SDP und RTP Traffic beobachten.
- Die Server-Syslog auf einem eigenen Syslog-Server sammeln und mit einer Splunk-Instanz sie live auswerten und den Traffic visualisieren.
Durch die Definition des Normalzustandes könnten wir Alerts festlegen die uns eventuell schneller erreichen als die Beschwerden der User.
Mit diesem "Anomaly"-based Monitoring möchten wir natürlich erreichen, dass
- wir die Fehler schneller entdecken als die User, die kleinen Fehler wohl erst gar nicht melden.
- wir für späteren Troubleshooting genügend Information haben
- wir diese Infrastrukture eventuell nicht nur für VoIP Support sondern eventuell auch als Security Monitoring einsetzen können. (Firewall- Visualisierung in Splunk)
Hat jemand Praxiserfahrungen mit ähnlichen Szenarien? Ich muss natürlich zwischen Aufwand und Ergebnis abwegen. Was bringt es Logs zu sammeln, wenn ich es im Alltag erst gar nicht schaffe sie allein zu sammeln, auswerten und die Probleme zu lösen?
Was für Aufwand empfiehlt für eine Person, wenn es schnell, effezient und trotzdem strukturiert sein soll?
Vielen Dank für eure Feedbacks.
Gr. I.
ich habe mal ein Projekt / Auftrag, wo ich eine hosted PBX kontrollieren und den Usern helfen sollte.
Um nicht nur erst dann reagieren zu können, wenn Probleme schon aufgetreten sind, überlegen wir uns die Servertätigkeit umfassend auszuwerten.
Dafür stehen uns im Prinzip drei Möglichkeiten zur Verfügung:
- Wir sehen natürlich die Verbindungen auf dem WebGUI der PBX.
- auf dem Server Wireshark mitlaufen zu lassen und live SIP, SDP und RTP Traffic beobachten.
- Die Server-Syslog auf einem eigenen Syslog-Server sammeln und mit einer Splunk-Instanz sie live auswerten und den Traffic visualisieren.
Durch die Definition des Normalzustandes könnten wir Alerts festlegen die uns eventuell schneller erreichen als die Beschwerden der User.
Mit diesem "Anomaly"-based Monitoring möchten wir natürlich erreichen, dass
- wir die Fehler schneller entdecken als die User, die kleinen Fehler wohl erst gar nicht melden.
- wir für späteren Troubleshooting genügend Information haben
- wir diese Infrastrukture eventuell nicht nur für VoIP Support sondern eventuell auch als Security Monitoring einsetzen können. (Firewall- Visualisierung in Splunk)
Hat jemand Praxiserfahrungen mit ähnlichen Szenarien? Ich muss natürlich zwischen Aufwand und Ergebnis abwegen. Was bringt es Logs zu sammeln, wenn ich es im Alltag erst gar nicht schaffe sie allein zu sammeln, auswerten und die Probleme zu lösen?
Was für Aufwand empfiehlt für eine Person, wenn es schnell, effezient und trotzdem strukturiert sein soll?
Vielen Dank für eure Feedbacks.
Gr. I.
Please also mark the comments that contributed to the solution of the article
Content-ID: 285958
Url: https://administrator.de/forum/sinnvolles-monitoring-fuer-voip-pbx-285958.html
Printed on: May 12, 2025 at 19:05 o'clock
2 Comments
Latest comment
Ich betreue VoIP-Server, wo mehrere tausend User angemeldet sind.
Diese melden sich in der Regel dann, wenn etwas nicht korrekt eingerichtet wurde und sie das Telefon daher noch garnicht nutzen konnten.
Wenn es einmal mit Sinn und Verstand eingerichtet ist, läuft es üblicherweise sehr flauschig.
Was wir auf den VoIP-Servern machen ist, dass bestimmte Probleme automatisch durch die Software (Asterisk) erkannt und protokolliert werden.
Es kann z.B. passieren, dass man ausgehende Anrufe nicht durch ein PSTN-Gateway bekommt - dann muss das halt automatisch auf ein anderes Failovern und einen gut sichtbaren Eintrag im Log hinterlassen. Dann dauert der Rufaufbau ungewöhnlich lang, aber die meisten Nutzer denken sich garnichts dabei.
Ein Indiz für schlechte Übertragungsqualität ist, wenn Verbindungen nach kurzer Verbindungsdauer getrennt werden und sofort danach wieder die selbe Nummer angerufen wird. In dem Fall kann der zweite Anruf über ein anderes PSTN-Gateway geschickt werden. Passiert das zu häufig, wird das schlechte PSTN-Gateway deaktiviert und - du ahnst es - ein Eintrag im Log hinterlassen.
Ebenso kann man die Registrierung der Telefone/VoIP-Clients überwachen und Alarm geben, wenn Telefone nicht mehr registriert sind obwohl man erwartet dass sie angemeldet sein müssten.
Damit sind über 90% aller möglichen Probleme erschlagen - die restlichen Probleme sind so speziell, dass eine Auswertung per Wireshark nicht nur rechtlich extrem problematisch ist (§ 88 TKG) sondern auch unnötig auffändig.
Für viele Dinge, die man auswerten will, bieten die VoIP-Server in der Regel selbst genügend Daten um es auswerten zu können.
Diese melden sich in der Regel dann, wenn etwas nicht korrekt eingerichtet wurde und sie das Telefon daher noch garnicht nutzen konnten.
Wenn es einmal mit Sinn und Verstand eingerichtet ist, läuft es üblicherweise sehr flauschig.
Was wir auf den VoIP-Servern machen ist, dass bestimmte Probleme automatisch durch die Software (Asterisk) erkannt und protokolliert werden.
Es kann z.B. passieren, dass man ausgehende Anrufe nicht durch ein PSTN-Gateway bekommt - dann muss das halt automatisch auf ein anderes Failovern und einen gut sichtbaren Eintrag im Log hinterlassen. Dann dauert der Rufaufbau ungewöhnlich lang, aber die meisten Nutzer denken sich garnichts dabei.
Ein Indiz für schlechte Übertragungsqualität ist, wenn Verbindungen nach kurzer Verbindungsdauer getrennt werden und sofort danach wieder die selbe Nummer angerufen wird. In dem Fall kann der zweite Anruf über ein anderes PSTN-Gateway geschickt werden. Passiert das zu häufig, wird das schlechte PSTN-Gateway deaktiviert und - du ahnst es - ein Eintrag im Log hinterlassen.
Ebenso kann man die Registrierung der Telefone/VoIP-Clients überwachen und Alarm geben, wenn Telefone nicht mehr registriert sind obwohl man erwartet dass sie angemeldet sein müssten.
Damit sind über 90% aller möglichen Probleme erschlagen - die restlichen Probleme sind so speziell, dass eine Auswertung per Wireshark nicht nur rechtlich extrem problematisch ist (§ 88 TKG) sondern auch unnötig auffändig.
Für viele Dinge, die man auswerten will, bieten die VoIP-Server in der Regel selbst genügend Daten um es auswerten zu können.