Помилки проксі в Spring WebClient: реактивна обробка проти журналювання
Розрізняйте реактивний сигнал помилки WebClient, журналювання транспорту та обробку статусу HTTP під час збою проксі.
Транспорт може записати в журнал невдале проксі-з'єднання, тоді як застосунок також отримує й обробляє реактивну помилку. Сам запис у журналі не доводить, що обробник застосунку було пропущено.
Відстежуйте сигнал помилки в ланцюгу, на який справді підписуються. try/catch навколо коду, що лише створює Mono, — це інша сфера, ніж обробка пізнішого збою мережі.
| Оператор | Ефект |
|---|---|
| doOnError | Виконує побічний ефект, поки помилка триває |
| onErrorMap | Перетворює одну помилку на іншу |
| onErrorResume | Перемикається на альтернативний видавець |
Виберіть поведінку, потрібну застосунку. Запис метрики не вимагає повертати підроблений успішний вміст. Альтернативна відповідь має бути свідомим результатом застосунку, а не способом приховати невдалий маршрут.
Також розрізняйте винятки транспорту та отримані статуси помилки HTTP. Проксі-з'єднання може зазнати невдачі ще до появи звичайної відповіді призначення, тож обробнику статусу HTTP може не бути чого перевіряти. Зберігайте причину WebClientRequestException під час діагностики нижчого збою.
Коригуйте журналювання лише після розуміння результату. Повне вимкнення журналу транспорту може прибрати докази, потрібні для пізнішого тайм-ауту, проблеми TLS або збою автентифікації, не змінюючи поведінки реактивного конвеєра.