Справочные данные

Содержание

Справочные данные#

Для мониторинга и диагностики Astra Automation необходима информация о доступных метриках платформы и журналах компонентов.

Метрики Automation Controller#

Automation Controller предоставляет метрики с помощью следующего запроса к API Gateway:

GET https://<gateway_address>/api/controller/v2/metrics/

Здесь <gateway_address> – IP-адрес или FQDN Gateway.

В ответе Automation Controller возвращает метрики в формате Prometheus, содержащие сведения о состоянии контроллера, выполняемых заданиях, исполняющих узлах, внутренних очередях обработки событий и служебных подсистемах платформы.

Метрики Automation Controller разделены на следующие группы:

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

Описание метрик каждой группы приведено далее.

Системные метрики#

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

Метрика	Описание
`awx_system_info`	Служебная информация о платформе, включая версию, уникальный идентификатор установки, тип лицензии, дату окончания ее действия и состояние внешнего журналирования.
`awx_organizations_total`	Общее количество организаций, созданных на платформе.
`awx_users_total`	Общее количество учетных записей пользователей.
`awx_teams_total`	Общее количество команд пользователей.
`awx_inventories_total`	Общее количество инвентарных списков, зарегистрированных на платформе.
`awx_projects_total`	Общее количество проектов, в которых хранятся сценарии и другие файлы автоматизации.
`awx_job_templates_total`	Общее количество шаблонов заданий.
`awx_workflow_job_templates_total`	Общее количество шаблонов потоков заданий.
`awx_hosts_total{type="all\|active"}`	Количество управляемых узлов. Тип `all` показывает общее количество узлов, а `active` – количество узлов, доступных для выполнения автоматизации.
`awx_schedules_total`	Общее количество настроенных расписаний запуска заданий и потоков заданий.
`awx_sessions_total{type="all\|user\|anonymous"}`	Количество активных сеансов работы. Тип позволяет отдельно учитывать все сеансы, пользовательские сеансы и анонимные подключения.
`awx_database_connections_total`	Текущее количество подключений к базе данных.

Метрики лицензии#

Метрики лицензии позволяют контролировать использование лицензируемых ресурсов платформы.

Метрика	Описание
`awx_license_instance_total`	Максимальное количество управляемых узлов, разрешенное текущей лицензией.
`awx_license_instance_free`	Количество оставшихся управляемых узлов, которые еще можно взять под управление платформой без превышения лицензионных ограничений.

Метрики заданий#

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

Метрика	Описание
`awx_running_jobs_total`	Количество заданий, которые платформа выполняет в данный момент.
`awx_pending_jobs_total`	Количество заданий, ожидающих назначения на исполняющий узел или начала выполнения.
`awx_status_total{status}`	Количество заданий в каждом состоянии. Метка `status` может принимать следующие значения: `pending`, `waiting`, `running`, `successful`, `failed`, `error`, `canceled`.

Метрики узлов#

Метрики узлов содержат сведения о вычислительных ресурсах и емкости узлов Automation Controller.

Емкость узла – это внутренний расчетный показатель, по которому платформа распределяет задания. Она вычисляется на основе количества CPU и объема памяти узла (настройки SYSTEM_TASK_FORKS_CPU и SYSTEM_TASK_FORKS_MEM) с учетом коэффициента узла capacity_adjustment.

Метрика	Описание
`awx_instance_info`	Служебная информация об узле, включая его название, уникальный идентификатор, тип узла, версию ПО и сведения о применяемых политиках.
`awx_instance_capacity`	Общая расчетная емкость узла, по которой платформа планирует выполнение заданий.
`awx_instance_consumed_capacity`	Часть емкости узла, уже занятая выполняющимися заданиями.
`awx_instance_remaining_capacity`	Оставшаяся свободная емкость узла, доступная для запуска новых заданий.
`awx_instance_cpu`	Количество процессорных ядер, обнаруженных на узле.
`awx_instance_memory`	Объем оперативной памяти узла в байтах.

Метрики очередей событий Redis#

Метрики данной группы помогают контролировать обработку событий, поступающих от выполняемых заданий.

Во время выполнения задания платформа передает сведения о его ходе в виде событий. Сначала платформа помещает события в очередь Redis, затем службы Astra Automation обрабатывают события и сохраняют их в базе данных.

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

