Что означает `maxReserveABLSessionWaitTime`?

Хорошая тема для разбора! Давайте разберём эту метрику – она действительно помогает ловить узкие места.

Эта метрика показывает максимальное время, которое какая-либо ABL-сессия провела в очереди, ожидая освобождения ресурса (то есть пока система резервировала для неё сессию). Проще говоря: запрос пришёл, но сразу выполнить его не получилось – пришлось подождать, пока освободится «слот» в пуле сессий. Эта метрика фиксирует самый долгий такой случай за период сбора данных.

Как это работает в системе

Когда клиент отправляет запрос, система пытается зарезервировать для него ABL-сессию. Если все сессии в пуле сейчас заняты, то новый запрос встаёт в очередь. Время, которое он проводит в этой очереди до того, как получит сессию, и фиксируется в этой метрике.

Где посмотреть и как включить

Чтобы эта метрика появилась в мониторинге, нужно настроить сбор runtime-метрик в PAS. В файле openedge.properties есть параметр collectMetrics. Чтобы увидеть временные метрики (в том числе maxReserveABLSessionWaitTime), установим значение 2. При значении 1 будут только счётчики (например, сколько раз происходил таймаут при резервировании), а при 2 – уже временные показатели.

Как интерпретировать значения

Значение близко к нулю или равно нулю – система справляется: ресурсы освобождаются быстро, очередей почти нет.
Появляются небольшие значения (например, несколько сотен миллисекунд) – это может быть нормой под пиковой нагрузкой, но стоит понаблюдать.
Высокие или растущие значения – тревожный сигнал. Это говорит о том, что пул ABL-сессий слишком мал для текущей нагрузки: запросы постоянно встают в очередь, и пользователи испытывают задержки.

Что делать, если метрика растёт?

Проверить настройки агентов. Возможно, стоит увеличить maxABLSessionsPerAgent (размер пула сессий на агента), чтобы было больше «свободных слотов» для одновременной обработки запросов.
Проанализировать нагрузку. Посмотри, в какие моменты возникают пики. Иногда проблема не в абсолютном размере пула, а в том, что нагрузка распределена неравномерно.
Посмотреть сопутствующие метрики. Полезно смотреть в паре с numReserveABLSessionWaits (количество событий ожидания) и numReserveABLSessionTimeouts (количество таймаутов). Если растёт только max..., но num... не растёт – возможно, это единичные «просадки». А если все три метрики растут синхронно – это явный признак системной проблемы.
Оценить ресурсы сервера. Иногда причина не в настройках PAS, а в том, что сам сервер (CPU, память, диск, база данных OpenEdge) не справляется с нагрузкой, из-за чего операции резервирования замедляются.

В документации Progress (например, в разделе Collect runtime metrics или Get runtime metrics) эта метрика описана именно как показатель времени ожидания при резервировании сессии.

Отлично, раз уж мы разобрали maxReserveABLSessionWaitTime, давайте посмотрим на другие runtime-метрики PAS for OpenEdge. Я сгруппировал их по смыслу – так проще понять, за что каждая отвечает и когда её стоит отслеживать.

Метрики пула сессий и очередей

Эти показатели помогают понять, не становится ли узким местом резервирование сессий.

numReserveABLSessionWaits – количество случаев, когда запросу пришлось подождать в очереди, пока освободится ABL-сессия.
numReserveABLSessionTimeouts – количество таймаутов при резервировании сессии. Если эта метрика растёт, значит, система регулярно не успевает выделить сессию за отведённое время – это серьёзный сигнал.
maxConcurrentClients – максимальное число одновременно подключённых клиентов за период.
maxQueueDepth – максимальная глубина очереди запросов (сколько запросов ждало обработки одновременно).

Метрики времени выполнения

Они показывают, сколько времени занимают разные этапы обработки запроса.

avgReserveABLSessionWaitTime – среднее время ожидания сессии перед выполнением.
totReserveABLSessionWaitTime — суммарное время, которое все сессии провели в ожидании.
maxAgentReadTime – максимальное время, которое заняло чтение ответа от агента.
avgAgentReadTime, minAgentReadTime – среднее и минимальное время чтения ответа.
stdDevAgentReadTime – стандартное отклонение времени чтения ответа. Большое значение говорит о нестабильности: иногда ответ приходит быстро, иногда сильно задерживается.

