Orbit
Analyse de projet Orbit
The Analytics tab is the full picture of how a project is behaving: how long builds take, how often they succeed, how much of your plan's build minutes and bandwidth the project is using, and where…
L'onglet Analytics offre une vue complète du comportement d'un projet: durée des builds, fréquence de réussite, utilisation des minutes de build et de la bande passante du plan, et répartition du temps quand un build est lent.
Où se trouve Analytics
Ouvrez Orbit, cliquez sur le projet, et choisissez Analytics sous le groupe Observability dans la bande d'onglets du projet. La page s'intitule Analytics et couvre les performances des builds, le trafic et la fréquence de déploiement de ce projet.
Deux onglets adjacents découpent les mêmes données différemment. Build Insights se concentre sur les percentiles de durée des builds et le comportement du cache, et Web Vitals couvre les performances des utilisateurs réels. Voir Orbit Build Insights et Orbit Web Vitals.

Les cartes de résumé
Cinq cartes sont disposées en haut:
| Carte | Ce qu'elle compte |
|---|---|
| Minutes de build | Nombre total de minutes de build pour ce projet sur six mois |
| Requêtes d'origine | Requêtes qui ont atteint votre origine, soit les défauts de cache uniquement, sur six mois |
| Bande passante d'origine | Octets servis depuis l'origine sur six mois |
| Taux de réussite | Builds réussis par rapport aux builds terminés au total sur 30 jours |
| Temps économisé par le cache | Temps de build économisé par les accès au cache sur les 100 derniers builds |
Les requêtes d'origine et la bande passante d'origine sont exactement cela: l'origine uniquement. Tout ce qui est servi depuis le cache edge n'est pas compté ici, ce qui explique pourquoi un site très actif et bien en cache peut afficher des chiffres étonnamment petits. C'est le système qui fonctionne, pas une lacune du rapport.
Utilisation ce mois-ci
Sous les cartes se trouve un panneau intitulé Utilisation ce mois-ci, affichant le nom de votre plan et précisant que ces chiffres sont au niveau du compte, non par projet. Deux indicateurs sont affichés:
- Minutes de build, utilisées par rapport à l'allocation mensuelle de votre plan, avec la part de ce projet appelée séparément et les minutes qu'il vous reste.
- Bande passante (origine), de la même forme en gigaoctets.
Si vous dépassez une allocation, le panneau affiche le dépassement et ce qu'il coûte: les minutes de build facturent US$0.05 par minute et la bande passante d'origine US$0.03 par GB, en plus de votre plan.
Il projette également vers la fin du mois sur la base du taux jusqu'à présent, avec un dépassement estimé si vous continuez comme vous l'êtes. Cette projection est le chiffre utile, car elle vous signale un problème pendant que vous pouvez encore faire quelque chose.
Une boucle de build incontrôlée est le moyen classique de consommer une allocation. Un hook de déploiement relié à une tâche qui elle-même se déclenche au déploiement consommera volontiers des minutes toute la nuit. Si la projection augmente fortement, vérifiez l'onglet Déploiements pour un motif répétitif avant de supposer que votre trafic a augmenté. Un plafond de dépenses vous donne un arrêt dur: voir Orbit Spending Cap.
Build Insights
Le bloc Build Insights lit les données et vous écrit l'observation, en langage clair, plutôt que de vous laisser la repérer dans un graphique. Ce qui s'affiche dépend de ce qui est vrai de votre projet, par exemple:
- Une déclaration de taux de réussite, soit des félicitations pour une bonne fiabilité, soit une invitation à examiner les défaillances récentes.
- Temps de build en hausse ou en baisse par rapport à la quinzaine précédente, avec les deux moyennes citées.
- Un faible taux de coup de cache, avec le nombre de builds qui ont utilisé un cache chaud et une suggestion de garder la clé de cache stable entre les commits.
- Les builds du lundi étant plus lents, ce qui signifie généralement que le cache expire le week-end.
- La branche la moins performante en taux de réussite.
- Un temps d'attente moyen dans la file d'attente supérieur à 90 secondes, ce qui signifie que les builds attendent un runner.
Traitez celles-ci comme des pistes, non comme des verdicts. Chacune pointe vers une section plus bas sur la page avec les chiffres sous-jacents.
Fréquence de déploiement, fiabilité et activité
Trois visualisations couvrent le rythme:
- Fréquence de déploiement: derniers 30 jours affiche les déploiements par jour.
- Fiabilité: 8 dernières semaines empile les réussis contre les défaillances par semaine, avec la tendance par rapport aux quatre semaines précédentes.
- Activité de déploiement: année passée est une carte thermique calendaire, nuancée par volume et colorée selon que les déploiements du jour ont réussi.
La carte thermique de l'année est celle à montrer à quelqu'un qui demande à quel point un projet est actif. Les lacunes et les grappes sont visibles instantanément.
Performances des builds
Les Performances des builds affichent le dernier exécution des déploiements réussis sous forme de barres, avec le temps de build moyen et le plus rapide et le taux de coup de cache. Le survol d'une barre affiche la branche et le commit, et si ce build a touché le cache.
La Tendance du temps de build réduit chaque semaine à son P50 et indique si cette semaine est plus rapide ou plus lente.
Les Percentiles du temps de build donnent P50, P90 et P99. La note de bas de page est la partie importante: un P90 plus bas signifie des builds plus cohérents. Si votre P50 est correct mais que votre P90 le triple, la plupart des builds sont rapides et quelque chose tourne occasionnellement mal, ce qui est un problème différent d'être uniformément lent.
Efficacité du cache
Le bloc Efficacité du cache compare directement les builds froids aux builds en cache: la durée moyenne de chacun, le temps total économisé, et l'amélioration de vitesse qui en résulte.
Si la moyenne en cache est à peine meilleure que la moyenne froide, le cache est restauré mais n'aide pas, généralement parce que l'étape d'installation n'est pas la partie lente de votre build. Si le taux de coup lui-même est faible, le cache est invalidé trop souvent; un fichier de verrouillage qui change à chaque commit fera cela.
Les Statistiques de build par environnement décomposent les builds et les coups de cache par production, staging et preview, ce qui vous permet de découvrir que les aperçus consomment la plupart de vos minutes de build.
Statistiques par branche et par auteur
Deux tableaux couvrent les 30 derniers jours:
- Statistiques de build par branche: déploiements, taux de réussite et temps de build moyen par branche.
- Statistiques de déploiement par auteur: la même chose par la personne qui a poussé.
Le tableau par branche est celui pratique. Une branche avec un faible taux de réussite est généralement une branche avec un test ou une vérification de type cassés que tout le monde a appris à ignorer.
Attente dans la file d'attente et heure de la journée
L'Attente dans la file d'attente de build: 14 derniers jours mesure l'écart entre un build mis en file d'attente et un builder le reprenant. La note de bas de page fixe l'attente: moins de cinq secondes est typique, et les pics indiquent une contention.
Le Temps de build par heure: 90 derniers jours est une carte thermique jour de la semaine par heure de la journée en UTC, montrant quand vos builds sont les plus lents, avec les cellules nécessitant au moins deux builds avant qu'elles ne soient nuancées. Combiné avec l'attente dans la file d'attente, il vous indique si un build lent est votre build ou un moment chargé.
Causes des défaillances
Les déploiements défaillants au cours des 30 derniers jours sont classés par cause profonde: erreur de compilation, défaillance d'installation, défaillance du test, erreur de lint, dépassement du délai, dépassement de mémoire, erreur réseau ou inconnue. La section appelle la catégorie supérieure et quelle part de vos défaillances elle représente.
C'est l'itinéraire le plus rapide de "nos builds n'arrêtent pas d'échouer" à une chose spécifique à corriger. Si les deux tiers des défaillances sont des défaillances d'installation, le problème est la résolution des dépendances, pas votre code. Troubleshooting Failed Builds couvre ce qu'il faut faire avec chaque catégorie.
Taille des artefacts
La Taille des artefacts au fil du temps suit la taille de la sortie de chaque build, étiquetée en croissance, en diminution ou stable, avec les tailles les plus anciennes et les plus récentes.
Un artefact en croissance constante vaut la peine d'être examiné avant qu'il ne devienne un site lent. Les coupables habituels sont un répertoire d'images que personne n'élague et une dépendance qui a tiré quelque chose d'énorme.
Web Analytics
La section du bas affiche les Core Web Vitals des visiteurs réels au cours des 30 derniers jours, avec les pages principales, les pays, les référents et les performances p75 par page.
Si vous n'avez pas encore ajouté l'extrait de collection, cette section est vide et offre un lien pour le configurer. Voir Orbit Web Vitals pour l'extrait et ce que chaque métrique signifie.
Où aller ensuite
- Orbit Build Insights pour les percentiles et les détails du cache.
- Orbit Spending Cap pour placer un plafond sur le dépassement.
- Orbit Plan Limits pour savoir ce que votre plan inclut.