Ressources · 113
Panne de collecte : rapprocher les journaux et les événements manquants
Distinguer événements produits, reçus et exploitables pour expliquer une interruption sans confondre silence et absence d’incident.
· 2 min
Ce que ce guide permet
- Définir une référence observable
- Exercer une interruption maîtrisée
- Comparer les identifiants et déclarer les inconnus
Contrôle express
- Séquence de référence et schéma de rapprochement.
- Chronologie de panne et comportement aux limites.
- Liste des écarts et état de couverture explicite.
Méthode pas à pas
- 01
Définir une référence observable
Cartographiez application, collecteur et stockage avec leurs responsables. Préparez une séquence finie d’événements fictifs portant des identifiants stables, sans secrets ni données clients. Conservez heure de l’événement et heure d’observation : un retard de collecte n’est pas automatiquement une perte.
Séquence de référence et schéma de rapprochement.
- 02
Exercer une interruption maîtrisée
En test, interrompez la destination puis rétablissez-la. Observez remplissage de la file, tentatives, rejets et redémarrage. Une file persistante peut limiter certaines pertes mais reste bornée et dépend du stockage ; fixez le comportement si elle est pleine. Vérifiez que la collecte ne bloque pas silencieusement le service.
Chronologie de panne et comportement aux limites.
- 03
Comparer les identifiants et déclarer les inconnus
Rapprochez la référence et les événements réellement lisibles au même arrêt d’observation. Comptez répétitions, retards et absences séparément ; un acquittement réseau ne prouve pas l’exploitation finale. Sans référence fiable, déclarez la couverture inconnue plutôt que zéro événement perdu ou zéro incident.
Liste des écarts et état de couverture explicite.
Cas de recette à reproduire
Exemple fictif : ces données ne décrivent aucun client ni résultat réel.
Voir les données du cas
{
"expected_ids": [
"E1",
"E2",
"E3"
],
"received_ids": [
"E1",
"E1",
"E3"
],
"received_rows": 3,
"unique_received": 2,
"missing_ids": [
"E2"
],
"observation_cutoff": "same_for_both_sets"
}Décision attendue
Exemple fictif : E1, E2 et E3 sont attendus, mais E1, E1 et E3 sont reçus. Les trois lignes ne prouvent pas la complétude : E1 se répète et E2 manque à l’arrêt d’observation.
Votre carnet de recette
Consignez vos observations pour les critères de ce guide. Un relevé ne constitue pas une certification.
Le carnet ne sauvegarde pas automatiquement. Exportez avant de quitter.
Les filtres ne limitent pas les exports. La liste d’actions retient les blocages et critères non examinés.
L’import remplace les observations courantes après votre confirmation.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Événements manquants connus | Identifiants attendus absents de la destination | Référence et arrêt d’observation identiques |
| Répétitions reçues | Lignes reçues − identifiants uniques | Ne mesure pas les pertes inconnues |
Erreurs fréquentes
Questions fréquentes
Trois lignes reçues prouvent-elles que trois événements sont conservés ?
Non. Deux lignes peuvent répéter le même identifiant et masquer une absence. Comparez les identifiants, la fenêtre d’observation et les étapes de la chaîne.
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
Pour aller plus loin
Analyses associées
