Мониторинг WebLogic с помощью Proto Observability

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

• Сбор метрик WebLogic
  • Конфигурация WebLogic
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка
  • Собираемые метрики
    • Лейблы
      • Общие (на всех метриках)
      • Специфичные для WebLogic (из имён MBean’ов)
    • Метрики
      • JVM
      • Сервер и сокеты
      • Пул потоков (ThreadPoolRuntime)
      • Work manager’ы
      • Веб-приложения и сервлеты
      • Каналы сервера (ServerChannelRuntime)
      • JMS
      • Пулы соединений ресурс-адаптеров (ConnectorConnectionPoolRuntime)
    • Расширение набора метрик
  • Ключевые метрики для дашбордов и алертов
• Сбор логов WebLogic
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы на хосте
    • Если агент запускается в виде Docker контейнера
  • Проверка

Сбор метрик WebLogic

Интеграция weblogic собирает метрики через JMX — опрашивает Runtime MBean’ы домена в namespace com.bea:*:

• ServerRuntime — состояние сервера и открытые сокеты;
• JVMRuntime — heap JVM сервера;
• ThreadPoolRuntime — пул self-tuning потоков (self-tuning thread pool): занятые/простаивающие/standby/stuck/hogging-потоки, очередь запросов, throughput;
• WorkManagerRuntime — статистика по work manager’ам приложений;
• ServletRuntime / WebAppComponentRuntime — время выполнения сервлетов, перезагрузки, открытые HTTP-сессии веб-модулей;
• ServerChannelRuntime — сетевые каналы сервера (байты/сообщения/сокеты);
• JMSRuntime — соединения и количество развёрнутых JMS-серверов;
• ConnectorConnectionPoolRuntime — пулы соединений ресурс-адаптеров (JCA).

Конфигурация WebLogic

Проверка опрашивает MBean’ы com.bea:* через стандартный JMX RMI коннектор. Для этого нужны два условия.

1. MBean server WebLogic’а должен быть platform MBean server’ом. Стандартный com.sun.management.jmxremote-коннектор экспонирует только platform MBean server, а WebLogic по умолчанию держит свои Runtime MBean’ы в отдельном Runtime MBean Server — com.bea:* через jmxrmi так не видны. Решает системное свойство

-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder

— оно делает MBean server WebLogic’а platform MBean server’ом; после этого все com.bea:* MBean’ы доступны через стандартный коннектор. Атрибуты PlatformMBeanServerEnabled / PlatformMBeanServerUsed при этом должны быть true — в WebLogic 12.2.1.4 и 14.1.1 это значение по умолчанию (подтвердить можно в консоли: Domain → Configuration → General → Advanced → Platform MBean Server Enabled / Platform MBean Server Used; на более старых версиях включить там же или через WLST: startEdit() → cmo.setPlatformMBeanServerUsed(true) → activate()).

2. Запущен стандартный JMX RMI server. Включается JVM-флагами -Dcom.sun.management.jmxremote.*. Для установки на хост добавьте оба набора флагов в <DOMAIN_HOME>/bin/setUserOverrides.sh (его подхватывает setDomainEnv.sh):

# <DOMAIN_HOME>/bin/setUserOverrides.sh
JAVA_OPTIONS="${JAVA_OPTIONS} \
  -Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder \
  -Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=1099 \
  -Dcom.sun.management.jmxremote.rmi.port=1099 \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false \
  -Dcom.sun.management.jmxremote.local.only=false \
  -Djava.rmi.server.hostname=<имя_хоста_или_контейнера>"
export JAVA_OPTIONS

В контейнере (startWebLogic.sh запускает java с переменной окружения ${JAVA_OPTIONS} — значение проносится через SAVE_JAVA_OPTIONS) то же самое пробрасывается через environment::