Метрика	Описание
`callback_receiver_events_queue_size_redis`	Количество событий, ожидающих обработки в очереди Redis.
`callback_receiver_events_popped_redis`	Общее количество событий, извлеченных из очереди Redis для дальнейшей обработки (счетчик с момента запуска).
`callback_receiver_events_in_memory`	Количество событий, которые уже извлечены из Redis и находятся в памяти приложения до сохранения в базе данных.
`callback_receiver_events_insert_db`	Количество событий, сохраненных в базе данных (счетчик).
`callback_receiver_events_insert_db_seconds`	Суммарное время в секундах, затраченное на операции сохранения событий в базе данных.
`callback_receiver_events_broadcast`	Общее количество событий, переданных другим управляющим узлам кластера.
`callback_receiver_batch_events_errors`	Общее количество ошибок, возникших при пакетном сохранении событий в базе данных.
`callback_receiver_batch_events_insert_db`	Гистограмма количества событий, сохраняемых в базе данных за одну пакетную операцию вставки. В сыром текстовом виде Prometheus отображается как набор связанных строк (`_bucket`, `_sum`, `_count`). При визуализации в Grafana позволяет анализировать распределение размеров пакетов и строить процентили (p50, p95, p99).
`callback_receiver_event_processing_avg_seconds`	Среднее время в секундах от получения события из очереди до завершения его обработки и сохранения в базе данных.

Метрики менеджера задач#

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

Метрика	Описание
`task_manager_tasks_started`	Количество задач, запуск которых был инициирован менеджером задач в ходе последнего цикла работы.
`task_manager_running_processed`	Количество выполняющихся задач, состояние которых было обработано менеджером задач в ходе последнего цикла работы.
`task_manager_pending_processed`	Количество ожидающих задач, рассмотренных менеджером задач для последующего запуска в ходе последнего цикла.
`task_manager_tasks_blocked`	Количество задач, запуск которых был заблокирован из-за ограничений, зависимостей или нехватки доступной емкости узлов в ходе последнего цикла.
`task_manager_get_tasks_seconds`	Время в секундах, затраченное на получение информации о задачах из базы данных в ходе последнего цикла работы менеджера задач.
`task_manager_start_task_seconds`	Время в секундах, затраченное менеджером задач на запуск задач в ходе последнего цикла работы.
`task_manager_process_running_tasks_seconds`	Время в секундах, затраченное менеджером задач на обработку выполняющихся (running) задач в ходе последнего цикла работы.
`task_manager_process_pending_tasks_seconds`	Время в секундах, затраченное менеджером задач на обработку ожидающих (pending) задач в ходе последнего цикла работы.
`task_manager__schedule_seconds`	Время в секундах, затраченное на выполнение последнего полного цикла планирования задач.
`task_manager__schedule_calls`	Количество вызовов (запусков) цикла планирования задач менеджером задач.
`task_manager_commit_seconds`	Время в секундах, затраченное на сохранение изменений в базу данных после последнего цикла работы менеджера задач.
`task_manager_recorded_timestamp`	Временная метка, когда был зафиксирован последний цикл работы менеджера задач.

Метрики менеджера зависимостей#

Менеджер зависимостей (Dependency Manager) отвечает за анализ и разрешение зависимостей между задачами, в том числе внутри потоков заданий. Он определяет, готовы ли задачи к запуску или должны оставаться заблокированными до выполнения предшествующих задач.

Метрики данной группы позволяют оценивать производительность подсистемы обработки зависимостей, выявлять узкие места при работе со сложными workflow и контролировать задержки запуска задач из-за зависимостей.

Метрика	Описание
`dependency_manager_pending_processed`	Количество ожидающих задач, зависимости которых были обработаны менеджером зависимостей в ходе последнего цикла работы.
`dependency_manager_get_tasks_seconds`	Время в секундах, затраченное на получение данных о задачах из базы данных в ходе последнего цикла работы менеджера зависимостей.
`dependency_manager_generate_dependencies_seconds`	Время в секундах, затраченное на формирование и разрешение зависимостей для ожидающих задач в ходе последнего цикла.
`dependency_manager__schedule_seconds`	Время в секундах, затраченное на выполнение последнего полного цикла обработки зависимостей.
`dependency_manager__schedule_calls`	Количество выполненных циклов обработки зависимостей (сколько раз менеджер запускал процедуру `_schedule` после получения блокировки).
`dependency_manager_recorded_timestamp`	Временная метка последнего обновления метрик менеджера зависимостей.

Метрики менеджера потока заданий#

Менеджер потока заданий (Workflow Manager) отвечает за выполнение потоков заданий и управление связями между отдельными заданиями внутри них. Он анализирует граф потока, запускает следующие задания по мере завершения предыдущих, обрабатывает условные ветвления и логику workflow.

Метрики данной группы позволяют контролировать производительность обработки потоков заданий, выявлять задержки при запуске задач внутри потока и оценивать эффективность менеджера.

