thbar
commented
3 years ago J'ai fait une première passe de lecture, je vais décanter j'ai quelques idées qui me viennent. Merci pour l'issue !
Closed antoine-de closed 2 years ago
thbar
commented
3 years ago J'ai fait une première passe de lecture, je vais décanter j'ai quelques idées qui me viennent. Merci pour l'issue !
AntoineAugusti
commented
2 years ago Le fonctionnement en batch processing devrait pouvoir être utilisable https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/master/gtfs-realtime-validator-lib/README.md#batch-processing
thbar
commented
2 years ago C'est traité dans les PR suivantes:
On utilise bien la partie CLI Java, en la lançant sur le deuxième noeud alias "worker", qui peut crasher sans perturber le site.
Validateur GTFS-RT
On a eu plusieurs fois la demande d’avoir une validation des GTFS-RT. Tout comme la validation des GTFS, il y a 2 parties :
Préambule
Un validateur de flux GTFS-RT a besoin de 2 choses:
Il n’y a qu’un validateur opensource référencé sur awesome-transit, (utilisé par MobilityData), gtfs-realtime-validator.
On peut aussi développer le nôtre, avec les briques utilisées par notre validateur GTFS et notre convertisseur GTFS-RT->SIRI Lite.
Particularité
Validateur des ressources référencées
Une des complexités d’un validateur de données temps réel est que ces données changent en permanence :stuck_out_tongue_winking_eye: Il y a donc 2 dimensions :
Validateur à la volée
Pour la validation à la volée, j’ai l’impression qu’on peut se contenter du rapport de validation classique, pas besoin de faire du monitoring d’api.
Fonctionnalités
Rapport de validation à l’instant t
gtfs-realtime-validator propose un client CLI Java qui sort un rapport json de validation. Ils ont aussi une webapp pour lancer des validations et afficher les rapports.
L’interface a cette tête:
On peut voir soit pour directement récupérer leur webapp (mais je sais pas trop comment on ferait ca), soit refaire l’interface à notre sauce, en récupérant le json du validateur.
monitoring de l’api dans la durée
Je vois pas grand-chose là-dessus sur le gtfs-realtime-validator à part des sommes d’incidents, et une historisation des rapports (mais il y a des issues là-dessus).
Il faut voir ce qu’on veut vraiment pour ça, si on veut une vraie historisation des rapports, ou si on garde simplement des indicateurs agrégés.
Proposition de découpage
J’ai l’impression que du coup on peut découper cette grosse fonctionnalité en plusieurs petites :
Puis, dans l’ordre qu’on veut :
2a. un rapport statique à la demande
2b. monitorer les API
rapport statique
Même si ça me fait mal vu que ça serait cool à implémenter (en Rust \o/), je pense qu’on peut utiliser le validateur existant (en JAVA :scream: ) Faut voir si :
La comme ça, j’ai l’impression que ça risque d’être un peu embêtant de faire rentrer notre modèle dans leur webapp, donc que le plus simple c’est soit JAR en CLI depuis elixir (mais peut être qu’on aura des soucis de mémoire, mais en même temps pour le moment on a que des petits jdd à valider), soit une webapp à part.
Puis faudrait faire une page pour les ressources GTFS-RT (et pour toutes les ressources tant qu’a faire), avec le rapport de validation.
Monitorer dans la durée
Hum la faut voir jusqu’où on veut pousser le truc. Peut-être utiliser un truc genre prometheus (exposé par l’api qui check ?) et voir si on ne peut pas utiliser du graphana ? ou juste faire un petit graph directement sur le site, si on veut faire simple.
Voila, cette issue est suffisamment longue, vous en pensez quoi ?