Journaux Squid : un 407 suivi d'un 200 compte-t-il comme un échec ?
Comptez les opérations terminées séparément des échanges d'authentification lorsque Squid journalise un défi suivi d'un tunnel réussi.
Supposons qu'un client envoie une requête sans identifiants proxy, reçoive un défi et réessaie avec succès. Un journal de requêtes peut contenir deux entrées. La personne qui utilise l'application n'a pourtant vécu qu'une seule opération terminée.
C'est pourquoi un journal réparti à parts égales entre TCP_DENIED/407 et TCP_TUNNEL/200 n'établit pas automatiquement un taux d'échec de cinquante pour cent. Déterminez d'abord si les entrées forment des paires de défi et de nouvelle tentative.
Comptez ce qui vous importe réellement
| Mesure | Nombre |
|---|---|
| Défis d'authentification | Réponses du proxy demandant une authentification |
| Tentatives de proxy | Transactions individuelles enregistrées par l'intermédiaire |
| Tâches terminées | Opérations de l'application atteignant le résultat prévu |
Corrélez les horodatages, le contexte du client, la destination et tout identifiant de requête disponible. Une tentative non authentifiée peut n'avoir aucun nom d'utilisateur journalisé, alors que sa nouvelle tentative réussie en a un. Une activité simultanée signifie que des lignes adjacentes, à elles seules, sont une preuve faible que deux entrées vont ensemble.
Gardez aussi un tunnel réussi distinct d'une opération de site web réussie. L'acceptation de CONNECT établit le tunnel ; la destination peut encore échouer pendant TLS ou renvoyer ensuite une erreur d'application.
Examinez les défis terminaux répétés, les tâches sans achèvement ultérieur ou un changement soudain du nombre d'échanges. Ces cas diffèrent d'un client stable qui commence par un défi et fait exactement ce que sa configuration demande. Supprimer l'authentification uniquement pour verdir un tableau de bord modifierait le service au lieu de réparer la mesure.