[BACK] Référencer les coupures du back / délai call API

[marthevienne]

Les segments DEFAULT_AIS sont déterminés sur la base d'un délai de plus de 30 min (ou 29 min) entre 2 positions successives.

En fouillant dans les données de spire_ais_data, on peut voir parfois que des données n'ont pas été créées toutes les 30 min (gap). Cela arrive même assez souvent. On a donc l'impression d'avoir un tas de segments en DEFAULT_AIS alors qu'en réalité, le problème vient d'ailleurs.

De plus, on a déjà eu des coupures de l'instance en production (BDD pleine, facture impayée (oups), maintenance).

On peut voir leur trace dans la table spire_ais_data.

J'ai référencé dans un CSV les gap post archivage de Nicolas donc il me manque qu'un mois depuis qu'on a migré vers CleverCloud.

Comment pourrait-on imaginer suivre ces interruptions et donc pouvoir différencier une perte du signal venant du bateau/zone VS le back ?

[SebM42]

Proposition :

• lors du lancement de la requete de récupération des infos spire, on établit le delta de temps depuis le dernier lancement (il me semble que nico stocke déjà le timestamp du dernier appel dans la BDD), si ce dernier lancement a eu lieu il y a plus de X minutes, alors on spécifie dans la base une valeur indiquant qu'on a eu une coupure du back

• on rajoute un type de segment (mettons OFF ou BACK_FAILURE)

• lors de la création des segments, si la valeur de la base indique qu'il y a eu une coupure back, alors au lieu de typer les segment en DEFAUT_AIS on leur attribue ce nouveau type de segment

• on prévoit une représentation cartographique pour ce nouveau type de segment

[rv2931]

Dans les évolutions à prévoir je pense qu'un véritable traitement par lot serait intéressant et permettrait entre autre de gérer ce genre de chose
La proposition de @SebM42 devrait fonctionner mais d'un point de vue qualité ça veut dire qu'on perd de données, données qui aujourd'hui sont un peu compliquée à corriger/regénérer

Idéalement pour faire ça, faudrait passer par des vrais outils du genre Airflow/Dagster ou autre. En attendant on peut bricoler des trucs qui ne ferait non pas que tracer ce qui a été fait, mais planifier les slots sur les 24 prochaines heures par exemple avec leurs paramétrage (date de référence de l'interrogation, période interrogée, statut...) et avoir une info de chaque slot du genre "planifié", "en cours", "succès"/"error"
Du coup quand il y a interruption, c'est bcp plus facile de voir ce qui était planifié, ce qui n'a finalement pas été joué, de rejouer ce qu'il manque avec les paramètres qui étaient prévus jusqu'à arriver au dernier slot planifié pour la date/heure courante
On peut d'ailleurs là aussi très facilement dire qu'on souhaite arrêter les interrogations dès qu'un des slot précédent est en erreur ou est resté "en cours" puisqu'il a planté, ou même rejouer un slot en cas d'indisponibilité de l'API spire le temps qu'elle revienne

Après ça repose la question: est-ce qu'on bricole un truc qui ferait comme, ou est-ce qu'on utilise un outil fait pour ça
Mais j'imagine que la proposition de @SebM42 est plus facile et rapide à mettre en œuvre en l'état des choses

[SebM42]

Le sujet porte sur les interruptions d'appel à l'API de Spire, et à ma connaissance, si on rate un appel API pour n'importe quelle raison (sic : BDD pleine, facture impayée (oups), maintenance), alors de toute facon les données sont perdus car on ne peut pas remonter le temps

[rv2931]

Oui, effectivement, j'ai pas regardé l'API spire les paramètres qu'on avait sur l'API spire mais ça vaudrait le coup d'y jeter un oeil voir si le traitement par lot et récupération reste envisageable
ça celle-là : https://documentation.spire.com/vessels-api/making-api-calls/ ?

[marthevienne]

Je peux bricoler un truc pour enregistrer les gap de manière assez simple pour l'instant pour ne bloquer l'archivage des données AIS. C'était surtout pour vous sonder sur la question.
Effectivement, on ne peut pas récupérer des données passées mais on peut en racheter si besoin donc dans l'idée, s'il nous manque plusieurs jours, on peut demander à Spire de nous les filer.

[rv2931]

Du coup, dans la doc publique, on a bien les paramètres updated_after et updated_before. C'est généralement les parmaètres qui permettent de faire du traitement par lot maintenant il y a sûrement des limites techniques ou contractuelles que je n'ai pas

Sachant que souvent il n'y a que updated_after mais ce n'est pas trop grace car finalement si t'interroge sur -1h, en séparant les infos tu récupère finalement les infos pour 4 slots de 15min, ce qui permet de garder une gestion par slots mais de réduire le nombre d'interrogation

[SebM42]

Je peux bricoler un truc pour enregistrer les gap de manière assez simple pour l'instant pour ne bloquer l'archivage des données AIS. C'était surtout pour vous sonder sur la question. Effectivement, on ne peut pas récupérer des données passées mais on peut en racheter si besoin donc dans l'idée, s'il nous manque plusieurs jours, on peut demander à Spire de nous les filer.

Si on a cette possibilité, c'est assez lourd à faire, puisque la structure des données qu on recevra alors de Spire sera bien différente. Il faudra donc convertir ces données en un batch structuré à passer dans l'ETL. J'imagine également que Spire à une limite dans son historique, il faudra également vérifier que cette limite est suffisamment grande pour couvrir les périodes manquantes, sinon il faudra également prévoir le cas ou la période manquante est supérieure à cette limite (cf ma proposition pour ce cas)

Je suggère de faire un easy fix à échéance moyenne pour commencer, et se pencher sur la récupération d'un historique spire à échéance plus longue.

[rv2931]

J'ai regardé comme on trace les exécutions des tâches aujourd'hui et j'aurais une proposition à faire pour tracer les exécutions des call API de la même manière mais en ajoutant une historisation
globalement, en s'inspirant du mécanisme Slow Changing Dimensions

• on rajoute une colonne : active:bool qui est à True exclusivement pour l'exécution en cours
• à chaque nouvelle exécution on ajoute une ligne : active=True (on mets toutes les autres lignes de la task à False) et on stocke de la même manière qu'actuellement le point in time, created_at et updated_at
• la fonction get_point_in_time reste inchangée mais ne prend ses données que dans la ligne active=True
• la fonction set_point_in_time reste inchangé vu de l'extérieur, c'est juste qu'en plus elle crée une nouvelle ligne avec active=True et mets les autres active=False)
• on trace la task load_spire_data_from_api de la même manière (actuellement elle n'est pas "surveillée"), seules clean_positions et create_update_excursions_segments sont tracées

Au final, on l'historique d'exécution complet de toutes les tâches et donc on peut facilement détecter les périodes ou la task load_spire_data_from_api ne s'est pas exécutée pendant plus de 15 minutes

@marthevienne @njouanin

[njouanin]

oui, ça me va de tracer les exécutions et l'historique des traitements. Ca permettrait effectivement de détecter les trous qui ont pour origine une mauvaise exécution côté back.

[marthevienne]

C'est en prod ! Bravo !
Le but est de venir alimenter la création des segments avec les infos sur les coupures. Pour l'instant, gardons-les en base, on augmente la taille de la BDD si nécessaire et une fois qu'on aura fait le lien, on pourra archiver les tasks_executions au même titre que les données AIS s'il n'y a pas d'autre blocage.