Какие источники можно посмотреть при падении Java приложения

Источники информации при падении Java приложения

Когда Java приложение падает, есть несколько мест, откуда можно получить информацию о причине сбоя. Знание этих источников критично для быстрой диагностики и устранения проблем.

1. Application Logs (Логи приложения)

Первое и самое важное место для поиска информации — это логи приложения.

Логгирование в Spring Boot:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Service
public class UserService {
    private static final Logger logger = LoggerFactory.getLogger(UserService.class);

    public User getUser(Long id) {
        try {
            logger.debug("Fetching user with id: {}", id);
            User user = userRepository.findById(id).orElse(null);
            logger.info("User found: {}", user);
            return user;
        } catch (Exception e) {
            logger.error("Error fetching user", e);  // логируем exception
            throw new UserNotFoundException("User not found");
        }
    }
}

Просмотр логов:

# Для локального приложения
tail -f logs/application.log

# Для Docker контейнера
docker logs -f <container_id>

# Для production (Kubernetes)
kubectl logs -f <pod_name> -c <container_name>

# С фильтрацией
grep "ERROR\|WARN" logs/application.log

2. Exception Stack Trace

Stack trace — это трассировка стека вызовов, которая показывает, где именно произошла ошибка.

java.lang.NullPointerException: Cannot invoke "User.getName()" because "user" is null
    at com.example.service.UserService.printUser(UserService.java:45)
    at com.example.controller.UserController.getUser(UserController.java:20)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod

Читаем stack trace снизу вверх:

1. Корневая причина (root cause) — обычно в самом низу (NullPointerException)
2. Путь ошибки — через какие методы дошли до ошибки
3. Точка падения — конкретная строка (UserService.java:45)

3. System Logs (Системные логи ОС)

Для production сервера:

# Linux syslog
sudo tail -f /var/log/syslog

# Systemd журналы
sudo journalctl -u myapp -f  # -f для real-time

# dmesg (kernel messages)
sudo dmesg | tail

# Out of Memory ошибки
grep -i "java" /var/log/messages

4. Heap Dump и Memory Issues

Если приложение упало из-за нехватки памяти:

# Получить heap dump
jmap -dump:live,format=b,file=heap.bin <pid>

# Анализировать dump
jhat heap.bin

# Просмотр Java процессов
jps -l

# Мониторинг памяти в реальном времени
jstat -gc -h10 <pid> 1000

В коде:

Uncaught Exception Handler для логирования critical ошибок:
Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
    logger.error("Uncaught exception in thread: {}", t.getName(), e);
    // send alert
});

5. Thread Dump

Для диагностики deadlock или зависания приложения:

# Создать thread dump
jstack <pid> > thread_dump.txt

# Или через kill сигнал
kill -3 <pid>  # выведет thread dump в консоль

Анализируем thread dump:

"main" prio=5 tid=0x0....
  java.lang.Thread.State: BLOCKED (on object monitor)
  at com.example.service.DeadlockService.methodA(DeadlockService.java:20)
  - waiting to lock <0x1234> (a java.lang.Object)
  - held by "worker-1" (tid=0x2...)

6. JMX и Monitoring Tools

# Подключиться к приложению через JMX
jconsole <pid>
# или
jvisualvm

# Для remote JVM (production):
java -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=9010 \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false \
     MyApp

7. Application Metrics и APM

В production используются специализированные инструменты:

• Prometheus + Grafana — метрики и мониторинг
• ELK Stack (Elasticsearch, Logstash, Kibana) — централизованное логирование
• New Relic, Datadog, Dynatrace — Application Performance Monitoring
• Jaeger, Zipkin — распределённая трассировка (distributed tracing)

// Пример метрик с Micrometer
@Component
public class CustomMetrics {
    private final MeterRegistry meterRegistry;

    public CustomMetrics(MeterRegistry meterRegistry) {
        this.meterRegistry = meterRegistry;
    }

    public void recordException(Exception ex) {
        meterRegistry.counter(
            "app.exceptions",
            "type", ex.getClass().getSimpleName()
        ).increment();
    }
}

8. Database Logs

Если проблема в БД:

# PostgreSQL
tail -f /var/log/postgresql/postgresql.log

# MySQL
tail -f /var/log/mysql/error.log

# Slow query log
tail -f /var/log/mysql/slow.log

9. GC (Garbage Collection) Logs

Если проблема в сборке мусора:

java -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps \
     -Xloggc:gc.log \
     MyApp

# Анализ GC логов
jstat -gcutil <pid> 1000  # каждую секунду

10. Core Dump (Linux)

Для серьёзных сбоев:

# Включить core dumps
ulimit -c unlimited

# Анализировать core dump
gdb -c core.dump java

Алгоритм диагностики при падении

1. Проверь свежие логи приложения (tail -f)
2. Поищи Exception и Stack Trace
3. Проверь системные логи (dmesg, syslog)
4. Смотри на нехватку ресурсов: память (free -h), CPU (top)
5. Если зависание → thread dump (jstack)
6. Если утечка памяти → heap dump (jmap)
7. Если медленное выполнение → профайлер (JFR, JProfiler)
8. Проверь зависимости: БД доступна? API online? Сеть работает?

Лучшие практики логирования

// ✅ Правильно
logger.error("Error processing user ID: {}", userId, exception);

// ❌ Неправильно
logger.error("Error: " + exception.getMessage());  // string concat
logger.error(exception.toString());  // потеря stack trace

// ✅ Разные уровни логирования
logger.debug("Entering method with parameters: {}", params);
logger.info("Operation completed successfully");
logger.warn("Retry attempt {} failed", retryCount);
logger.error("Critical error occurred", exception);