Метрики для транспортов

PAS поддерживает разные транспорты (SOAP, REST, WEB), и для каждого есть свои метрики.

Для SOAP:
- minTotalTime, avgTotalTime, maxTotalTime – минимальное, среднее и максимальное время выполнения SOAP-запроса (от клиента до PAS и обратно).
- stdDevTotalTime – стандартное отклонение времени выполнения SOAP-запросов.
Для REST:
- avgConnectTime – среднее время установления соединения.
- maxConnectTime – максимальное время установления соединения.
- avgSessionTime, maxSessionTime – среднее и максимальное время выполнения удалённой процедуры в сессии.
- stdDevConnectTime, stdDevSessionTime – стандартные отклонения для времени соединения и выполнения процедуры.
Для WEB:
- minABLProcessingTime, maxABLProcessingTime – минимальное и максимальное время обработки запроса.
- stdDevABLProcessingTime – стандартное отклонение времени обработки.
- maxABLConnectTime – максимальное время создания соединения ABL через OpenAppObject.

Как интерпретировать

Если numReserveABLSessionWaits или maxQueueDepth растут – вероятно, пул сессий слишком мал для текущей нагрузки. Стоит увеличить maxABLSessionsPerAgent.
Рост numReserveABLSessionTimeouts – тревожный сигнал: система систематически не успевает резервировать сессии. Нужно анализировать причину (нагрузка, настройки таймаутов, узкие места в коде приложения).
Если stdDevAgentReadTime или stdDevTotalTime велики – это говорит о нестабильности. Даже если среднее время в норме, редкие сильные задержки могут раздражать пользователей.
Для транспортов смотрите на maxTotalTime или maxSessionTime: если они значительно выше среднего, ищите отдельные «тяжёлые» запросы или проблемы на стороне клиента/внешних сервисов.

Практический совет

Не пытайтесь мониторить все метрики сразу. Начните с тех, что релевантны вашей задаче:

если есть жалобы на задержки – копайте в сторону времени выполнения и очередей;
если приложение падает – добавьте метрики по ошибкам и таймаутам.

И обязательно настраивайте алерты на аномальный рост (например, если maxQueueDepth превысил пороговое значение или numReserveABLSessionTimeouts стал больше нуля в течение длительного времени).

Как получить runtime-метрики

Чтобы получать runtime‑метрики в PAS for OpenEdge (в т.ч. maxReserveABLSessionWaitTime и сопутствующие), нужно выполнить три шага: включить сбор метрик, перезапустить экземпляр и затем забрать данные одним из поддерживаемых способов.

Шаг 1. Включить сбор метрик в `openedge.properties`

Откройте {CATALINA_BASE}/config/openedge.properties.

Для Session Manager (метрики ABL‑приложения)

В секции [AppServer] задайте параметр collectMetrics:

1 – только счётчики (кол-во событий).
2 – только временные метрики (например, maxReserveABLSessionWaitTime, средние времена).
3 – и счётчики, и временные метрики (наиболее полезно для мониторинга).

Пример:

[AppServer]
collectMetrics=3

Если у вас несколько ABL‑приложений, можно включать метрики отдельно для каждого, указав секцию вида [ABL_app_name] (например, [oepas1]).

Для ABL Web‑приложений (транспорты REST, SOAP, APSV, WEB)

Для каждого веб‑приложения метрики включаются в секции [ABL_app_name.Web_app_name], например:

[oepas1.ROOT]
collectMetrics=3

Это даст метрики по каждому транспорту (REST, SOAP и т.д.) отдельно.

Важно: без перезапуска PAS изменения не применяются.

Шаг 2. Перезапустить экземпляр PAS

После правки openedge.properties обязательно перезапустите PAS‑экземпляр, чтобы настройки вступили в силу.

Шаг 3. Получить метрики

Есть три основных способа, все они описаны в документации Progress.

Способ 1. `REST APIoemanager` (самый удобный для интеграции)

Требуется, чтобы приложение oemanager.war было развернуто в экземпляре PAS.

Примеры запросов:

Метрики Session Manager для ABL‑приложения:

curl -u user:pass "http://host:port/oemanager/applications/oepas1/metrics"

Метрики транспорта REST для веб‑приложения ROOT:

curl -u user:pass "http://host:port/oemanager/applications/oepas1/webapps/ROOT/transports/rest/metrics"

