Proxy GTFS-RT : investigation problème reporté par Google Maps

AntoineAugusti commented 8 months ago

Google Maps nous a remonté rencontrer des erreurs lors du requêtage de certains flux GTFS-RT.

J'ai investigué et je n'ai rien trouvé mettant en évidence un dysfonctionnement de notre infrastructure pour le moment, le problème semble être au niveau des serveurs sources des producteurs de données.

J'ai :

regardé des logs dans AppSignal (avec des mots clés sur "Sent 502" Google / filtré par leur user-agent)
regardé dans Sentry
Lu le code
Exécuté un test en local

Mix.install([{:httpoison, "~> 2.2"}])

require Logger

url = "https://proxy.transport.data.gouv.fr/resource/divia-dijon-gtfs-rt-trip-update"

1..100_000
|> Task.async_stream(
  fn _ ->
    case HTTPoison.get(url, [{"user-agent", "REDACTED"}]) do
      {:ok, %{status_code: 200}} ->
        :ok
      other ->
        Logger.error(inspect(other))
    end
  end,
  max_concurrency: 5,
  timeout: 10_000
)
|> Stream.run()

qui m'a donné 8 timeout ou bad gateway sur 100 000 requêtes en requêtant pendant 15-20 minutes.

J'attends des retours plus précis de l'équipe technique de Google.

cc @thbar si tu as des idées pour continuer l'enquête ou déterminer si le problème vient de notre infrastructure ou non.

thbar commented 8 months ago

cc @thbar si tu as des idées pour continuer l'enquête ou déterminer si le problème vient de notre infrastructure ou non.

Plusieurs points:

