Мониторинг IBM WebSphere Application Server (WAS) с помощью Proto Observability

На этой странице:

• Сбор метрик IBM WAS
  • Конфигурация IBM WAS
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка
  • Собираемые метрики
    • Лейблы
    • JVM
    • Пулы потоков (Thread Pools)
    • JDBC connection pools
    • Сессии сервлетов (Servlet Session Manager)
    • Доступность
  • Ключевые метрики для дашбордов и алертов
• Сбор логов IBM WAS
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка

Сбор метрик IBM WAS

Интеграция ibm_was собирает PMI-статистику (Performance Monitoring Infrastructure) сервера приложений через PerfServlet — небольшое веб-приложение, которое отдаёт PMI-счётчики в виде XML по HTTP:

http://<host>:9080/wasPerfTool/servlet/perfservlet

Это не JMX-интеграция: агент делает обычный HTTP-запрос и парсит XML. Поэтому образу агента не нужен суффикс -jmx — JRE для этой интеграции не требуется.

Поддерживается IBM WebSphere Application Server traditional (8.5.5 и 9.0.x). Для WebSphere Liberty PMI через PerfServlet недоступен — там метрики снимаются по-другому (через openmetrics-эндпоинт фичи mpMetrics); этот вариант здесь не рассматривается.

Конфигурация IBM WAS

Нужно сделать две вещи: развернуть PerfServlet и убедиться, что PMI включён.

• Способ настройки:
• Админ-консоль / wsadmin
• Docker (websphere-traditional)

import java.lang.System as System

ear = System.getProperty('was.install.root') + '/installableApps/PerfServletApp.ear'
AdminApp.install(ear, ['-appname', 'PerfServletApp', '-usedefaultbindings'])
AdminConfig.save()
# Если серверов несколько — добавьте явный
#   -MapModulesToServers [[ perfservlet perfServletApp.war,WEB-INF/web.xml WebSphere:cell=<cell>,node=<node>,server=<server> ]]

# Персистентно — в конфиге сервера:
serverId = AdminConfig.getid('/Cell:DefaultCell01/Node:DefaultNode01/Server:server1/')
pmi = AdminConfig.list('PMIService', serverId)
AdminConfig.modify(pmi, [['enable', 'true'], ['initialSpecLevel', 'all']])
AdminConfig.save()

# И в рантайме (на запущенном сервере) — через PerfMBean:
perf = AdminControl.completeObjectName('type=Perf,*')
AdminControl.invoke(perf, 'setStatisticSet', '[extended]', '[java.lang.String]')

FROM icr.io/appcafe/websphere-traditional:latest

# (необязательно) зафиксировать пароль администратора вместо случайного
COPY --chown=1001:0 PASSWORD /tmp/PASSWORD

# (необязательно) простой текстовый лог вместо HPEL/JSON
ENV ENABLE_BASIC_LOGGING=true

# скрипт деплоя PerfServlet + включения PMI
COPY --chown=1001:0 deploy-perfservlet.py /work/config/deploy-perfservlet.py

RUN env JVM_EXTRA_CMD_ARGS=-Xnoloa /work/configure.sh

import java.lang.System as System

# 1. установка PerfServlet (в single-server профиле -usedefaultbindings
#    смапит web-модуль на server1 / default_host; ctx root /wasPerfTool —
#    из application.xml внутри EAR)
ear = System.getProperty('was.install.root') + '/installableApps/PerfServletApp.ear'
AdminApp.install(ear, ['-appname', 'PerfServletApp', '-usedefaultbindings'])
AdminConfig.save()

# 2. PMI -> all (персистентно) + extended (рантайм)
serverId = AdminConfig.getid('/Cell:DefaultCell01/Node:DefaultNode01/Server:server1/')
pmi = AdminConfig.list('PMIService', serverId)
AdminConfig.modify(pmi, [['enable', 'true'], ['initialSpecLevel', 'all']])
AdminConfig.save()

perf = AdminControl.completeObjectName('type=Perf,*')
AdminControl.invoke(perf, 'setStatisticSet', '[extended]', '[java.lang.String]')

<code>websphere-traditional</code> — это «base»/developer-образ WAS traditional (~1.5–2 GB),

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