В ответе будет JSON с метриками, включая maxReserveABLSessionWaitTime, numReserveABLSessionWaits, numReserveABLSessionTimeouts и т. п.

Способ 2. `OEJMX`‑запросы (для скриптов и кастомного мониторинга)

Через JMX можно запрашивать те же метрики, что и в REST. Это удобно, если вы уже используете Prometheus JMX‑exporter или пишете свои скрипты (Bash/Python/PowerShell).

Примеры типичных MBean‑объектов (имена могут зависеть от версии и конфигурации):

Session Manager:

com.progress.oe.broker:type=SessionManager,application=oepas1

Транспорты/агенты: по соответствующим типам.

В JMX доступны те же атрибуты: MaxReserveABLSessionWaitTime, счётчики ожиданий и таймаутов.

Способ 3. ProTop / Promon (для оперативного анализа и админки)

ProTop автоматически собирает и показывает ключевые метрики PAS/OpenEdge, в том числе пулы сессий, ожидания, таймауты, очереди. Это самый быстрый способ «на глаз» оценить, есть ли проблемы с резервированием сессий.
Promon полезен для разовых диагностических сессий и глубокого анализа поведения агентов и сессий.

Важные нюансы из документации Progress

Метрики накапливаются с момента последнего сброса (reset). Если вы делаете дашборды, учитывайте, что абсолютные значения счётчиков растут, а временные максимумы (max...) отражают худший случай за этот период.
Есть REST‑эндпоинт для сброса метрик (полезно при старте нового окна анализа).
Если collectMetrics не настроен или равен 0, временные не собираются и не будут доступны ни в REST, ни в JMX, ни в ProTop.

Пример для мониторинга PAS в Linux

Допустим, вы хотите раз в минуту забирать метрики и складывать в Prometheus‑формат или CSV. Минимальный Bash‑шаблон:

URL="http://localhost:16680/oemanager/applications/oepas1/metrics"
USER="admin"
PASS="secret"

curl -s -u "$USER:$PASS" "$URL" | jq '
  {
    maxReserveABLSessionWaitTime: .result.maxReserveABLSessionWaitTime,
    numReserveABLSessionWaits: .result.numReserveABLSessionWaits,
    numReserveABLSessionTimeouts: .result.numReserveABLSessionTimeouts,
    requests: .result.requests
  }
'

Далее вывод можно парсить в Prometheus text‑format, писать в InfluxDB или агрегировать в Bash/Python.

Как сбросить метрики

Сбросить runtime‑метрики в PAS for OpenEdge можно несколькими способами – в зависимости от того, какие именно метрики нужно обнулить (всего приложения и транспорта) и каким инструментом вы пользуетесь.

Через `REST API` (основной способ для автоматизации)

Для сброса используется HTTP‑запрос DELETE к соответствующему эндпоинту oemanager.

Сброс метрик ABL‑приложения (Session Manager)

curl -X DELETE -u user:pass "http://host:port/oemanager/applications/oepas1/metrics"

Это обнулит метрики уровня приложения (в т.ч. maxReserveABLSessionWaitTime, счётчики ожиданий и т.п.).

Сброс метрик транспорта (REST/SOAP/APSV/WEB)

# REST
curl -X DELETE -u user:pass "http://host:port/oemanager/applications/oepas1/webapps/ROOT/transports/rest/metrics" 
# SOAP
curl -X DELETE -u user:pass "http://host:port/oemanager/applications/oepas1/webapps/ROOT/transports/soap/metrics" 
# APSV / WEB — аналогично, подставьте нужный тип транспорта

Формат ответа при успехе обычно такой:

{
   "operation":"RESET SESSION-MGR METRICS",
   "outcome":"SUCCESS",
   "result":"",
   "errmsg":"",
   "versionStr":"v12.1.0 ( 2019-08-07 )",
   "versionNo":1
}

Через `JMX` (если мониторинг на базе JMX)

В PAS метрики доступны через MBean’ы, и у них есть операции сброса. Типичный MBean для приложения:

com.progress.oe.broker:type=SessionManager,application=oepas1

У этого MBean есть операция resetMetrics() (имя может немного отличаться в разных версиях). Её можно вызвать:

из JConsole/VisualVM,
через jmxterm,
из скрипта (Java, Python + JMX client и т. п.).