services:
  weblogic:
    image: javasec/weblogic-12.2.1.4   # неофициальный community-образ, см. alert выше
    # у образа нет ENTRYPOINT/CMD — стартуем WebLogic явно; домен и boot.properties
    # в образе уже есть, учётку запрашивать не нужно
    command: ["bash", "-c", "exec /home/wls/weblogic/user_projects/domains/base_domain/startWebLogic.sh"]
    environment:
      JAVA_OPTIONS: >-
        -Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
        -Dcom.sun.management.jmxremote
        -Dcom.sun.management.jmxremote.port=1099
        -Dcom.sun.management.jmxremote.rmi.port=1099
        -Dcom.sun.management.jmxremote.authenticate=false
        -Dcom.sun.management.jmxremote.ssl=false
        -Dcom.sun.management.jmxremote.local.only=false
        -Djava.rmi.server.hostname=weblogic    # имя сервиса в docker network        
    ports:
      - "7001:7001"   # HTTP listen port — консоль /console, /weblogic/ready
      - "1099:1099"   # JMX RMI

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

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

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

   init_config:
     is_jmx: true
     collect_default_metrics: true
     new_gc_metrics: true
   
   instances:
     - host: localhost
       port: 1099
       # user: username      # если на JMX включена аутентификация
       # password: password
       name: weblogic_instance
       # collect_default_metrics на домене со множеством приложений/сервлетов
       # матчит сотни атрибутов — поднимаем лимит JMXFetch (по умолчанию 350),
       # иначе проверка уходит в WARNING с "Truncating to 350 metrics".
       max_returned_metrics: 2000
       # JMXFetch кэширует список MBean'ов на ~10 минут. Если агент стартует
       # раньше, чем WebLogic зарегистрирует com.bea:* MBean'ы, первые ~10 минут
       # собирались бы только платформенные JVM-метрики — сокращаем интервал.
       refresh_beans: 120
   

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

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

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

labels:
  com.protoobp.ad.check_names: '["weblogic"]'
  com.protoobp.ad.init_configs: '[{"is_jmx": true, "collect_default_metrics": true, "new_gc_metrics": true}]'
  com.protoobp.ad.instances: '[{"host": "%%host%%", "port": "1099", "name": "weblogic_instance", "max_returned_metrics": 2000, "refresh_beans": 120}]'

Проверка

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

docker exec protoobp-agent agent status | grep -A 8 "^    weblogic$"

Ожидаемый вывод — status : OK и metric_count > 0. На реальном домене collect_default_metrics матчит сотни атрибутов (per-servlet / per-work-manager / per-webapp кардинальность), metric_count обычно несколько сотен:

    weblogic
      instance_name : weblogic_instance
      message : <no value>
      metric_count : 353
      service_check_count : 0
      status : OK

На холодном docker compose up первые ~1–2 минуты metric_count может быть ~20 (агент успел просканировать MBean’ы до того, как WebLogic зарегистрировал свои com.bea:*), затем refresh_beans ре-сканирует и значение поднимается до сотен. Это нормально.

Список найденных JMX-атрибутов:

docker exec protoobp-agent agent jmx list collected
docker exec protoobp-agent agent jmx list matching | grep "com.bea"

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

Все метрики собираются по JMX и имеют тип gauge — содержат мгновенное значение на момент сбора. Метрики, у которых в таблицах указан тип rate, интеграция помечает на стороне агента как кумулятивные счётчики (monotonic_count) — backend конвертирует их в rate в секунду.

Лейблы

Общие (на всех метриках)

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

Специфичные для WebLogic (из имён MBean’ов)

metrics.yaml интеграции использует bean_regex без явного блока tags:, поэтому JMXFetch навешивает на каждую метрику лейблы из ключевых свойств имени MBean’а (ObjectName) — с сохранением регистра, как в самом имени. Имена MBean’ов WebLogic выглядят, например, как com.bea:ServerRuntime=AdminServer,Name=ThreadPoolRuntime,Type=ThreadPoolRuntime или com.bea:ServerRuntime=AdminServer,Name=FileServlet,ApplicationRuntime=consoleapp,Type=ServletRuntime,WebAppComponentRuntime=AdminServer_/console, поэтому встречаются лейблы:

Метрики

JVM

MBean JVMRuntime. Несут ServerRuntime, Name=<server>, Type=JVMRuntime.

При включённом new_gc_metrics: true дополнительно собираются стандартные JVM-метрики GC и памяти из platform MBean’ов (jvm_gc_minor_collection_count, jvm_gc_major_collection_count, jvm_heap_memory, jvm_non_heap_memory, jvm_thread_count, …).

Сервер и сокеты

MBean’ы ServerRuntime и Server (конфигурационный). Несут Name=<server>, Type=ServerRuntime / Server.

Состояние сервера (RUNNING / ADMIN / STANDBY / SHUTTING_DOWN …) текущая интеграция как отдельную числовую метрику не собирает — индикатором доступности служит сам факт наличия свежих JMX-метрик по instance (см. «Ключевые метрики для дашбордов и алертов»). Числовое состояние при необходимости добавляется кастомным conf-блоком (см. Расширение набора метрик).

