Suposem que un client envia una petició sense credencials de proxy, rep un repte i ho torna a provar amb èxit. Un registre de peticions pot contenir dues entrades. La persona que utilitza l'aplicació, però, ha viscut una sola operació completada.

Per això, un registre dividit a parts iguals entre TCP_DENIED/407 i TCP_TUNNEL/200 no estableix automàticament un índex de fallades del cinquanta per cent. Primer determineu si les entrades formen parelles de repte i reintent.

Compta allò que realment t'importa

MesuraRecompte
Reptes d'autenticacióRespostes del proxy que demanen autenticació
Intents de proxyTransaccions individuals registrades per l'intermediari
Feines completadesOperacions de l'aplicació que arriben al resultat previst

Correlacioneu les marques de temps, el context del client, la destinació i qualsevol identificador de petició disponible. Un intent no autenticat pot no tenir cap nom d'usuari registrat, mentre que el reintent correcte sí que en té. L'activitat simultània fa que les línies adjacents, per si soles, siguin una prova feble que dues entrades vagin juntes.

També convé mantenir un túnel correcte separat d'una operació web correcta. L'acceptació de CONNECT estableix el túnel; la destinació encara pot fallar durant el TLS o retornar un error d'aplicació després.

Investigueu reptes terminals repetits, feines sense cap finalització posterior o un canvi sobtat en el nombre d'intercanvis. Aquests casos són diferents d'un client estable que primer rep el repte i fa exactament el que li demana la seva configuració. Suprimir l'autenticació només per fer més verd un tauler canviaria el servei en lloc de reparar la mesura.

Articles relacionats