Skip to Content
TestingObservabilité app

Observabilité app

Disponibilité

L’API observabilité est partiellement implémentée. Deux sources de données sont utiles aujourd’hui :

  • une timeline d’événements append-only remplie manuellement ; et
  • allocation ressources VM courante rapportée par libvirt.

Les éléments suivants sont des aperçus de contrat uniquement :

  • analytics requêtes renvoie une liste rollup vide car ingest logs accès ne tourne pas ;
  • configuration sonde uptime persiste, mais aucun planificateur n’effectue les vérifications HTTP ;
  • échantillons ressources sont vides car l’échantillonneur ne tourne pas ; et
  • streaming journaux app n’est pas implémenté.

Il n’y a pas de tableau de bord observabilité terminé. Une configuration sonde stockée n’est pas une preuve qu’un endpoint a été vérifié.

Surface REST actuelle

Les routes sont sous /api/app-gateway.

MéthodeCheminCe que cela prouve aujourd’hui
GET/analytics/{slug}?days=7Le contrat est joignable ; rollups est attendu vide.
PUT/probes/{slug}La configuration sonde a été validée et stockée.
GET/probes/{slug}La configuration stockée peut être lue. Le statut runtime reste non défini.
DELETE/probes/{slug}La configuration stockée a été supprimée.
POST/events/{slug}Un événement fourni par l’appelant a été ajouté.
GET/events/{slug}?limit=100Événements stockés lisibles du plus récent au plus ancien.
GET/metrics/{slug}?vm_name={name}Allocation courante peut être renvoyée ; samples est vide.

Configuration sonde

PUT /api/app-gateway/probes/my-app Content-Type: application/json { "path": "/healthz", "interval_s": 60, "expected_status": 200, "timeout_s": 5, "enabled": true }

Une lecture ressemble actuellement à ceci :

{ "config": { "path": "/healthz", "interval_s": 60, "expected_status": 200, "timeout_s": 5, "enabled": true }, "last_run_at": null, "last_status": null, "last_http_status": null, "consecutive_failures": 0 }

Les champs runtime null sont le signal important : aucune vérification n’a tourné. Utilisez un moniteur externe pour alertes disponibilité jusqu’à livraison du planificateur.

Événements

Les événements sont des enregistrements durables écrits via l’API, pas une piste d’audit automatiquement complète. Hooks déploiement, checkpoint, domaine et walker sont encore en attente ; les appelants ne doivent pas supposer que ces activités apparaîtront sans append explicite.

Traitez métadonnées événement comme données fournies par l’appelant. N’y placez pas de secrets.

Allocation ressources

La route metrics peut rapporter vCPUs, mémoire et disques assignés lorsqu’une VM correspondante est disponible depuis libvirt. Elle ne rapporte pas encore série temporelle ni santé applicative. L’allocation est configuration de capacité, pas preuve que l’application a utilisé ou survécu à cette capacité.

Conseils opérationnels

Jusqu’à déploiement ingest et boucles worker :

  1. utilisez un moniteur HTTP externe pour uptime ;
  2. collectez journaux application avec un mécanisme géré opérateur ;
  3. utilisez libvirt ou télémétrie hôte pour utilisation réelle ; et
  4. attachez horodatages et preuves source aux enregistrements incident plutôt que de compter seule sur la liste événements aperçu.

La fonctionnalité peut être présentée comme prête seulement après ingest, sonde, échantillonnage et workers log-stream restart-safe ayant passé tests échec et reprise bout en bout.