Orbit Projektanalysen

Das Analytics-Tab ist das Gesamtbild davon, wie sich ein Projekt verhält: wie lange Builds dauern, wie oft sie erfolgreich sind, wie viel der Build-Minuten und Bandbreite deines Plans das Projekt nutzt, und wo die Zeit vergeht, wenn ein Build langsam ist.

Wo Analytics zu finden ist

Öffne Orbit, klicke auf das Projekt, und wähle Analytics unter der Gruppe Observability in der Projektregisterkarte. Die Seite trägt den Titel Analytics und zeigt Build-Performance, Traffic und Deploy-Häufigkeit für dieses Projekt.

Zwei benachbarte Registerkarten unterteilen dieselben Daten unterschiedlich. Build Insights konzentriert sich auf Build-Dauer-Perzentile und Cache-Verhalten, und Web Vitals behandelt die Performance echter Nutzer. Siehe Orbit Build Insights und Orbit Web Vitals.

Die Zusammenfassungskarten

Fünf Karten sitzen oben:

Nutzung diesen Monat

Unter den Karten befindet sich ein Panel mit dem Titel Nutzung diesen Monat, das deinen Plannamen anzeigt und klarmacht, dass diese Zahlen kontogebunden sind, nicht pro Projekt. Zwei Messer werden angezeigt:

• Build-Minuten, verbrauch gegen das monatliche Kontingent deines Plans, mit dem Anteil dieses Projekts separat aufgeführt und den verbleibenden Minuten.
• Bandbreite (Origin), die gleiche Form in Gigabyte.

Wenn du ein Kontingent überschreitest, zeigt das Panel die Überkapazität und was sie kostet: Build-Minuten werden mit US$0.05 pro Minute und Origin-Bandbreite mit US$0.03 pro GB berechnet, zusätzlich zu deinem Plan.

Es projiziert auch voraus bis zum Ende des Monats basierend auf der bisherigen Rate, mit einer geschätzten Überkapazität, falls du so weitermachst. Diese Projektion ist die aussagekräftige Zahl, denn sie informiert dich über ein Problem, während du noch etwas dagegen tun kannst.

Build Insights

Der Block Build Insights liest die Daten und schreibt die Beobachtung für dich in einfacher Sprache auf, anstatt dich ein Diagramm selbst durchsuchen zu lassen. Das Angezeigte hängt davon ab, was für dein Projekt wahr ist, zum Beispiel:

• Eine Aussage zur Erfolgsquote, entweder ein Lob für gute Zuverlässigkeit oder ein Hinweis zur Überprüfung neuer Fehler.
• Build-Zeit nach oben oder unten im Vergleich zur vorherigen vierzehn Tage, mit beiden Durchschnitten zitiert.
• Eine niedrige Cache-Hit-Rate mit der Anzahl der Builds, die einen warmen Cache nutzten, und ein Hinweis auf die Stabilität des Cache-Schlüssels zwischen Commits.
• Montag-Builds sind langsamer, was normalerweise bedeutet, dass der Cache übers Wochenende abläuft.
• Der am schlechtesten abschneidende Branch nach Erfolgsquote.
• Ein durchschnittlicher Queue-Wait über 90 Sekunden, was bedeutet, dass Builds auf einen Runner warten.

Behandle diese als Anhaltspunkte, nicht als Verdikt. Jedes verweist auf einen Abschnitt weiter unten auf der Seite mit den zugrunde liegenden Zahlen.

Deploy-Häufigkeit, Zuverlässigkeit und Aktivität

Drei Visualisierungen decken die Kadenz ab:

• Deploy-Häufigkeit: letzte 30 Tage zeigt Deploys pro Tag.
• Zuverlässigkeit: letzte 8 Wochen stapelt erfolgreich gegen fehlgeschlagen pro Woche, mit dem Trend gegen die vorherigen vier Wochen.
• Deploy-Aktivität: das letzte Jahr ist eine Kalender-Heatmap, abgestuft nach Volumen und eingefärbt, ob die Deploys des Tages erfolgreich waren.

Die Jahres-Heatmap ist diejenige, um sie jemandem zu zeigen, der fragt, wie aktiv ein Projekt ist. Lücken und Cluster sind sofort sichtbar.

Build-Performance

Build-Performance zeigt die letzte erfolgreiche Deployment als Balken, mit durchschnittlicher und schnellster Build-Zeit und der Cache-Hit-Rate. Das Darüberfahren mit einem Balken zeigt den Branch und Commit, und ob dieser Build den Cache getroffen hat.

Build-Zeit-Trend reduziert jede Woche auf sein P50 und meldet, ob diese Woche schneller oder langsamer ist.

