Lucarne
Exploitation

Tableaux de bord

Aucun tableau de bord n'est provisionné. Les données sont interrogeables chez les quatre fournisseurs, ce qui est vérifié ; les tableaux de bord restent à construire. Cette page décrit ce qui est possible et par quel moyen, en distinguant ce qui est automatisable de ce qui ne l'est pas.

État

FournisseurProvisionnement par APIÉtat
OpenObserveoui (/api/{org}/dashboards)Non fait
Umaminon documentéNon fait, vues natives disponibles
Matomooui (API.getReportMetadata, widgets)Non fait, rapports natifs disponibles
Rybbitpartiel (entonnoirs via /api/sites/{site}/funnels)Non fait

Umami et Rybbit offrent des vues prêtes à l'emploi sans configuration : audience, pages, référents, événements. Pour un POC de comparaison, elles suffisent et ne demandent aucun travail.

Ce qui est mesurable avec le catalogue actuel

Avec les cinq événements de events.md :

  • pages vues, visiteurs, sessions — natif chez les trois fournisseurs ;
  • recherches sans résultat (search_performed avec outcome: zero_results) — l'indicateur le plus utile du projet, déjà suivi par trackSiteSearch côté Matomo ;
  • clics vers les sources externes par catégorie (outbound_link_clicked) ;
  • consultations de fiches par type (record_viewed).

Ce qui n'est pas mesurable, et pourquoi

Le cahier des charges demande DAU/WAU/MAU, entonnoir d'inscription, adoption de fonctionnalité, rétention et attribution de campagne. La plupart n'ont pas de sens ici :

  • pas d'inscription ni de compte : aucun entonnoir d'activation ;
  • pas d'identification (ADR 006) : la rétention par utilisateur est hors d'atteinte, seule une approximation par session est possible ;
  • agent_created et agent_run_completed de l'exemple n'existent pas dans ce produit.

Provisionner des panneaux pour des signaux qui ne sont pas collectés produirait des tableaux de bord vides. Le cahier des charges l'interdit explicitement, à raison.

Pour OpenObserve

L'API accepte une définition JSON :

TerminalCode
AUTH=$(grep '^OPENOBSERVE_AUTH=' infra/analytics/compose/.env | cut -d= -f2-)
curl -X POST "http://localhost:5080/api/default/dashboards" \
  -H "Authorization: $AUTH" -H 'Content-Type: application/json' \
  -d @mon-tableau-de-bord.json

Panneaux qui correspondent à des signaux réellement collectés aujourd'hui : volume de journaux par niveau, durée des spans par nom d'opération, compteurs applicatifs exportés par la façade.

Tout le reste — latence HTTP par centile, erreurs par route, santé des conteneurs — suppose d'activer l'instrumentation automatique et un exportateur d'hôte, ce qui n'est pas fait.

Chaîne analytics

Le cahier des charges demande un tableau de bord sur la chaîne elle-même : événements générés, acceptés, rejetés, réessais, arriéré, erreurs par fournisseur. Les compteurs existent dans AnalyticsClient.getStats() et EventQueue.getStats(), mais ne sont pas encore exportés en métriques OpenTelemetry. C'est le chaînon manquant le plus simple à ajouter, et le plus utile pour exploiter la chaîne.

DéploiementCapacité