Développer une application web qui affiche en direct les journaux et mesures de conteneurs

## Rédiger des revues brèves qui ne signalent que bugs et blocages Utilisez un mode très concis pour les révisions de demandes de modification et les réponses du responsable de maintenance. Ne signalez que les erreurs, les problèmes de sécurité et les blocages. Employez des listes courtes, ajoutez des références `file:line` lorsque cela est pertinent, omettez les sections telles que Points forts ou Résumé, et limitez l’ensemble de la réponse à environ 10 à 15 lignes. Écrivez comme un responsable de maintenance humain. N’utilisez ni tirets cadratins ni demi-cadratins, ni oppositions rhétoriques du type « pas X, mais Y », ni éloges introductifs creux, ni récapitulatifs finaux, ni libellés en gras au milieu d’un paragraphe, ni précautions de langage vides. Les minuscules informelles et les formes contractées sont acceptables. Indiquez la décision, donnez une raison et arrêtez-vous. ## Faire tester le correctif par l’auteur du signalement à partir du build de la demande de modification Lorsqu’un problème signalé est corrigé dans une demande de modification ouverte, demandez à son auteur de tester l’artefact d’intégration continue créé pour cette demande. Donnez la référence exacte de l’image ou du paquet précompilé en utilisant un modèle générique tel que `{registry}/{image}:change-{number}`. L’auteur du signalement peut ainsi vérifier le correctif avant la prochaine version. Avant de recommander cette méthode, confirmez que l’automatisation publie effectivement un artefact étiqueté pour chaque demande de modification. ## Comprendre les couches serveur et interface avant de modifier Considérez le système comme une partie serveur HTTP compilée associée à une interface monopage typée. La partie serveur gère le routage, l’authentification, les clients de conteneurs ou de charges de travail, les flux de journaux et de mesures en direct, les actions, les notifications et la communication avec les agents distants. L’interface gère les vues fondées sur des fichiers, les composants réutilisables, les gestionnaires d’état réactifs, les fonctions composables de diffusion, le routage, la localisation et les préférences des utilisateurs. Prenez explicitement en charge chaque mode de déploiement documenté, notamment le service autonome ou à plusieurs hôtes, l’orchestration en grappe et le fonctionnement par agents distants. Ne supposez pas qu’une modification fonctionnant avec une mise en œuvre de client fonctionnera avec toutes les parties serveur. Gardez claire la direction principale des dépendances : `HTTP handlers -> host service -> per-host service -> domain client -> runtime implementation`. ## Construire et tester avec les cibles documentées Configurez le projet en installant les dépendances et en exécutant la cible de génération des certificats, des schémas ou du code de protocole. Utilisez la tâche de développement complète pour coordonner le rechargement à chaud de la partie serveur et de l’interface, ou exécutez séparément les deux processus de surveillance lorsque vous isolez un problème. Construisez les ressources de l’interface avant de les intégrer dans une construction complète de la partie serveur. Conservez des cibles distinctes pour le paquet de distribution de l’interface, l’application entière et l’image déployable. Utilisez la cible d’aperçu pour examiner localement une construction proche de la production. Exécutez les tests de la partie serveur, les tests unitaires de l’interface, la vérification des types et les tests d’intégration dans le navigateur au moyen de leurs cibles documentées. Utilisez `TZ=UTC` pour les tests de l’interface sensibles aux horodatages et réservez le mode de surveillance au travail local itératif. ## Séparer les couches de la partie serveur derrière une interface client commune Maintenez le routage HTTP et les gestionnaires de diffusion au-dessus des services d’hôte et de client. Placez les opérations propres à l’environnement d’exécution derrière une interface partagée de client de domaine, puis mettez en œuvre cette interface pour chaque partie serveur de conteneur, de grappe ou d’agent distant prise en charge. Séparez des gestionnaires de transport les fournisseurs d’authentification, les modèles de domaine, l’analyse des événements, l’évaluation des notifications et leur envoi. Conservez l’analyse de la ligne de commande et l’orchestration de plusieurs hôtes dans les couches de prise en charge plutôt que de les dupliquer dans les gestionnaires. Pour une nouvelle opération sur une charge de travail, mettez à jour l’interface de client de domaine, chaque mise en œuvre d’environnement applicable, l’enveloppe du service par hôte et le gestionnaire HTTP avec sa route. Ne contournez pas une couche dans le seul but de faire fonctionner un mode de déploiement. ## Garder l’état et les types d’entrée de journal de l’interface dans leur rôle Conservez les vues de route, les composants importés automatiquement, les gestionnaires d’état réactifs, les fonctions composables de diffusion et les modules d’extension de l’application dans leurs rôles établis. Considérez comme immuable la configuration injectée par le HTML rendu côté serveur. Placez les préférences persistantes derrière une abstraction de stockage réactive. Représentez le texte sur une ligne, les objets structurés et les messages multilignes regroupés par des types d’entrée de journal distincts. Utilisez l’alias de message partagé plutôt que de répéter un type d’union, et créez les entrées au moyen d’une fabrique qui choisit le type approprié pour chaque événement. Les composants réutilisés lors des changements de route ou de charge de travail doivent actualiser tout l’état dérivé. Si un graphique optimise les mises à jour en ne modifiant que sa dernière barre, exposez une méthode de recalcul complet et appelez-la lorsque toute la série de données est remplacée. ## Respecter les limites fixes des flux de journaux et de mesures Utilisez des événements envoyés par le serveur pour les flux de journaux, d’événements de cycle de vie et de mesures, ainsi que des connexions WebSocket pour les sessions interactives d’attachement ou d’exécution. Envoyez les actions qui modifient l’état d’une charge de travail au moyen de requêtes HTTP explicites, et non par des flux en lecture seule. Conservez les événements entrants de l’interface dans une mémoire tampon pendant 250 millisecondes, mais videz-la après 1 000 millisecondes au maximum. Regroupez les mises à jour réactives et, lorsque les messages affichés dépassent 400 entrées, remplacez ou marquez les entrées les plus anciennes conformément aux règles de la visionneuse. Conservez l’historique des mesures dans une fenêtre glissante de 300 éléments au maximum. Lissez les mesures avec une moyenne mobile exponentielle d’alpha 0,2, normalisez les valeurs de processeur selon le nombre de cœurs autorisé ou celui de l’hôte, et gardez séparées les valeurs de mémoire en pourcentage et en valeur absolue. Réduisez l’échantillonnage des graphiques en fonction de la largeur d’affichage disponible. Le remplacement complet d’une série de données, par exemple lors d’un changement de charge de travail, doit déclencher un recalcul complet même si les mises à jour ordinaires ne modifient que la dernière barre. ## Traiter séparément chaque mode de connexion et de déploiement Prenez en charge comme modes distincts l’absence d’authentification, l’authentification par fichier local et l’authentification par mandataire direct. Utilisez des justificatifs signés assortis d’une date d’expiration pour l’authentification locale, validez le fichier d’utilisateurs configuré et maintenez l’autorisation fondée sur les rôles indépendante du fournisseur d’identité. En mode autonome, combinez les clients locaux et distants au moyen d’un gestionnaire capable de réessayer. En mode grappe, découvrez les nœuds par l’API d’orchestration et connectez-vous à un agent sur chaque nœud. En mode natif de la grappe, mettez en œuvre la même interface de client de domaine au moyen de l’API de cette plateforme. En mode agent distant, exigez un transport authentifié par certificat. Conservez la sélection du mode au point d’entrée de l’application. Une fonction reste incomplète tant que son comportement n’est pas défini pour tous les modes applicables ou explicitement refusé dans les modes non pris en charge. ## Ajouter les nouvelles fonctions dans toutes les couches concernées Pour une nouvelle route HTTP, enregistrez la route, mettez en œuvre son gestionnaire, résolvez la cible par le service d’hôte et renvoyez des données structurées ou établissez le flux prévu. Pour une nouvelle vue de journaux, ajoutez la vue de route, créez une fonction composable de diffusion, construisez l’URL de l’API avec les filtres appropriés, gérez la mémoire tampon, renvoyez des messages et des commandes réactifs, puis réutilisez la visionneuse existante. Pour une nouvelle mesure, étendez le type de statistique de la partie serveur, extrayez et calculez la valeur, mettez à jour le schéma de protocole, régénérez le code de protocole et exposez le champ dans le modèle de l’interface lorsque celle-ci en a besoin. Les flux d’événements existants doivent transporter la mise à jour sans ajouter un transport parallèle. Pour un nouveau canal de notification, mettez en œuvre l’interface du répartiteur, enregistrez-la dans la fabrique de répartiteurs, ajoutez son formulaire de configuration et préservez le comportement persistant des règles et de l’état des alertes. ## Limiter les appels d’outils distants et ne réessayer que les pannes passagères Ne vous connectez pas tant qu’un répartiteur distant n’est pas configuré. Utilisez un flux bidirectionnel pour découvrir et appeler les outils, répartissez les appels au moyen d’un registre unique et limitez à cinq les exécutions simultanées avec un sémaphore pondéré. Après une défaillance transitoire, reconnectez-vous avec une attente exponentielle de 1 à 30 secondes assortie d’une variation aléatoire. Cessez définitivement les nouvelles tentatives lorsqu’une réponse de refus d’autorisation indique des justificatifs non valides ou une offre indisponible. Mettez en cache une seule fois les définitions d’outils immuables afin que la désactivation du fonctionnement distant n’ajoute qu’un surcoût négligeable. Pour ajouter un outil, définissez son nom, sa description et son schéma de paramètres ; ajoutez son type de réponse à l’union de résultats du protocole ; régénérez le code de protocole ; enregistrez le cas de répartition ; mettez-le en œuvre derrière l’interface du service d’hôte ; et ajoutez des tests ciblés. ## Classer chaque événement de journal et le diffuser sans l’accumuler en mémoire Analysez les flux multiplexés de l’environnement d’exécution en lisant leurs en-têtes et leurs charges utiles, puis classez chaque événement brut comme données structurées, événement multiligne regroupé ou événement sur une ligne. Extrayez la gravité au moyen de motifs explicites, sérialisez l’événement de domaine et livrez-le par le flux en direct. Pour les agents distants, traduisez les appels du client de domaine en requêtes de protocole, déléguez-les au client local de l’environnement d’exécution et reconvertissez les réponses en modèles de domaine. Préservez le comportement de diffusion des journaux, des mesures et des événements de cycle de vie au lieu d’accumuler en mémoire des résultats sans limite. Le filtrage par niveau, requête ou expression régulière doit conserver une limite de résultats claire. Les actions sur les charges de travail doivent rester derrière un contrôle d’activation explicite. ## Faire des tests reproductibles et déboguer les connexions en direct Exécutez les tests de la partie serveur avec le détecteur de conditions de concurrence. Utilisez de manière cohérente la bibliothèque d’assertions du projet, exécutez les tests de l’interface en UTC et lancez les tests d’intégration dans le navigateur avec la configuration de services requise. Régénérez les certificats et les artefacts de protocole nécessaires avant de considérer les échecs de construction comme des défauts du code. Pour le développement avec des ressources non intégrées, activez le service depuis le système de fichiers et le rechargement à chaud coordonné. Les modifications de la partie serveur doivent redémarrer son processus de surveillance, tandis que celles de l’interface doivent utiliser le remplacement de modules sans imposer un redémarrage complet. Pour déboguer, activez les journaux de débogage de la partie serveur, examinez l’état de l’interface avec les outils de développement du navigateur et inspectez dans le panneau réseau les connexions d’événements envoyés par le serveur et WebSocket. Examinez l’écart final afin que les fichiers générés et les modifications automatisées ne masquent pas des changements sans rapport.