Hallo,
wir haben immer mal wieder Fehler im Grafana mit “division by zero”. Dies tritt auf wenn Streams keine Daten senden (rtcpinfo_sentpackets = 0)?
Der Fehler tritt in “Call Quality Overview” und “Call flow” auf.
Im Inspector wird diese Meldung ausgegeben:
{ "results": { "A": { "error": "pq: division by zero", "refId": "A", "meta": { "sql": "SELECT\n rtcpinfo_sourcessrc as ssrc,\n stream as stream,\n max(rtcpinfo_sentpackets) as packets,\n max(rtcpinfo_cumulativelost) as lost,\n max(rtcpinfo_cumulativelost::float/rtcpinfo_sentpackets::float) as lost_ratio,\n max(rtcpinfo_iajitter) as jitter_max,\n avg(rtcpinfo_iajitter) as jitter_avg,\n max(rtcpinfo_rtt * 1000 ) as rtt_max,\n avg(rtcpinfo_rtt * 1000) as rtt_avg\nFROM rtcp\nWHERE \n rtcpinfo_chain = '1593515867195_232'\nGROUP BY ssrc,stream;" }, "series": null, "tables": null } }, "message": "pq: division by zero" }
Der Divisionsfehler lässt sich leicht abfangen indem ein AND rtcpinfo_sentpackets > 0 der WHERE-Bedingung angehangen wird, da dies aber ein System-Template ist kann es nicht gespeichert werden und müsste immer wieder manuell angepasst werden.
Ist das evtl. ein generelles Konfigurationsproblem der pascom oder darf das passieren?
Dies tritt hier bei ~10% aller Gespräche auf, in der “Call Quality Overview” ist eine Darstellung ohne manuelle Anpassung (Divisionsfehler) kaum möglich.
Edit: es sind doch deutlich mehr als 10%, schon eher jedes zweite Gespräch.
Hier sieht man zwei Streams mit SSRC=0 und keinen Paketen, daher auch der Divisionsfehler bei der Berechnung von
lost_ratio. Der Query hier ohne lost_ratio-Berechnung.
Edit 2: Hier mal ein Beispiel mit SSRC=0 und vorhandenen Paketen, der Standardquery liefert aber trotzdem “division by zero”.
Gruß,
Rapha