Метрика	Описание
`workflow_manager_spawn_workflow_graph_jobs_seconds`	Время в секундах, затраченное на запуск задач в составе потоков заданий в ходе последнего цикла работы.
`workflow_manager_get_tasks_seconds`	Время в секундах, затраченное на получение данных о задачах потоков заданий из базы данных в ходе последнего цикла.
`workflow_manager__schedule_seconds`	Время в секундах, затраченное менеджером потока заданий на выполнение последнего полного цикла обработки.
`workflow_manager__schedule_calls`	Количество вызовов (запусков) цикла обработки потоков заданий.
`workflow_manager_recorded_timestamp`	Временная метка последнего обновления метрик менеджера потока заданий.

Метрики диспетчера#

Диспетчер (Dispatcher) отвечает за получение задач от менеджера задач, их распределение по узлам исполнения, обработку обратных вызовов (callbacks) и выполнение других фоновых операций платформы. Он управляет пулом обработчиков (workers), которые непосредственно выполняют задания.

Метрики данной группы позволяют контролировать доступность диспетчера, загруженность обработчиков и эффективность масштабирования.

Метрика	Описание
`dispatcher_availability`	Коэффициент доступности диспетчера (от 0 до 1). Значение 1 означает, что диспетчер был полностью доступен в течение всего интервала измерения.
`dispatcher_pool_active_task_count`	Текущее количество активных задач, обрабатываемых в пуле обработчиков диспетчера.
`dispatcher_pool_max_worker_count`	Максимальное количество обработчиков (workers) в пуле за период наблюдения.
`dispatcher_pool_scale_up_events`	Количество операций автоматического увеличения размера пула обработчиков (scale up).

Метрики внутренних подсистем#

Внутренние подсистемы платформы отвечают за сбор, агрегацию и распространение метрик между узлами кластера. Они обеспечивают эффективный обмен данными мониторинга в распределенной среде с помощью Redis.

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

Метрика	Описание
`subsystem_metrics_pipe_execute_seconds`	Время в секундах, затраченное на сохранение метрик в Redis с помощью конвейера (pipeline) в ходе последнего цикла.
`subsystem_metrics_pipe_execute_calls`	Количество операций сохранения метрик в Redis, выполненных через конвейер.
`subsystem_metrics_send_metrics_seconds`	Время в секундах, затраченное на передачу метрик другим узлам платформы в ходе последнего цикла.

Метрики Private Automation Hub#

Private Automation Hub предоставляет метрики с помощью следующего запроса к собственному API:

GET https://<hub_address>/metrics

Здесь <hub_address> – FQDN или IP-адрес узла Private Automation Hub.

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

Метрики Private Automation Hub разделены на следующие группы:

Метрики коллекций;
Метрики HTTP;
Метрики процесса.

Описание метрик каждой группы приведено далее.

Метрики коллекций#

Метрики данной группы позволяют контролировать операции импорта (публикации) и загрузки коллекций в Private Automation Hub.

Метрика	Описание
`galaxy_api_collection_import_attempts_total`	Общее количество попыток импорта коллекций с момента запуска сервиса Private Automation Hub (счетчик).
`galaxy_api_collection_import_failures_total`	Общее количество неудачных попыток импорта коллекций с момента запуска сервиса (счетчик).
`galaxy_api_collection_import_successes_total`	Общее количество успешно импортированных коллекций с момента запуска сервиса (счетчик).
`galaxy_api_collection_artifact_download_attempts_total`	Общее количество попыток выгрузки артефактов коллекций с момента запуска сервиса (счетчик).
`galaxy_api_collection_artifact_download_failures_total`	Общее количество неудачных попыток выгрузки артефактов коллекций с момента запуска сервиса (счетчик).
`galaxy_api_collection_artifact_download_successes_total`	Общее количество успешных выгрузок артефактов коллекций с момента запуска сервиса (счетчик).

Метрики HTTP#

Метрики HTTP помогают анализировать обращения к графической консоли и API сервиса Private Automation Hub, а также контролировать производительность обработки запросов.

Метрика	Описание
`django_http_requests_total_by_method_total{method}`	Общее количество запросов HTTP, сгруппированных по методам с момента запуска сервиса (счетчик).
`django_http_responses_total_by_status_total{status}`	Общее количество ответов HTTP, сгруппированных по кодам состояния с момента запуска сервиса (счетчик).
`django_http_requests_latency_seconds_by_view_method`	Гистограмма времени обработки запросов HTTP в секундах, сгруппированная по методу и представлению. В сыром текстовом виде Prometheus выглядит как набор связанных метрик (`_bucket`, `_sum`, `_count`). При визуализации в Grafana дает возможность строить графики среднего времени ответа, медианы и различных процентилей (p50, p95, p99).

Метрики процесса#

Метрики данной группы позволяют контролировать потребление вычислительных ресурсов Private Automation Hub.

