Диагностика состояния

Формальная проверка работоспособности приложения

Диагностика состояния включает в себя ряд проверок, в составе формальной проверки работоспособности приложения.

Проверки работоспособности front-end веб-сервера (nginx, apache, IIS)

Проверки выполняются, если используется front-end веб-сервер (nginx, apache, IIS):

  • Проверьте, запущен ли сервер, на котором расположен front-end.
  • Проверьте, запущена ли служба.
  • Просмотрите логи (журнал событий).
  • Подключитесь к приложению по прямой ссылке на Tomcat, минуя front-end.

Проверка доступности сервера приложения

Проверка заключается в проверке доступности сервера приложения и возможности подключения на порт приложения.

Параметры проверки:

  • $servername — имя сервера приложения или IP адрес,
  • $port — порт приложения (или front-end)

Для ОС Linux выполните команды в терминале:

ping $servername
telnet $servername $port

Выполнение вышеуказанных команд позволяет убедиться в том, что сервер доступен и подключение на порт приложения возможно.

Проверка наличия процесса

Проверка процесса заключается в проверке наличия в системе процесса Apache Tomcat в данный момент.

Для ОС Linux выполните команду ps. Работающий сервер приложений Apache Tomcat представляет собой Java-процесс, выполняющий класс org.apache.catalina.startup.Bootstrap с параметром start:

$ ps aux | grep org.apache.catalina.startup.Bootstrap nausd4 16734 60.6 9.3 1210628 372888 pts/3 Sl 10:08 0:16 /opt/nausd4/java/bin/java -Djava.util.logging.config.file=/opt/nausd4/tomcat/conf/logging.properties -server -da -Xms768m -Xmx768m -Dfile.encoding=UTF-8 -XX:MaxPermSize=192m -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true -Dext.prop.dir=/opt/nausd4/conf -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=192.168.224.141 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/opt/nausd4/tomcat/endorsed -classpath /opt/nausd4/java/lib/tools.jar:/opt/nausd4/tomcat/bin/bootstrap.jar:/opt/nausd4/tomcat/bin/tomcat-juli.jar -Dcatalina.base=/opt/nausd4/tomcat -Dcatalina.home=/opt/nausd4/tomcat -Djava.io.tmpdir=/opt/nausd4/tomcat/temp org.apache.catalina.startup.Bootstrap start

Выполнение вышеуказанных действий позволяет убедиться, что процесс Apache Tomcat выполняется в данный момент.

Проверка сетевых портов

При проверке выявляется открытость сетевых портов (по умолчанию 8005, 8009, 8080) и их прослушивание (LISTEN) сервером Apache Tomcat.

Для ОС Linux:

  • выполните в терминале команду netstat

    $ netstat -an | grep LISTEN | grep 8080
    tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN

    в терминале отобразится информация, что порт открыт и прослушивается сервером:

  • выполните в терминале команду fuser

    $ fuser -v 8080/tcp
    USER        PID ACCESS COMMAND
    8080/tcp:            nausd4   16734 F.... java

    в терминале отобразится PID "слушающего" процесса.

Результат выполнения команды отобразится в окне консоли.

Для браузера, чтобы проверить доступность Apache Tomcat зайдите на корневую страницу сервера приложений, используя базовый URL, в случае нормальной работы сервера открывается стартовая страница Apache Tomcat/7.0.22.

Страница не будет отображаться, если:

  • не доступен Apache Tomcat;
  • некорректная настройка перенаправления с базового URL на .../sd/ (невозможно однозначно подтвердить доступность);
  • отсутствует каталог ../tomcat/webapps/ROOT — ошибка 404 (подтверждается доступность порта).

Проверка соединения с базой данных

Проверка соединения с базой данных заключается в обнаружении наличия установленного (ESTABLISHED) соединения с хостом базы данных на соответствующий порт и проверки доступности данного порта с сервера приложения.

Проверка выполняется с помощью команд в терминале (командной строке) аналогично Проверка сетевых портов.

Порт по умолчанию для PostgreSQL — 5432.

Проверка использования ресурсов

В рамках проверки использования ресурсов на серверах приложения и СУБД проверяется:

  • наличие свободного места на диске;
  • использование памяти;
  • загрузка процессора.

Сбор и анализ служебной информации

Анализ лога приложения (sdng.log)

Расположение лога: каталог по умолчанию../logs/sdng.log, точный путь указан в файле log4j2.properties. В случае отсутствия файла, информация будет записываться в ../tomcat/logs/catalina.out.

Выполните проверку лога приложения на наличие ошибок. Поиск ошибок проводится по ключевым словам: ERROR и Caused by, а также по наличию стека ошибки (stack trace).

Пример ошибки, приведшей к падению приложения. Информация об ошибке приводится в сокращении, так как критические ошибки содержат большой объем информации, с сохранением структуры.

Copy
52319 [localhost-startStop-1 - -] (27 фев 2018 13:30:59,054) ERROR context.ContextLoader - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.security.filterChains': .... Failed process metaClass:slmService__Evt
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:359)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:108)
 