Пул потоков (ThreadPoolRuntime)

MBean ThreadPoolRuntime (self-tuning thread pool). Несут ServerRuntime, Name=ThreadPoolRuntime, Type=ThreadPoolRuntime.

Work manager’ы

MBean WorkManagerRuntime (по одному на work manager приложения). Несут ServerRuntime, ApplicationRuntime, Name=<work_manager>, Type=WorkManagerRuntime.

Веб-приложения и сервлеты

MBean’ы WebAppComponentRuntime и ServletRuntime (по одному на сервлет веб-модуля). Несут ServerRuntime, ApplicationRuntime, Name, WebAppComponentRuntime (для сервлетов), Type.

Среднее время отклика сервлета считается как weblogic_servlet_runtime_exec_time_total / <число вызовов> — счётчик числа вызовов (InvocationTotalCount) в дефолтный набор не входит, при необходимости добавляется кастомным conf-блоком.

Каналы сервера (ServerChannelRuntime)

MBean ServerChannelRuntime (по одному на сетевой канал сервера). Несут ServerRuntime, Name=<channel> (например, Default[http][1], Default[iiop]), Type=ServerChannelRuntime.

JMS

MBean JMSRuntime (на сервер). Несёт ServerRuntime, Name=<server>.jms, Type=JMSRuntime.

Метрики уровня JMS-сервера (messages_current / messages_pending) и назначения (destination_messages_*, consumers_current) в дефолтный набор проверки weblogic не входят — для них при необходимости добавьте кастомный conf-блок на MBean’ы JMSServerRuntime / JMSDestinationRuntime (см. Расширение набора метрик).

Пулы соединений ресурс-адаптеров (ConnectorConnectionPoolRuntime)

MBean ConnectorConnectionPoolRuntime (пулы соединений JCA ресурс-адаптеров). Несут ServerRuntime, ApplicationRuntime, ConnectorComponentRuntime, Name, Type=ConnectorConnectionPoolRuntime.

Пулы соединений JDBC-датасорсов (JDBCDataSourceRuntimeMBean — ActiveConnectionsCurrentCount, WaitingForConnectionCurrentCount, LeakedConnectionCount, ConnectionDelayTime, …) и метрики JTA-транзакций (JTARuntimeMBean — TransactionTotalCount, TransactionCommittedTotalCount, TransactionRolledBackTotalCount, TransactionTimeoutTotalCount, …) в дефолтный набор проверки weblogic не входят. Если они нужны — добавьте их кастомным conf-блоком (см. ниже).

Расширение набора метрик

collect_default_metrics: true собирает только перечисленные выше атрибуты. Любой другой атрибут MBean’а com.bea:* добавляется в init_config.conf — синтаксис как у других JMX-интеграций:

init_config:
  is_jmx: true
  collect_default_metrics: true
  conf:
    - include:
        domain: com.bea
        bean_regex: 'com.bea:ServerRuntime=([-.\w]+),Name=([-/.\w]+),Type=JDBCDataSourceRuntime'
        attribute:
          ActiveConnectionsCurrentCount:
            alias: weblogic.jdbc.connection_pool.active_connections
          WaitingForConnectionCurrentCount:
            alias: weblogic.jdbc.connection_pool.waiting_for_connection
          LeakedConnectionCount:
            alias: weblogic.jdbc.connection_pool.leaked_connections

Алиасы alias: записываются через точку (weblogic.jdbc.connection_pool.active_connections) — так требует синтаксис JMXFetch; на ProtoOBP backend эти метрики попадут под именами weblogic_jdbc_connection_pool_active_connections, weblogic_jdbc_connection_pool_waiting_for_connection, weblogic_jdbc_connection_pool_leaked_connections (точки заменяются на _).

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

Доступность сервера

• Отсутствие свежих серий по instance (server_runtime:<имя>) — алерт: сервер недоступен или JMX отвалился (агент не получает метрики). Числовое состояние сервера (server_state != RUNNING) при необходимости добавляется кастомным conf-блоком на ServerRuntime.State.

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