Это удобно, если у вас уже настроен сбор через Prometheus JMX exporter и хочется сбрасывать «изнутри» стека мониторинга.

Важные нюансы

Метрики сбрасываются с момента последнего сброса. Если вы строите графики «в абсолютных счётчиках», то после сброса они начнутся с нуля – это нормально. Для дашбордов лучше использовать дельты (rate/increase) между замерами.
Сброс не влияет на настройки. Параметры вроде maxABLSessionsPerAgent, collectMetrics и т.д. остаются без изменений.
Разные уровни сброса. Метрики приложения и транспорта – это разные наборы. Если нужно «всё сразу», придётся вызвать несколько REST‑эндпоинтов.
Права доступа. Для REST нужен пользователь с правами менеджера (обычно тот же, что и для просмотра метрик). Для JMX – соответствующие привилегии в PAS.

Когда и зачем сбрасывать

Перед нагрузочным тестом – чтобы метрики отражали только период теста, а не «хвост» прошлой нагрузки.
При смене конфигурации (например, после увеличения maxABLSessionsPerAgent) – чтобы видеть эффект именно от новых настроек.
Для упрощения интерпретации при ручном анализе: проще смотреть «чистые» метрики за короткий интервал.

Как интерпретировать runtime-метрики в PAS for OpenEdge

Что означает `maxReserveABLSessionWaitTime`?

Как это работает в системе

Метрики пула сессий и очередей

Метрики времени выполнения

Метрики для транспортов

Как интерпретировать

Практический совет

Как получить runtime-метрики

Шаг 1. Включить сбор метрик в `openedge.properties`

Для Session Manager (метрики ABL‑приложения)

Для ABL Web‑приложений (транспорты REST, SOAP, APSV, WEB)

Шаг 2. Перезапустить экземпляр PAS

Шаг 3. Получить метрики

Способ 1. `REST APIoemanager` (самый удобный для интеграции)

Способ 2. `OEJMX`‑запросы (для скриптов и кастомного мониторинга)

Способ 3. ProTop / Promon (для оперативного анализа и админки)

Важные нюансы из документации Progress

Пример для мониторинга PAS в Linux

Как сбросить метрики

Через `REST API` (основной способ для автоматизации)

Сброс метрик ABL‑приложения (Session Manager)

Сброс метрик транспорта (REST/SOAP/APSV/WEB)

Через `JMX` (если мониторинг на базе JMX)

Важные нюансы

Когда и зачем сбрасывать

Как настроить maxConnectionsPerAgent и maxABLSessionsPerAgent для экземпляра PASOE

Есть вопрос? Спросите... Отменить ответ

Что означает maxReserveABLSessionWaitTime?

Как это работает в системе

Метрики пула сессий и очередей

Метрики времени выполнения

Метрики для транспортов

Как интерпретировать

Практический совет

Как получить runtime-метрики

Шаг 1. Включить сбор метрик в openedge.properties

Для Session Manager (метрики ABL‑приложения)

Для ABL Web‑приложений (транспорты REST, SOAP, APSV, WEB)

Шаг 2. Перезапустить экземпляр PAS

Шаг 3. Получить метрики

Способ 1. REST APIoemanager (самый удобный для интеграции)

Способ 2. OEJMX‑запросы (для скриптов и кастомного мониторинга)

Способ 3. ProTop / Promon (для оперативного анализа и админки)

Важные нюансы из документации Progress

Пример для мониторинга PAS в Linux

Как сбросить метрики

Через REST API (основной способ для автоматизации)

Сброс метрик ABL‑приложения (Session Manager)

Сброс метрик транспорта (REST/SOAP/APSV/WEB)

Через JMX (если мониторинг на базе JMX)

Важные нюансы

Когда и зачем сбрасывать

Вам также может понравиться

Есть вопрос? Спросите... Отменить ответ

Вход через логин и пароль

Регистрация пользователя

Что означает `maxReserveABLSessionWaitTime`?

Шаг 1. Включить сбор метрик в `openedge.properties`

Способ 1. `REST APIoemanager` (самый удобный для интеграции)

Способ 2. `OEJMX`‑запросы (для скриптов и кастомного мониторинга)

Через `REST API` (основной способ для автоматизации)

Через `JMX` (если мониторинг на базе JMX)