....
 
Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"tags"). Expected elements are ....
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:726)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:247)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:242)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:109)
 
....
 
... 148 more
52466 [localhost-startStop-1 - -] (27 фев 2018 13:30:59,201) INFO  server.SpringContextLoaderListener - Shutdown

Анализ лога сборщика мусора (gc.log)

Расположение лога: каталог по умолчанию ../tomcat/logs/gc.log, точный пусть указан в Java опциях, см. Конфигурация производительности Java-машины. Лог может отсутствовать, если он не был включен в Java опциях.

Если настроена ротация, то файл может называться, например, gc.log.<DATA> или gc-<DATA>.log, где DATA — это дата запуска приложения. Если ротация не настроена, то файл будет перезаписываться при перезапуске приложения.

Присутствие в логе Garbage Collector частого срабатывания Full GC (чаще 1-2 раз в час) свидетельствует о нехватке приложению выделенной памяти. Пример лога, при нехватки оперативной памяти.

Copy
102012,091: [GC (Allocation Failure)  1609184K->934640K(1757184K), 0,0206108 secs]
102033,520: [GC (Allocation Failure)  1609968K->936168K(1756672K), 0,0182472 secs]
102045,986: [GC (Allocation Failure)  1612008K->936368K(1757184K), 0,0154273 secs]
...
102062,496: [GC (Allocation Failure)  1612208K->936568K(1756672K), 0,0144282 secs]
102077,456: [GC (Allocation Failure)  1613432K->973365K(1757184K), 0,1088718 secs]
102082,367: [GC (Allocation Failure)  1650229K->1023829K(1698816K), 0,1046733 secs]
102132,016: [GC (Allocation Failure)  1640789K->1057585K(1720832K), 0,0528350 secs]
102151,880: [GC (Allocation Failure)  1674545K->1086725K(1718784K), 0,0664323 secs]
102165,947: [Full GC (Ergonomics)  1086725K->767085K(1742336K), 2,5549589 secs]
102172,916: [GC (Allocation Failure)  1369709K->770173K(1744384K), 0,0206573 secs]
102186,339: [GC (Allocation Failure)  1372797K->770133K(1741312K), 0,0178681 secs]
102212,942: [GC (Allocation Failure)  1373781K->770421K(1743360K), 0,0191809 secs]
...
102232,442: [GC (Allocation Failure)  1374069K->771293K(1742336K), 0,0164079 secs]
102235,895: [GC (Allocation Failure)  1379037K->771645K(1744896K), 0,0137651 secs]
102331,301: [GC (Allocation Failure)  1379389K->771845K(1745408K), 0,0124906 secs]
102300,467: [Full GC (Ergonomics)  1991610K->1954555K(2044416K), 3,5342154 secs]
102304,414: [Full GC (Ergonomics)  1991609K->1958054K(2044416K), 3,5337156 secs]
102308,375: [Full GC (Ergonomics)  1991608K->1955125K(2044416K), 3,4959781 secs]
102311,931: [Full GC (Ergonomics)  1991606K->1955676K(2044416K), 3,5702704 secs]
102315,536: [Full GC (Ergonomics)  1991606K->1954844K(2044416K), 3,2903888 secs]
...
102322,230: [Full GC (Ergonomics)  1991606K->1955094K(2044416K), 3,3101642 secs]
102325,569: [Full GC (Ergonomics)  1991606K->1955018K(2044416K), 3,6425242 secs]
102329,284: [Full GC (Ergonomics)  1991606K->1954132K(2044416K), 3,3916315 secs]
102332,722: [Full GC (Ergonomics)  1991606K->1955206K(2044416K), 3,4654606 secs]
102336,257: [Full GC (Ergonomics)  1991606K->1955071K(2044416K), 3,2115753 secs]
102339,689: [Full GC (Ergonomics)  1991606K->1953717K(2044416K), 3,4246289 secs]
102343,852: [Full GC (Ergonomics)

Анализ логов Apache Tomcat

Расположение логов: каталог ../tomcat/logs/

Выполните проверку логов на наличие ошибок в следующем порядке:

  1. catalina.out;
  2. localhost.log (может быть в формате "localhost.$DATA.log", где $DATA — текущая дата);
  3. прочие логи.

Сбор служебной информации

Сбор служебной информации необходимо производить до перезапуска приложения и в момент наличия проблемы.

Подробное описание см. Сбор служебной информации для анализа ошибок

Отправка информации об ошибке в техподдержку

Если после выполнения формальной проверки работоспособности приложения не удалось выявить и устранить причину проблемы, то:

  • Соберите информацию о проблеме до перезапуска приложения! (при перезапуске приложения часть логов может перезаписаться) и скопируйте в отдельное место:

    • Логи (sdng.log, gc.log, логи Apache Tomcat).
    • Стеки потоков.
    • Дамп памяти.

    При необходимости приложение можно перезапустить.

  • Предоставьте информацию для диагностики проблемы в клиентский сервис ITSM 365.

Рекомендации по анализу логов и стеков потоков в данной статье не приводятся.