Build-Zeit-Perzentile gibt P50, P90 und P99. Die Fußnote ist der wichtigste Teil: ein niedrigeres P90 bedeutet konsistentere Builds. Wenn dein P50 in Ordnung ist, aber dein P90 ist dreimal so groß, sind die meisten Builds schnell und etwas läuft gelegentlich schief, das ist ein anderes Problem als gleichmäßig langsam zu sein.

Cache-Effizienz

Der Block Cache-Effizienz vergleicht Cold Builds direkt mit gecachten Builds: die durchschnittliche Dauer von jedem, die gesamte gesparte Zeit und die resultierende Geschwindigkeitsverbesserung.

Wenn der gecachte Durchschnitt kaum besser ist als der Cold-Durchschnitt, wird der Cache wiederhergestellt, aber hilft nicht, normalerweise weil der Install-Schritt nicht der langsame Teil deines Builds ist. Wenn die Hit-Rate selbst niedrig ist, wird der Cache zu oft ungültig gemacht; eine Lockdatei, die sich bei jedem Commit ändert, wird das tun.

Per-Environment-Build-Stats unterteilt Builds und Cache-Hits nach Production, Staging und Preview, wo du herausfindest, dass Previews die meisten deiner Build-Minuten verursachen.

Per-Branch und Per-Author Stats

Zwei Tabellen behandeln die letzten 30 Tage:

• Per-Branch-Build-Stats: Deploys, Erfolgsquote und durchschnittliche Build-Zeit nach Branch.
• Per-Author-Deploy-Stats: das gleiche nach der Person, die gepusht hat.

Die Per-Branch-Tabelle ist die praktische. Ein Branch mit einer niedrigen Erfolgsquote ist normalerweise ein Branch mit einem fehlgeschlagenen Test oder Typ-Check, den alle zu ignorieren gelernt haben.

Queue Wait und Tageszeit

Build-Queue-Wait: letzte 14 Tage misst die Lücke zwischen einem Build, der in die Queue eingereiht wird, und einem Builder, der ihn aufgreift. Die Fußnote setzt die Erwartung: unter fünf Sekunden ist typisch, und Spitzen zeigen Konflikt an.

Build-Zeit nach Stunde: letzte 90 Tage ist eine Wochentag-nach-Stunde-des-Tages-Heatmap in UTC, die zeigt, wenn deine Builds am langsamsten sind, wobei Zellen mindestens zwei Builds benötigen, bevor sie abgestuft werden. In Kombination mit Queue Wait sagt es dir, ob ein langsamer Build dein Build oder ein beschäftigter Moment ist.

Fehlerursachen

Fehlgeschlagene Deployments in den letzten 30 Tagen werden nach Grundursache klassifiziert: Compilefehler, Installfehler, Testfehler, Lint-Fehler, Timeout, unzureichend Speicher, Netzwerkfehler oder unbekannt. Der Abschnitt hebt die oberste Kategorie hervor und wie viel deiner Fehler sie ausmacht.

Dies ist der schnellste Weg von "unsere Builds schlagen immer fehl" zu einer spezifischen Sache zum Beheben. Wenn zwei Drittel der Fehler Installfehler sind, ist das Problem die Abhängigkeitsauflösung, nicht dein Code. Troubleshooting Failed Builds behandelt, was mit jeder Kategorie zu tun ist.

Artefaktgröße

Artefaktgröße über Zeit verfolgt, wie groß die Ausgabe jedes Builds ist, gekennzeichnet als wachsend, schrumpfend oder stabil, mit den ältesten und neuesten Größen.

Ein stetig wachsendes Artefakt ist der Untersuchung wert, bevor es eine langsame Site wird. Die üblichen Verdächtigen sind ein Bilderverzeichnis, das niemand aufräumt, und eine Abhängigkeit, die etwas Enormes hinzugezogen hat.

Web-Analysen

Der untere Abschnitt zeigt Core Web Vitals von echten Besuchern in den letzten 30 Tagen, mit Top-Seiten, Ländern, Referrern und Per-Seite-P75-Performance.

Wenn du das Collection-Snippet noch nicht hinzugefügt hast, ist dieser Abschnitt leer und bietet einen Link zum Einrichten. Siehe Orbit Web Vitals für das Snippet und was jede Metrik bedeutet.

Wo es als nächstes hingehen soll

• Orbit Build Insights für Perzentile und Cache-Details.
• Orbit Spending Cap, um eine Obergrenze für Überkapazität zu setzen.
• Orbit Plan Limits für das, was dein Plan beinhaltet.