Squid-naplók: hiba-e a 407, amelyet 200 követ?
A befejezett műveleteket külön számolja a hitelesítési cseréktől, amikor a Squid kihívást, majd sikeres alagutat naplóz.
Tegyük fel, hogy egy kliens proxy-hitelesítő adatok nélkül küld egy kérést, kihívást kap, majd sikeresen újrapróbálja. Egy kérésnapló két bejegyzést tartalmazhat. Az alkalmazást használó ember viszont egyetlen befejezett műveletet élt át.
Ezért az TCP_DENIED/407 és TCP_TUNNEL/200 között egyenlően megosztott napló nem bizonyít automatikusan ötven százalékos hibaarányt. Először állapítsa meg, hogy a bejegyzések kihívás-és-újrapróbálkozás párokat alkotnak-e.
Azt számolja, ami valóban számít Önnek
| Mérőszám | Darabszám |
|---|---|
| Hitelesítési kihívások | Hitelesítést kérő proxyválaszok |
| Proxypróbálkozások | A közvetítő által rögzített egyedi tranzakciók |
| Befejezett feladatok | A tervezett eredményt elérő alkalmazásműveletek |
Kapcsolja össze az időbélyegeket, a kliens kontextusát, a célt és minden elérhető kérésazonosítót. Egy nem hitelesített próbálkozásnak lehet, hogy nincs naplózott felhasználóneve, sikeres újrapróbálkozásának viszont van. Az egyidejű tevékenység azt jelenti, hogy a szomszédos sorok önmagukban gyenge bizonyítékok arra, hogy két bejegyzés összetartozik.
Tartsa továbbá külön a sikeres alagutat a sikeres weboldalművelettől. A CONNECT elfogadása létrehozza az alagutat; a cél továbbra is meghiúsulhat a TLS során, vagy később alkalmazáshibát adhat vissza.
Vizsgálja meg az ismétlődő végső kihívásokat, a később soha be nem fejeződő feladatokat vagy a cserék számának hirtelen változását. Ezek különböznek az olyan stabil klienstől, amely kihívással kezd, és pontosan azt teszi, amit a konfigurációja kér. A hitelesítés elfojtása csak azért, hogy egy irányítópult zöldebb legyen, megváltoztatná a szolgáltatást ahelyett, hogy helyrehozná a mérést.