Produits Entr'ouvert » Passerelle

Pour alimenter le ticket (ce n'est pas un avis).
Je ne sais pas si c'est une bonne pratique : personnellement j'utilise les mails d'erreurs pour signaler aux clients leurs erreurs de configuration (erreurs " métier "),
signalées par les self.logger.error dans les connecteurs.
Pour Parsifal, ça me permet de garder un œil sur les cas d'usages non prévus qui arrivent constamment.
Peut-être que si je devais regarder à plusieurs endroits (IHMs passerelle, mails ou sentry), je privilégierais l'un ou l'autre par défaut.

edit (d'après la note-ci-dessous) :

les logs explicites (self.logger.error/exception dans le code des connecteurs) => pas sentry

Perso je les attrape via les traces envoyés par mails, mais ils sont aussi dans sentry, ex:

• https://sentry.entrouvert.org/entrouvert/publik/issues/119252/?query=No%20week%20calendar%20for%20family
• https://sentry.entrouvert.org/entrouvert/publik/issues/122809/?query=fails%20to%20notify%20paid%20invoice
• https://sentry.entrouvert.org/entrouvert/publik/issues/112749/?query=existe%20d%C3%A9j%C3%A0%20sur%20la%20famille

Il faut bien séparer:

• le fait pour le module d'intégration logging de sentry de prendre les messages en niveau erreur et les pousser dans sentry
  • ça n'est pas un handler classique, ça monkeypatch logging pour récupérer absolument tous les logs en erreur
  • il y a de quoi ignorer un logger https://docs.sentry.io/platforms/python/integrations/logging/#ignoring-a-logger à voir si on pourrait ignorer le logger parent de tous les loggers de connecteurs passerelle.resource
• les logs explicites (self.logger.error/exception dans le code des connecteurs) => pas sentry
• les logs implicites:
  • dans passerelle.utils.jsonresponse.to_json => à trier
    

            # ici self.logger vaut quasiment toujours connector.logger
            logger = self.logger or logging.getLogger('passerelle.jsonresponse')
    ...
               elif isinstance(e, HTTPError):
                    log_http_request(
                        logger,
                        request=e.request,
                        response=e.response,
                        extra=extras,
                        duration=e.response.elapsed.total_seconds(),
                    )
    ...
                elif getattr(e, 'log_error', True):
                    logger.exception('Error occurred while processing request', extra=extras)
                else:
                    logger.warning('Error occurred while processing request', extra=extras)
    

  • dans l'application wsgi de Django => sentry

C'est ici que la plupart des APIError et RequestException sont interceptées et finissent journalisées mais il y en a aussi dans passerelle.utils.Request, il y a donc un tri à faire pour pouvoir router proprement les choses et ne pas les envoyer à sentry.

Déjà dans un premier temper séparer APIError, qui est a priori une erreur relativement bien identifiée, des autres exceptions dans to_json().