Recherche & corrélation des logs
Voir tous les tagsUne note de conception classe les endroits où un classifieur qui répond par une probabilité calibrée, jamais par du texte, aurait sa place dans avuru obs, et ce que chaque usage coûterait à la promesse que rien ne quitte le cluster. Un banc d'essai hors ligne mesure le premier cas avant qu'un modèle ne soit jamais appelé depuis le produit.
Choisissez les services et workloads qui vous intéressent, sélectionnez les sources à lire, puis suivez leurs logs en un flux fusionné ou en panneaux côte à côte — depuis Signaux → Logs et depuis le nouvel onglet Service Mesh → Logs.
La carte des services devient le point d'entrée de l'application : sélectionnez un service, gardez la carte sous les yeux, et passez à ses appelants, ses dépendances, ses traces et ses journaux depuis un seul inspecteur.
L'onglet Journaux d'un service ne revient plus vide quand le pod range ses
lignes sous un autre nom, et chaque table de journaux sait désormais copier,
sélectionner et télécharger les lignes qu'elle affiche. Les deux changements
sont sur main pour la prochaine version.
Deux changements côté journaux, tous deux sur main pour la prochaine
version : une ligne suivie sur le stdout d'un pod porte désormais une
sévérité, et l'onglet Journaux d'une charge de travail sur l'écran du maillage
part des lignes de la charge elle-même.
La v0.16.0 fait de la page d'une charge de travail, sur l'écran du maillage, la fiche que le cluster en tient lui-même — et y met ses journaux : ses propres lignes, et celles que le proxy de nœud et son waypoint ont écrites à son sujet, reliées par le hub qui connaît ses pods.
L'installation du chart Helm déploie désormais un sensor par nœud qui observe chaque service du cluster — traces eBPF, métriques RED et collecte des logs, sans SDK, sans sidecar, sans changement applicatif.
Les logs sont interrogeables et reliés aux traces.