Orbit Project Analytics

Het tabblad Analytics geeft het volledige beeld van hoe een project zich gedraagt: hoe lang builds duren, hoe vaak ze slagen, hoeveel van je planminuten en bandbreedte het project gebruikt, en waar de tijd heengaat wanneer een build traag is.

Waar Analytics zich bevindt

Open Orbit, klik op het project en kies Analytics onder de groep Observability in het projecttabblad. De pagina heet Analytics en dekt buildprestaties, verkeer en implementatiefrequentie voor dit project.

Twee naast elkaar liggende tabbladen delen dezelfde gegevens op verschillende manieren. Build Insights richt zich op buildduurduur-percentielen en cacheverhalten, en Web Vitals behandelt echte gebruikersprestaties. Zie Orbit Build Insights en Orbit Web Vitals.

De samenvattingskaarten

Vijf kaarten staan aan de bovenkant:

Gebruik deze maand

Onder de kaarten is een paneel met als titel Gebruik deze maand, met je plannaam en duidelijk makend dat deze getallen account-breed zijn, niet per project. Twee meters worden weergegeven:

• Buildminuten, gebruikt tegen de maandelijkse toewijzing van je plan, met dit project's aandeel afzonderlijk aangegeven en de minuten die je nog hebt.
• Bandbreedte (origin), dezelfde vorm in gigabytes.

Als je een toewijzing overschrijdt, toont het paneel het overschot en wat het kost: buildminuten worden gefactureerd op US$0.05 per minuut en origin-bandbreedte op US$0.03 per GB, bovenop je plan.

Het projecteert ook vooruit tot het einde van de maand op basis van het huidige ritme, met een geschat overschot als je zo doorgaat. Die projectie is het nuttige getal, omdat het je over een probleem vertelt terwijl je er nog iets aan kunt doen.

Build Insights

Het blok Build Insights leest de gegevens en schrijft de observatie voor je, in duidelijke taal, in plaats van je het zelf in een diagram te laten opsporen. Wat verschijnt hangt af van wat waar is voor je project, bijvoorbeeld:

• Een uitspraak over het succespercentage, ofwel lof voor goede betrouwbaarheid of een herinnering om recente fouten na te gaan.
• Buildtijd omhoog of omlaag vergeleken met de vorige twee weken, met beide gemiddelden aangehaald.
• Een lage cache hit-ratio, met het aantal builds dat een warme cache gebruikte en een aansporing over het stabiel houden van de cachesleutel tussen commits.
• Maandagbuilds zijn langzamer, wat meestal betekent dat de cache over het weekend verloopt.
• De slechtst presterende branch naar succespercentage.
• Een gemiddelde wachtijd in de wachtrij van meer dan 90 seconden, wat betekent dat builds op een runner wachten.

Beschouw deze als aanknopingspunten, niet als uitspraken. Elk wijst naar een sectie verder naar beneden op de pagina met de onderliggende getallen.

Implementatiefrequentie, betrouwbaarheid en activiteit

Drie visualisaties behandelen cadence:

• Implementatiefrequentie: afgelopen 30 dagen toont implementaties per dag.
• Betrouwbaarheid: afgelopen 8 weken stapelt geslaagde tegen mislukte implementaties per week, met de trend tegen de vorige vier weken.
• Implementatieactiviteit: afgelopen jaar is een calenderheatmap, gearceerd naar volume en gekleurd naar of de implementaties van die dag slaagden.

De jaarheatmap is degene die je aan iemand laat zien die vraagt hoe actief een project is. Gaten en clusters zijn direct zichtbaar.

Buildprestatie

Buildprestatie toont de laatste run van geslaagde implementaties als balken, met gemiddelde en snelste buildtijd en de cache hit-ratio. Door over een balk te zweven zie je de branch en commit, en of die build de cache raakte.

Build time trend reduceert elke week tot zijn P50 en rapporteert of deze week sneller of langzamer is.

Build time percentiles geeft P50, P90 en P99. De voetnoot is het belangrijke deel: een lager P90 betekent consistentere builds. Als je P50 prima is maar je P90 is drie keer zo groot, zijn de meeste builds snel en gaat er af en toe iets ernstig mis, wat een ander probleem is dan uniform traag zijn.

Cache-efficiëntie

Het blok Cache efficiency vergelijkt koudebulls rechtstreeks met gesloten builds: de gemiddelde duur van elk, de totale tijd bespaard en de resulterende snelheidsverbetering.

Als het cached-gemiddelde nauwelijks beter is dan het koude gemiddelde, wordt de cache hersteld maar helpt het niet, meestal omdat de installatiestap niet het langzame gedeelte van je build is. Als de hit-ratio zelf laag is, wordt de cache te vaak ongeldig; een lockfile die bij elke commit verandert, zal dat doen.

Per-environment build stats splitst builds en cache hits uit naar productie, staging en preview, wat je erachter brengt dat previews het merendeel van je buildminuten doen.

Per-branch en per-auteur statistieken

Twee tabellen behandelen de afgelopen 30 dagen:

• Per-branch build stats: implementaties, succespercentage en gemiddelde buildtijd per branch.
• Per-author deploy stats: hetzelfde per persoon die duwde.

De per-branch tabel is de praktische. Een branch met een laag succespercentage is meestal een branch met een verbroken test of typcontrole die iedereen heeft leren negeren.

Wachtrijwacht en tijd van de dag

Build queue wait: afgelopen 14 dagen meet de kloof tussen een build in de wachtrij en een builder die het ophaalt. De voetnoot bepaalt de verwachting: onder vijf seconden is typisch, en pieken duiden op congestie.

Build time by hour: afgelopen 90 dagen is een weekdag-naar-uur-van-de-dag-heatmap in UTC, die aantoont wanneer je builds het langzaamst zijn, met cellen die minstens twee builds nodig hebben voordat ze gearceerd zijn. Gecombineerd met wachtrijwacht, vertelt het je of een langzame build jouw build is of een druk moment.

Oorzaken van falen

Mislukte implementaties in de afgelopen 30 dagen worden geclassificeerd naar oorzaak: compilatiefout, installatiefouten, testfout, lintfout, timeout, onvoldoende geheugen, netwerkfout of onbekend. Het gedeelte roept de topklasse en het percentage van je fouten op.

Dit is de snelste route van "onze builds blijven mislukken" naar een specifiek ding om op te lossen. Als twee derde van de fouten installatiefouten zijn, is het probleem afhankelijkheidsresolutie, niet je code. Troubleshooting Failed Builds behandelt wat je met elke klasse moet doen.

Artefactgrootte

Artifact size over time volgt hoe groot elke build-uitvoer is, gelabeld als groeiend, afnemend of stabiel, met de oudste en nieuwste grootte.

Een voortdurend groeiend artefact is het onderzoeken waard voordat het een langzame site wordt. De gebruikelijke verdachten zijn een beeldmap die niemand snoeit en een afhankelijkheid die iets enorms heeft ingevoerd.

Webanalytica

Het onderste gedeelte toont Core Web Vitals van echte bezoekers in de afgelopen 30 dagen, met toptalige's, landen, verwijzers en per-pagina p75-prestaties.

Als je het collectiefragment nog niet hebt toegevoegd, is dit gedeelte leeg en biedt een koppeling aan om het in te stellen. Zie Orbit Web Vitals voor het fragment en wat elke metriek betekent.

Waar je daarna heen gaat

• Orbit Build Insights voor percentielen en cachdetail.
• Orbit Spending Cap om een plafond op overschot in te stellen.
• Orbit Plan Limits voor wat je plan omvat.