envoyproxy/envoy

Access log status code filter not working for response code 0

Open

#17 482 ouverte le 26 juil. 2021

Voir sur GitHub
 (3 commentaires) (0 réactions) (0 assignés)C++ (5 373 forks)batch import
area/access_logbughelp wanted

Métriques du dépôt

Stars
 (27 997 stars)
Métriques de merge PR
 (Merge moyen 8j) (378 PRs mergées en 30 j)

Description

Description: Unable to use status code filters to log requests with a 0 response code.

Repro steps: We are running Istio 1.6.13 which uses Envoy 1.15.4. We want to only output access logs for HTTP requests with responses >= 400 or == 0.

This is the filter being applied:

filter:
  or_filter:
    filters:
    - status_code_filter:
        comparison:
          op: GE
          value:
            default_value: "400"
            runtime_key: "400"
    - status_code_filter:
        comparison:
          op: EQ
          value:
            default_value: "0"
            runtime_key: "0"

All 4xx/5xx requests are being logged, and 1xx/2xx/3xx requests are not logged, as expected. However, any requests with response code 0 are also not being logged.

Has this been resolved in a newer version of Envoy/Istio?

If not:

  1. Is this the intended behaviour because the status code filter only gets applied to valid HTTP response codes?
  2. Is there a different filter that can be applied to make sure all 0 responses get logged?

Guide contributeur

Direction de recherche
Étudiez l'implémentation de status code filter dans la chaîne de filtres HTTP d'Envoy. Le filtre ne traite probablement que les codes d'état HTTP valides (100-599) et ignore le 0. Examinez la logique de comparaison du filtre dans source/common/http/filters. Vérifiez s'il existe une limitation connue ou si un cas spécial pour 0 est nécessaire. Passez également en revue l'analyse de la configuration pour voir si 0 est accepté comme valeur valide. Envisagez d'ajouter un cas de test pour le code d'état 0.
Stack technique
cpp
Domaine
backend
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
Une demi journée
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
C++Git
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65