Observabilité
Tu ne devrais pas avoir à ajouter un outil pour voir ce que fait ton projet.
Sortie de build, logs runtime, utilisation des ressources par conteneur, et coûts détaillés. Rien de tout cela n'est un module complémentaire à installer, un sidecar à configurer, ou un plan vers lequel passer. C'est actif parce que ton projet tourne.
Inclus. Il n'existe pas de palier observabilité.
En un seul endroit
Le projet, c'est là où tout s'additionne.
Un composant te renseigne sur lui-même. Un projet te dit ce que fait l'application : chaque composant, les bases de données et buckets qu'ils utilisent, les routes devant eux, et un chiffre unique pour ce que coûte l'ensemble ce mois-ci. Tu n'assembles pas cette vue toi-même. C'est la page sur laquelle tu étais déjà.
Intégré
Chaque partie rend compte d'elle-même.
Rien ici n'est un produit séparé. Ces vues font partie de chaque projet que tu déploies.
Sortie de build
Le log d'un déploiement au moment où il se produit, diffusé en flux plutôt qu'interrogé, et conservé avec le déploiement pour qu'un build échoué reste lisible ensuite.
Logs runtime
Ce que le composant affiche en ce moment, filtrable, sans ouvrir un shell ni attacher un agent.
Utilisation des ressources
CPU, mémoire et stockage par conteneur pendant son exécution, sur le même écran que la console et les commandes d'alimentation.
Coûts, détaillés
Depuis le début du mois et une projection, répartis par conteneur de base, réplicas supplémentaires, bande passante et domaines personnalisés, par composant et pour le projet dans son ensemble.
Activité
Qui a changé quoi, et quand. Déploiements, variables, membres, domaines. L'enregistrement existe que le changement vienne de la console, de l'API ou d'un assistant.
La carte du système
Ce qui est connecté à quoi, dessiné à partir du projet tel qu'il est réellement plutôt que d'un schéma que quelqu'un a dessiné une fois et n'a plus mis à jour.
Prévenu, pas découvert
Personne n'a besoin de surveiller un écran.
Une observabilité qui ne fonctionne que pendant que tu regardes n'est pas très utile. Les événements qui comptent te parviennent là où tu es.
- Un déploiement a réussi.
- Un déploiement a échoué.
- Une base de données a fini son provisionnement, ou a été supprimée.
- Un composant a été converti en hébergement statique.
- Ton solde est critiquement bas.
Ils arrivent dans la console et par e-mail, et ce sont les mêmes événements sur lesquels agit le plafond de dépenses.
Sur la feuille de route
L'analyse des visiteurs arrive, et n'est pas encore là.
Les pages vues, les référents et la provenance de tes utilisateurs sont en cours de construction, et rien de tout cela n'existe aujourd'hui. Nous préférons écrire cela ici plutôt que te laisser le découvrir après ton déploiement.
La périphérie compte les requêtes par app pour décider quand mettre à l'échelle, et ce compteur est conservé cinq minutes puis abandonné. Ce n'est pas un pipeline d'analyse déguisé sous un autre nom.
Nous ne fixerons pas de date avant que ce soit prêt.
Déploie quelque chose et regarde-le tourner.
Les logs, la répartition des coûts et la carte du système sont déjà là.