Метрика	Описание
`process_resident_memory_bytes`	Объем оперативной памяти в байтах, который потребляет Private Automation Hub.
`process_cpu_seconds_total`	Суммарное процессорное время в секундах, затраченное Private Automation Hub с момента его запуска.

Журналы компонентов#

Журналы помогают диагностировать ошибки, анализировать поведение сервисов, расследовать инциденты и отлаживать компоненты. Они дополняют метрики, предоставляя контекст и последовательность событий.

Процессами Automation Controller и Gateway управляет Supervisor (supervisord) – система управления процессами. Поэтому на их узлах помимо основных журналов доступны журналы Supervisor в каталоге /var/log/supervisor/. Они содержат информацию о запуске, перезапусках, выводах процессов и ошибках Supervisor. Private Automation Hub и Event-Driven Automation работают как службы systemd – их служебный вывод доступен через journalctl -u <имя юнита>.

Журналы Automation Controller#

Основные журналы Automation Controller расположены в каталоге /var/log/tower/.

Файл	Назначение	Источник
`tower.log`	Основной журнал работы контроллера: ошибки выполнения заданий, внутренние исключения, работа API, синхронизация проектов и общие события платформы.	Приложение AWX/Tower (основной процесс)
`callback_receiver.log`	Обработка событий, поступающих от запускаемых заданий автоматизации.	Callback Receiver (сервис, управляемый Supervisor)
`dispatcher.log`	Работа диспетчера задач, распределение нагрузки, взаимодействие с исполняющими узлами.	Dispatcher
`job_lifecycle.log`	Жизненный цикл заданий: ожидание, блокировка зависимостями, планирование и запуск.	Подсистема планирования задач
`task_system.log`	Работа фоновых служб и внутренних системных задач.	Внутренние службы AWX
`wsrelay.log`	Взаимодействие между узлами кластера через WebSocket.	WebSocket relay
`syslogng_configurer.log`	Настройка и работа механизма перенаправления журналирования во внешние системы (syslog-ng).	Syslog-ng configurator

Наиболее полезные журналы Supervisor:

awx-uwsgi.log – веб-сервер и API;
awx-daphne.log – ASGI/WebSocket;
awx-dispatcher.log – диспетчер задач;
awx-callback-receiver.log – обработка событий.

Журналы Private Automation Hub#

Файл	Назначение	Источник
`/var/log/galaxy_api_access.log`	Запросы к API сервиса коллекций (методы, пути, пользователи, коды ответов).	Приложение Private Automation Hub
`/var/log/nginx/automationhub.access.log`	Все входящие запросы HTTP к веб-серверу.	NGINX
`/var/log/nginx/automationhub.error.log`	Ошибки веб-сервера NGINX.	NGINX
`/var/log/redis/redis.log`	Работа локального Redis (очереди, кеш).	Redis

Журналы Event-Driven Automation#

Для диагностики Event-Driven Automation просматривайте журналы веб-сервера и локальных служб хранения данных.

Основные журналы:

Файл	Назначение	Источник
`/var/log/nginx/automationedacontroller.access.log`	Входящие запросы HTTP.	NGINX (фронтенд)
`/var/log/nginx/automationedacontroller.error.log`	Ошибки веб-сервера NGINX.	NGINX
`/var/log/redis/redis-platform.log`	Работа платформенного Redis, если узел входит в инвентарную группу `redis` (собственный локальный Redis на узле Event-Driven Automation не устанавливается).	Redis
Журналы активаций сводов правил (в контейнерах активаций)	Поступление событий, обработка правил, выполнение действий, ошибки в сводах правил.	Activation workers (контейнеры, управляемые Event-Driven Automation)

Журналы конкретных активаций сводов правил находятся внутри контейнеров активаций. Для просмотра используйте команду podman logs (от имени пользователя eda) или графическую консоль Astra Automation. В графической консоли Event-Driven Automation также доступна история срабатывания сводов правил и история событий.

Журналы Gateway#

Gateway отвечает за аутентификацию, маршрутизацию и безопасность API. Его основные журналы расположены в каталоге /var/log/astra-automation/gateway/.

Файл	Назначение	Источник
`gateway.log`	Запросы к API Gateway, работа сервера приложений.	Gateway application
`grpc_server.log`	Аутентификация, проверка токенов, перенаправление запросов между компонентами.	gRPC server
`envoy.log`	Работа прокси Envoy (подключения, отключения, маршрутизация). Дополнительно вывод службы systemd `automation-gateway-proxy` доступен командой `journalctl -u automation-gateway-proxy`.	Envoy proxy

Дополнительные журналы:

/var/log/nginx/ – журналы NGINX;
/var/log/supervisor/ – Supervisor.