1. Создайте файл /etc/protoobp-agent/conf.d/ibm_was.d/conf.yaml:

   init_config:
   
   instances:
     - servlet_url: http://localhost:9080/wasPerfTool/servlet/perfservlet
       # service: websphere          # тег service для метрик и логов
       # username: <user>            # если PerfServlet за basic-auth
       # password: <password>
       # tls_verify: false           # если PerfServlet за HTTPS с self-signed
   

2. Перезапустите агента: systemctl restart protoobp-agent.

По умолчанию интеграция собирает четыре группы счётчиков: jvm, jdbc, servlet_session, thread_pools. Любую из них можно отключить параметром collect_<группа>_stats: false (например, collect_jdbc_stats: false). Дополнительные XML-атрибуты PMI можно вытащить через custom_queries.

Если агент запускается в виде Docker контейнера

Добавьте autodiscovery-лейблы к контейнеру WAS. В docker-compose.yaml:

labels:
  com.protoobp.ad.check_names: '["ibm_was"]'
  com.protoobp.ad.init_configs: '[{}]'
  com.protoobp.ad.instances: '[{"servlet_url": "http://%%host%%:9080/wasPerfTool/servlet/perfservlet", "service": "websphere"}]'

%%host%% агент подставит сам — это IP контейнера WAS в docker network.

Проверка

Убедитесь, что проверка запустилась и собирает метрики:

docker exec protoobp-agent agent status | grep -A 11 "^    ibm_was"

Ожидаемый вывод — Instance ID помечен [OK], а Metric Samples за прогон больше нуля:

    ibm_was (2.3.0)
    ---------------
      Instance ID: ibm_was:xxxxxxxxxxxxxxxx [OK]
      Configuration Source: container:docker://...
      Total Runs: 13
      Metric Samples: Last Run: 74, Total: 816
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 13
      Average Execution Time : 44ms
      Last Successful Execution Date : ...

Также можно открыть PerfServlet прямо в браузере или curl‘ом — должен вернуться XML:

curl -s http://localhost:9080/wasPerfTool/servlet/perfservlet | head
# <?xml version="1.0" encoding="UTF-8"?>
# <!DOCTYPE PerformanceMonitor SYSTEM "/wasPerfTool/dtd/performancemonitor.dtd">
# <PerformanceMonitor responseStatus="success" version="9.0.5.27">
# <Node name="DefaultNode01">
# <Server name="server1">
# <Stat name="server"> ...

Собираемые метрики

Все метрики собираются по HTTP с PerfServlet и имеют тип gauge — содержат мгновенное значение на момент сбора. (PMI-счётчики типа CountStatistic интеграция отправляет как count, DoubleStatistic — как rate, но в наборе по умолчанию таких среди перечисленных ниже нет.) Типы и единицы измерения — согласно документации интеграции.

Лейблы

Добавляются агентом, ProtoOBP backend’ом и самой интеграцией:

JVM

Группа jvm. Для каждой метрики интеграция дополнительно публикует вариант с суффиксом _gauge (исходные ibm_was_jvm_<имя> помечены как deprecated — используйте _gauge-варианты).

Пулы потоков (Thread Pools)

Группа thread_pools. Несут лейбл thread_pool (WebContainer, Default, ORB.thread.pool, server.startup, …).

JDBC connection pools

Группа jdbc. Несут лейблы provider, dataSource.

Сессии сервлетов (Servlet Session Manager)

Группа servlet_session. Несут лейбл web_application.

Доступность

Ключевые метрики для дашбордов и алертов

Доступность

• ibm_was_can_connect == 0 (или service check ibm_was_can_connect в CRITICAL) — PerfServlet недостижим: сервер упал, приложение PerfServletApp не запущено, PMI выключен или сеть до агента не работает.
• Отсутствие свежих серий по instance — то же самое (агент не получает метрик).

Насыщение пулов потоков

• ibm_was_thread_pools_percent_maxed per thread_pool близок к 100 — пул (особенно WebContainer) исчерпан, запросы встают в очередь.
• ibm_was_thread_pools_declaredthread_hung_count > 0 или ibm_was_thread_pools_concurrent_hung_thread_count > 0 — есть «зависшие» потоки (долгие операции, дедлоки, медленные внешние вызовы).

Исчерпание JDBC connection pool

• ibm_was_jdbc_percent_used / ibm_was_jdbc_percent_maxed стабильно высокие per dataSource — пул на пределе.
• ibm_was_jdbc_waiting_thread_count > 0 и/или растущий ibm_was_jdbc_wait_time — потоки ждут соединение (узкое место — БД или размер пула).
• ibm_was_jdbc_fault_count > 0 — «фолты»/таймауты при выдаче соединений.

