Jak mogę debugować wyjątki, które nie są łatwe do odtworzenia i występują tylko w środowisku produkcyjnym?

Pracuję nad problemem, w którym wyjątek występuje tylko w naszym środowisku produkcyjnym. Nie mam dostępu do tych środowisk ani nie wiem, co oznacza ten wyjątek. Patrząc na opis błędu, nie jestem w stanie zrozumieć przyczyny.

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

Czy ktoś mógłby mi doradzić, jak podejść do tego rodzaju problemu?

exceptions

— C4CodeE4Exe
źródło

czy należy to przenieść do StackOverflow? Myślę, że dostaniesz tam więcej odpowiedzi.

— DXM

Jedno słowo: logowanie.

— quant_dev

@DXM - byłoby to nie na temat przepełnienia stosu, ponieważ jest zbyt ogólne. OP poszukuje strategii i technik, a nie konkretnego rozwiązania. Jeśli kod, który zawiódł, został dołączony, być może może on działać na przepełnieniu stosu.

— ChrisF

Z mojego doświadczenia wynika, że większość takich problemów wynika z problemów z konfiguracją zabezpieczeń i może być trudna do zrozumienia. Jak wspomnieli inni, dobre rejestrowanie pomoże to ujawnić.

— jfrankcarr

Odpowiedzi:

Ogólnie rzecz biorąc, lepsze rejestrowanie debugowania. Zastanów się, co chcesz wiedzieć, dodaj go do kodu i umieść w dziennikach, abyś mógł to wypracować. Przechwytywanie większej liczby szczegółów otoczenia w tym czasie również pomaga - jakie żądanie, kiedy itp.

Konkretnie, szukałbym wspólnego wzorca u klientów, który go dotknął - a jeśli znalazłeś jeden optymalizujący - ale następnie przechwyciłem ruch w warstwie TCP.

Przejrzenie wymienianych wiadomości SSL powinno dać ci pojęcie, co dzieje się źle w protokole, a przynajmniej jakie są wspólne właściwości żądania. Gdy już to zrobisz, powinno być bliżej debugowania.

Przypuszczam, że wynika to z jednej z trzech rzeczy:

Coś, co nie jest SSL, rozmawiało z portem SSL. (skanowanie portów jest powszechne, ale zdarza się również HTTP do portu HTTPS).
Klient nie współdzieli akceptowalnego zestawu szyfrów z serwerem.
Klient oferuje certyfikat, a serwer jest w porządku. (Niezbyt często, ale możliwe.)

— Daniel Pittman
źródło

może serwer oferuje samopodpisany certyfikat lub podpisany przez urząd certyfikacji, którego klient nie zna / nie ufa

— Carlos Campderrós,

Wydaje mi się, że widziałem # 3, gdy jedna ze stron wygasła certyfikaty.

— FrustratedWithFormsDesigner

Sporo debugowałem na systemach produkcyjnych. Nigdy nie korzystałem z debugera, zawsze rejestrował lub zapisywał kluczowe wartości w określonej części ekranu.

— Loren Pechtel

dziękuję wszystkim za porady. Jestem pewien, że istnieją pragmatyczne sposoby rozwiązania błędu produkcyjnego.

— C4CodeE4Exe

Zalecam użycie strategii rejestrowania z konfigurowalnym maksymalnym poziomem dziennika. Narzędzie takie jak log4j ( http://logging.apache.org/log4j/ , http://en.wikipedia.org/wiki/Log4j ) może to zrobić.

Konfigurowalny poziom dziennika (lub gadatliwość) jest ważny, aby móc znaleźć przyczynę błędu, być może bez konieczności ponownego instalowania oprogramowania.

Jeśli taka strategia nie wystarczy, aby znaleźć błąd, spróbuj znaleźć sposób tworzenia / odczytywania dzienników tworzonych przez aplikacje, z którymi się komunikujesz.

Możesz także wdrożyć jakiś mechanizm, aby automatycznie otrzymywać więcej informacji o błędach przez e-mail.

Mówiąc bardziej ogólnie, możesz przeczytać kilka artykułów na temat oprzyrządowania, które jest większym tematem obejmującym rejestrowanie i śledzenie.

— PL
źródło