Диагностика состояния
- Формальная проверка работоспособности приложения
- Сбор и анализ служебной информации
- Отправка информации об ошибке в техподдержку
Формальная проверка работоспособности приложения
Диагностика состояния включает в себя ряд проверок, в составе формальной проверки работоспособности приложения.
Проверки работоспособности 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).
Пример ошибки, приведшей к падению приложения. Информация об ошибке приводится в сокращении, так как критические ошибки содержат большой объем информации, с сохранением структуры.
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 раз в час) свидетельствует о нехватке приложению выделенной памяти. Пример лога, при нехватки оперативной памяти.
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/
Выполните проверку логов на наличие ошибок в следующем порядке:
- catalina.out;
- localhost.log (может быть в формате "localhost.$DATA.log", где $DATA — текущая дата);
- прочие логи.
Сбор служебной информации
Сбор служебной информации необходимо производить до перезапуска приложения и в момент наличия проблемы.
Подробное описание см. Сбор служебной информации для анализа ошибок
Отправка информации об ошибке в техподдержку
Если после выполнения формальной проверки работоспособности приложения не удалось выявить и устранить причину проблемы, то:
-
Соберите информацию о проблеме до перезапуска приложения! (при перезапуске приложения часть логов может перезаписаться) и скопируйте в отдельное место:
- Логи (sdng.log, gc.log, логи Apache Tomcat).
- Стеки потоков.
- Дамп памяти.
При необходимости приложение можно перезапустить.
- Предоставьте информацию для диагностики проблемы в клиентский сервис ITSM 365.
Рекомендации по анализу логов и стеков потоков в данной статье не приводятся.