Come posso eseguire il debug di eccezioni che non sono facilmente riproducibili e si verificano solo in un ambiente di produzione?

Sto lavorando a un problema in cui l'eccezione si verifica solo nel nostro ambiente di produzione. Non ho accesso a questi ambienti, né so cosa significhi questa eccezione. Guardando la descrizione dell'errore, non riesco a capire la causa.

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Qualcuno potrebbe consigliarmi su come affrontare questo tipo di problema?

exceptions

— C4CodeE4Exe
fonte

questo dovrebbe essere spostato su StackOverflow? Penso che otterresti più risposte lì.

— DXM,

Una sola parola: registrazione.

— quant_dev

@DXM - sarebbe fuori tema per StackTranslate.it, in quanto è troppo generale. L'OP cerca strategie e tecniche piuttosto che una soluzione specifica. Se fosse incluso il codice che non andava a buon fine, forse potrebbe funzionare su Stack Overflow.

— ChrisF

Nella mia esperienza, molti problemi come questo derivano da problemi di configurazione della sicurezza e possono essere difficili da capire. Come altri hanno già detto, una buona registrazione aiuterà a rivelarlo.

— jfrankcarr,

Risposte:

In generale, una migliore registrazione del debug. Scopri cosa vuoi sapere, aggiungilo al codice e inseriscilo nei log in modo da poterlo elaborare. Catturare ulteriori dettagli sull'ambiente in quel momento aiuta anche: quale richiesta, quando, ecc.

In particolare, cercherei un modello comune nei client che colpiscono questo - e se ne trovassi uno ottimizzato - ma poi andrei e catturerei il traffico del livello TCP.

Guardare i messaggi SSL scambiati dovrebbe darti un'idea di cosa non va nel protocollo, o almeno quali sono le proprietà comuni della richiesta. Una volta ottenuto, dovrebbe essere più vicino al debug.

Come guida, immagino che questo provenga da una di queste tre cose:

Qualcosa che non è SSL ha parlato con la porta SSL. (le scansioni delle porte sono comuni, ma succede anche HTTP alla porta HTTPS.)
Il client non condivide un set accettabile di cifre con il server.
Il client offre un certificato e il server ha un attacco sibilante. (Non comune, ma possibile.)

— Daniel Pittman
fonte

forse il server offre un certificato autofirmato o firmato da una CA che il client non conosce / di cui si fida

— Carlos Campderrós

Penso di aver visto il n. 3 accadere quando una delle parti ha scaduto i certificati.

— FrustratedWithFormsDesigner

Ho fatto un po 'di debug sui sistemi di produzione. Non ho mai usato un debugger, è sempre stato il log o la scrittura di valori chiave in una particolare parte dello schermo.

— Loren Pechtel,

grazie a tutti per il consiglio. Sono sicuro che ci sono modi pragmatici per risolvere un bug di produzione.

— C4CodeE4Exe

Consiglierei di utilizzare una strategia di registrazione con un livello di registro massimo configurabile. Un'utilità come log4j ( http://logging.apache.org/log4j/ , http://en.wikipedia.org/wiki/Log4j ) potrebbe fare il lavoro.

Il livello di registro (o verbosità) configurabile è importante per poter trovare la ragione di un errore, possibilmente senza dover ridistribuire il software.

Se tale strategia non è sufficiente per trovare l'errore, prova a trovare come produrre / leggere i registri prodotti dalle applicazioni con cui comunica il tuo.

È inoltre possibile implementare un meccanismo per ottenere automaticamente ulteriori informazioni sugli errori via e-mail.

Più in generale, puoi leggere alcuni articoli sulla strumentazione, che è un argomento più ampio che include la registrazione e la traccia.

— PL
fonte