SIP-kapacitetsmonitor
Et read-only monitoreringssystem, der omsætter levende kanaldata fra flere SBC'er til historik, rapporter og et konkret grundlag for kapacitetsplanlægning.
Visningen er anonymiseret. Virksomhedsidentitet, hostnames og trunk-identifikatorer er fjernet. Systemet er internt og kan derfor ikke åbnes som en offentlig demo.
Problemet
Installeret kapacitet fortæller, hvor mange kanaler der findes, men ikke hvordan de faktisk bliver brugt. Uden sammenhængende historik er det svært at se spidsbelastninger, sammenligne SBC'er og vurdere, om kapaciteten passer til det reelle behov.
Opgaven var derfor at hente de levende data uden at ændre noget på udstyret, gemme målingerne over tid og gøre dem anvendelige for både den daglige drift og den mere langsigtede planlægning.
Løsningen
Systemet starter en read-only collector for hver SBC. Collectoren logger ind med Playwright og læser den levende JavaScript-kanalmodel direkte. Den arbejder altså med strukturerede data, ikke skærmbilleder, OCR eller farver i brugerfladen.
Hver måling normaliseres og samles i en fælles SQLite-historik. Et separat dashboard og API viser den aktuelle situation og udviklingen over tid, mens en rapportfunktion kan eksportere kapacitetsstatistik som CSV.
En måling ad gangen
- Playwright åbner SBC'ens monitor og finder kanalmodellen på siden eller i dens frames.
- Kun de nødvendige kanal-, trunk- og kaldedata læses.
- Aktive kanaler, unikke kald, statusser og trunkforbrug beregnes.
- Et JSON-snapshot skrives atomisk, og de samlede værdier gemmes i SQLite.
- Dashboard, API og CSV-rapportering bruger den samme historiske datakilde.
Målinger, der kan forklares
Dashboardet skelner mellem aktive kanaler og unikke aktive kald, fordi ét kald kan bruge flere kanaler. For hver trunk vises blandt andet installeret kapacitet, aktuelt forbrug, peak, gennemsnit og P95.
En anbefalet kapacitet beregnes ud fra det observerede peak med en sikkerhedsmargin. En mulig reduktion bliver først vist, når historikken indeholder mindst 120 målinger fordelt over mindst tre dage. Det forhindrer en tynd datamængde i at ligne et sikkert beslutningsgrundlag.
En anbefaling er ikke en automatisk beslutning. Kontrakter, beredskab, vækst og krav til spidsbelastning skal stadig vurderes, før kapacitet ændres.
Robust indsamling
Hvis en måling fejler, fortsætter næste cyklus automatisk. Ved problemer med siden eller datamodellen forsøger collectoren først at genindlæse, derefter at logge ind igen og til sidst at oprette browsersiden på ny.
SQLite kører med WAL og timeout til samtidige collectors. Snapshots og dashboard-cache udskiftes atomisk, logfiler roteres, og en scheduled task starter processerne ved opstart og fungerer som watchdog mod manglende processer.
Et hurtigt dashboard med lang historik
Historiske beregninger kan være tunge. Derfor bruger API'et en stale-while-refresh-cache: den seneste brugbare visning returneres straks, mens opdateringen sker i baggrunden. Efter en genstart kan en diskcache levere data med det samme, og trendserier nedskaleres uden at miste det seneste punkt.
Bevidste grænser
- Systemet er afgrænset til et internt, betroet netværk.
- Det er et enkelt-host-design til let monitorering, ikke en distribueret dataplatform.
- Dataretention, backup og alarmering håndteres ikke automatisk.
- Kombinerede peaks afhænger af synkroniserede ure og regelmæssige målinger.
- Miljøspecifik konfiguration og følsomme driftsoplysninger er ikke en del af denne case.
Testpakken dækker blandt andet genbrug af en eksisterende browsersession, deduplikering af kald, trunknavne og kapacitet, undertrykkelse af anbefalinger uden tilstrækkelig baseline, live fallback-data og beskyttelse mod dobbelttælling af gentagne målinger.
Det vigtigste resultat er ikke én bestemt graf. Det er en dokumenteret kæde fra read-only kildedata til forklarlige målinger, som kan bruges uden at forveksle et estimat med et facit.
Har du tekniske data, der er svære at bruge?
Jeg bygger monitorering, rapportering og mindre interne systemer, der gør driftsdata lettere at forstå og handle på.