• weblogic_threadpool_runtime_threads_hogging / _threads_stuck растут — потоки висят на медленных/зависших запросах.
• weblogic_threadpool_runtime_user_requests_pending или _queue_length > 0 — запросы копятся в очереди (не успевает обрабатывать).
• weblogic_threadpool_runtime_execute_threads_idle → 0 при ненулевой очереди — пул исчерпан.
• weblogic_threadpool_runtime_overload_rejected_requests > 0 — work manager’ы начали отбрасывать запросы.
• weblogic_work_manager_runtime_threads_stuck > 0 / _requests_pending растёт — конкретное приложение упёрлось в свой work manager.

Латентность / трафик

• weblogic_threadpool_runtime_throughput падает при стабильном входящем трафике — деградация обработки.
• weblogic_servlet_runtime_exec_time_total (производная) и _exec_time_high — растущее время выполнения сервлетов.
• weblogic_server_channel_runtime_bytes_received / _bytes_sent, _connections_active — профиль сетевой нагрузки.

Веб-приложения

• weblogic_webapp_component_runtime_sessions_current — резкий рост = утечка сессий или всплеск трафика; обрыв до нуля при ожидаемом трафике = приложение не обрабатывает запросы.
• weblogic_servlet_runtime_reloads_total растёт в проде — нежелательные переразвёртывания.

JVM

• weblogic_jvm_runtime_heap_free_percent стабильно низкий (< 10–15 %) — давление на heap, риск длинных GC-пауз и OutOfMemoryError.
• weblogic_jvm_runtime_heap_size упёрся в weblogic_jvm_runtime_heap_size_max при низком heap_free — heap некуда расти.
• При new_gc_metrics: true — jvm_gc_major_collection_count / jvm_gc_major_collection_time растут = частые full GC.

JMS / JCA-пулы (если используются)

• weblogic_jms_runtime_connections_current == 0 при ожидаемом JMS-трафике — клиенты отвалились.
• weblogic_connector_connection_pool_runtime_connections_free → 0 при высоком _connections_active — пул ресурс-адаптера на грани исчерпания.

Сбор логов WebLogic

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

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

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

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

logs:
  # Server-log managed/admin сервера.
  - type: file
    path: <DOMAIN_HOME>/servers/<SERVER_NAME>/logs/<SERVER_NAME>.log
    source: weblogic
    service: weblogic
    log_processing_rules:
      - type: multi_line
        name: new_log_start_with_marker
        pattern: (\####)?<\w{3} (0?[1-9]|[12][0-9]|3[01]), \d{4}
  # stdout/stderr сервера (если редиректится в файл).
  - type: file
    path: <DOMAIN_HOME>/servers/<SERVER_NAME>/logs/<SERVER_NAME>.out
    source: weblogic
    service: weblogic
    log_processing_rules:
      - type: multi_line
        name: new_log_start_with_marker
        pattern: (\####)?<\w{3} (0?[1-9]|[12][0-9]|3[01]), \d{4}
  # HTTP access log (если включён access logging на сервере).
  - type: file
    path: <DOMAIN_HOME>/servers/<SERVER_NAME>/logs/access.log
    source: weblogic
    service: weblogic
    log_processing_rules:
      - type: multi_line
        name: new_log_start_with_date
        pattern: .*\[\d{2}\/(\w{3}|\w{4})\/\d{4}:\d{2}:\d{2}:\d{2} (\+|-)\d{4}\]

<DOMAIN_HOME> — корень домена (например, /u01/oracle/user_projects/domains/base_domain), <SERVER_NAME> — имя сервера (AdminServer или имя managed-сервера). Доменный лог Admin Server’а лежит рядом — <DOMAIN_HOME>/servers/<ADMIN_SERVER_NAME>/logs/<DOMAIN_NAME>.log.

Перезапустите агента: 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 к контейнеру WebLogic. Агент подхватит stdout/stderr контейнера (WebLogic пишет server-log туда) и пометит записи указанными source и service:

services:
  weblogic:
    labels:
      com.protoobp.ad.logs: '[{"source": "weblogic", "service": "weblogic", "log_processing_rules": [{"type": "multi_line", "name": "log_start_with_date", "pattern": "<\\w{3} \\d"}]}]'

Проверка

В выводе agent status должен быть раздел Logs Agent и в нём источник weblogic со Status: OK и ненулевым BytesRead (наблюдалось: BytesRead: 16233, Lines Combined: 29, MultiLine matches: 33):

docker exec protoobp-agent agent status | awk '/^Logs Agent$/,/^Process Agent$/'