on peut utiliser le staging pour éviter de polluer nos métriques de production (et voir si ça fait pareil, ça peut faire différemment)
on gagnerait à arriver de distinguer un retour type 500 qui est causé spécifiquement par une erreur dans le proxy (qui a peu de chances d'arriver en général, en particulier car j'ai collé les traces Ecto dans une tâche à part) avec celles retournées par le serveur distant (via un header ou autre par exemple) ; c'est peut-être ça le plus fiable à mettre en place pour tracer ça
ça permettrait de refaire le test ci-dessus mais en ayant une info fiable (1/ j'ai reçu la réponse du distant et j'ai bien traité et 2/ j'ai pété une erreur)
typiquement après si on ne trouve pas, je ferais des requêtes en parallèle avec un petit volume sur un déploiement quelque part (mais pas trop pour ne pas déclencher d'autre souci)

Je pense que je vais essayer de relire le code du proxy pour voir ce qui peut se passer, puis aller vers la mise en place d'un suivi avec la distinction plus haut.

Voilà à "brûle pourpoint".

AntoineAugusti commented 8 months ago

@thbar Ce sont de bonnes pistes pour améliorer les choses !

Je voulais dans un premier temps vérifier qu'il n'y avait pas de problème évident du côté de l'infra Clever Cloud ou de notre proxy avec ces analyses et ce script.

À ce stade et sans retour d'autres éléments de Google il semble qu'on relaie simplement les problèmes des serveurs de notre producteur.

AntoineAugusti commented 8 months ago

@thbar Si ça te convient, je te laisse traiter la partie "modification du code proxy" et créer éventuellement un autre ticket ou directement une PR ? Je vais m'en tenir à l'investigation et indiquer les résultats sur cette issue.

thbar commented 8 months ago

@thbar Si ça te convient, je te laisse traiter la partie "modification du code proxy" et créer éventuellement un autre ticket ou directement une PR ? Je vais m'en tenir à l'investigation et indiquer les résultats sur cette issue.

Tout à fait - il faut voir quelle priorité on assigne à ça ; et je suis curieux de voir les retours, j'irai voir la discussion.

AntoineAugusti commented 8 months ago

@thbar Google vient de nous partager quelques éléments. J'ai regardé rapidement et il y a une erreur que je n'explique pas, les erreurs status_code = 504 et le détail est

Failed to download (HTTP status: GatewayTimeout. Content: {"fault":{"faultstring":"Gateway Timeout","detail":{"errorcode":"messaging.adaptors.http.flow.GatewayTimeout"}}}) Status code: GatewayTimeout. Content: {"fault":{"faultstring":"Gateway Timeout","detail":{"errorcode":"messaging.adaptors.http.flow.GatewayTimeout"}}}.

je ne vois pas ce qui pourrait retourner ça chez nous et je n'ai pas constaté ça dans mes tests. Je ne vois pas les requêtes de notre côté dans AppSignal non plus.

J'ai regardé pour Divia trip updates et SNCF TER en particulier.

Tu as une idée ? Sinon je demanderai des infos complémentaires. Je me demande si c'est pas une gateway intermédiaire chez eux.

thbar commented 8 months ago

J'ai plusieurs idées pour aller voir:

déjà avaler le CSV et fournir des stats (count by resource ref) et voir si des patterns émergent
instrumenter notre code (mon idée plus haut, mais aussi un peu davantage), quitte à ce que ça soit temporaire, pour "tracer" un peu mieux le souci

Côté AppSignal les requêtes sont filtrées chez nous pour économiser le budget (les vraies requêtes je veux dire) donc on ne les retrouvera pas (et au pire on pourrait sélectivement les laisser passer, pour un subset, le temps de l'enquête).

Ca pourrait être autant un souci chez nous, que sur notre load balancer, que sur un proxy intermédiaire chez eux (type gateway anti-sorties)...

Il va falloir instrumenter avec une probe pour s'en sortir je pense.

AntoineAugusti commented 8 months ago

Il y a déjà normalement quelques éléments à regarder en ouvrant le CSV et en regardant certains flux. Certaines erreurs sont de toute évidence côté producteur mais pour par exemple SNCF et Divia il y a beaucoup de 504. AppSignal donne quelques traces de logs quand même.

Je vais de toute façon demander des clarifications côté Google et éventuellement leur demandant de spécifier un user-agent précis ou de passer des params dans l'URL pour faciliter les choses.

thbar commented 8 months ago

AppSignal donne quelques traces de logs quand même.

Oui juste les logs mais pas les requêtes pour le coup ; je pense que j'irai sûrement activer la trace sur les requêtes mais de façon sélective, avec un flux précis, pour ne pas exploser notre quota !

AntoineAugusti commented 8 months ago

@thbar Tu as bien les requêtes dans AppSignal avec le rate limiter et LOG_USER_AGENT = true. Mais il y a des choses à améliorer dans le code proxy pour distinguer d'où vient l'erreur (on relaie le producteur ou pas).

thbar commented 8 months ago

Je vais de toute façon demander des clarifications côté Google et éventuellement leur demandant de spécifier un user-agent précis ou de passer des params dans l'URL pour faciliter les choses.

@thbar Si ça te convient, je te laisse traiter la partie "modification du code proxy" et créer éventuellement un autre ticket ou directement une PR ? Je vais m'en tenir à l'investigation et indiquer les résultats sur cette issue.

J'ai créé:

https://github.com/etalab/transport-site/issues/3679

(dont je m'occuperai à un moment)

Je reste abonné ici pour suivre l'aventure :-)

thbar commented 8 months ago

@thbar Tu as bien les requêtes dans AppSignal avec le rate limiter et LOG_USER_AGENT = true. Mais il y a des choses à améliorer dans le code proxy !

Tu pourras pointer où ça sort dans AppSignal? Du coup je me demande si on ne double-compte pas des choses!

Je verrai en fonction du lien. Merci!

AntoineAugusti commented 8 months ago

Dans les logs

AntoineAugusti commented 8 months ago

Ma réponse à Google Maps

AntoineAugusti commented 8 months ago

https://github.com/etalab/transport-site/issues/3580 sur le sujet des logs et des attributs pour pouvoir les filtrer correctement dans AppSignal

AntoineAugusti commented 8 months ago

Google indique

De mon côté, je ne peux malheureusement pas te fournir plus d'informations.

Toutefois, ils ont ajouté les paramètres suivants à leurs requêtes vers les flux GTFS-RT ?client=Google-Transit-GTFSRT.

etalab / transport-site

Proxy GTFS-RT : investigation problème reporté par Google Maps #3670