Сессии

• Растущий ibm_was_servlet_session_live_count / active_count без спада — возможна утечка сессий (не инвалидируются) → давление на heap.
• ibm_was_servlet_session_no_room_for_new_session_count > 0 — отказы в создании сессий (превышен лимит).

JVM

• ibm_was_jvm_used_memory_gauge стабильно близок к ibm_was_jvm_heap_size_gauge — heap на пределе (риск OutOfMemoryError, длинные GC-паузы).
• Высокий ibm_was_jvm_process_cpu_usage_gauge — CPU bound.
• Сброс ibm_was_jvm_up_time_gauge к нулю — сервер перезапустился.

Латентность веб-уровня

• ibm_was_thread_pools_active_time (для WebContainer) — рост = запросы обрабатываются дольше; коррелирует с насыщением пула и нагрузкой на JDBC.

Сбор логов IBM WAS

Логи WAS собираются ProtoOBP агентом и отправляются в бэкенд ProtoOBP. Здесь — только специфичные для WAS настройки. Включение логов на стороне агента (logs_enabled, logs_pobp_url) описано в Получение данных логов.

WAS пишет логи в каталог ${WAS_PROFILE_ROOT}/logs/<имя_сервера>/ (для standalone-профиля — <WAS_INSTALL_ROOT>/profiles/AppSrv01/logs/server1/). В режиме basic logging это текстовые файлы SystemOut.log и SystemErr.log, плюс native_stdout.log / native_stderr.log (вывод самой JVM). В режиме HPEL (High Performance Extensible Logging — включён по умолчанию в образе websphere-traditional) логи хранятся в бинарном репозитории (logdata/, tracedata/) — их нельзя читать как обычные файлы; для сбора через агента переключитесь на basic logging (ENABLE_BASIC_LOGGING=true в образе, или Logging and Tracing → <сервер> → Change log detail levels / logViewer).

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

Дополните уже существующий /etc/protoobp-agent/conf.d/ibm_was.d/conf.yaml (тот же файл, в котором лежит instances:) блоком logs::

logs:
  - type: file
    path: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/SystemOut.log
    source: ibm_was
    service: websphere
    log_processing_rules:
      - type: multi_line
        name: log_start_with_date
        pattern: \[\d{1,2}/\d{1,2}/\d{2,4}
  - type: file
    path: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/SystemErr.log
    source: ibm_was
    service: websphere
    log_processing_rules:
      - type: multi_line
        name: log_start_with_date
        pattern: \[\d{1,2}/\d{1,2}/\d{2,4}
  - type: file
    path: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/native_stderr.log
    source: ibm_was
    service: websphere

Поправьте пути под свой профиль (PROFILE_NAME, SERVER_NAME). Если включён HPEL — либо переключитесь на basic logging, либо настройте экспорт HPEL в текст (logViewer.sh … -outLog …) и укажите этот файл в path:.

Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

Шаг 1 — включите сбор логов в самом агенте через переменные окружения и смонтируйте директорию JSON-логов docker-демона:

services:
  protoobp-agent:
    environment:
      POBP_LOGS_ENABLED: "true"
      POBP_LOGS_CONFIG_USE_HTTP: "true"
      POBP_LOGS_CONFIG_LOGS_POBP_URL: <protoobp-backend>:<port>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      # Прямое чтение JSON-лог файлов docker-демона быстрее,
      # чем тянуть их через Docker socket API.
      - /var/lib/docker/containers:/var/lib/docker/containers:ro

Шаг 2 — добавьте лейбл com.protoobp.ad.logs к контейнеру WAS. При запуске с ENABLE_BASIC_LOGGING=true образ websphere-traditional транслирует SystemOut.log / SystemErr.log в stdout/stderr контейнера — агент их подхватит:

services:
  websphere:
    labels:
      com.protoobp.ad.logs: '[{"source": "ibm_was", "service": "websphere", "log_processing_rules": [{"type": "multi_line", "name": "log_start_with_date", "pattern": "\\[\\d{1,2}/\\d{1,2}/\\d{2,4}"}]}]'

Проверка

В выводе agent status должен быть раздел Logs Agent со статусом running и источник ibm_was (service websphere) с ненулевым BytesRead:

docker exec protoobp-agent agent status \
  | sed -n '/^==== Logs Agent ====/,/^====/p'