Диагностика неисправностей

Диагностика неисправностей#

Диагностика неисправностей начинается с определения слоя, на котором возникла проблема.

Оповещение в Prometheus не всегда означает неисправность компонента Astra Automation. Причиной может быть недоступность самого источника метрик, ошибка авторизации, проблема TLS, недоступность экспортера, ошибка маршрутизации или некорректная конфигурация правила оповещения.

Перед анализом прикладного компонента определите, к какой группе относится проблема:

  • Prometheus не может получить метрики или выполнить проверку доступности;

  • Gateway возвращает некорректный агрегированный статус платформы;

  • Automation Controller не запускает задания или накапливает очередь ожидающих заданий;

  • Private Automation Hub возвращает ошибки при импорте коллекций или выгрузке артефактов;

  • Event-Driven Automation недоступен по API состояния;

  • Redis или PostgreSQL деградируют и влияют на обработку событий, задания или интерфейс;

  • на узле или постоянном томе заканчиваются ресурсы.

Такой порядок помогает отделить неисправность мониторинга от неисправности платформы.

Общий порядок диагностики#

Для любого сработавшего оповещения сначала выполните базовые проверки.

Запросы PromQL выполняйте в графической консоли Prometheus или в Grafana Explore:

  • В Prometheus откройте страницу Graph, введите запрос и выполните его.

  • В Grafana откройте страницу Explore, выберите источник данных Prometheus, введите запрос и выполните его.

  1. Определите название сработавшего правила.

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

  2. Определите источник данных.

    Для этого посмотрите метки правила оповещения:

    • job – задание сбора метрик Prometheus;

    • instance – адрес источника данных;

    • component – компонент платформы, если метка добавлена в конфигурации сбора;

    • platform – платформа, к которой относится метрика.

  3. Проверьте, получает ли Prometheus данные от источника.

    Для проверки доступности целей сбора используйте интерфейс Prometheus или API Prometheus:

    curl -s http://localhost:9090/api/v1/targets

    Команда возвращает список целей сбора. В поле health для нужной цели должно быть значение up. Если указано значение down, сначала устраните проблему доступа Prometheus к источнику данных.

  4. Проверьте, есть ли ошибка последнего сбора метрик.

    Для удобного просмотра активных целей выполните следующую команду:

    curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {job: .labels.job, instance: .labels.instance, health: .health, lastError: .lastError}'

    В поле lastError не должно быть ошибок подключения, авторизации, TLS или чтения файла токена.

  5. Определите тип проблемы по ошибке Prometheus.

    Типовые признаки:

    • connection refused – сервис или экспортер не принимает подключения на указанном порту;

    • no route to host – нет сетевой доступности до узла;

    • context deadline exceeded – источник данных отвечает слишком долго или недоступен по сети;

    • server returned HTTP status 401 – не передан токен доступа или токен некорректен;

    • server returned HTTP status 403 – у токена недостаточно прав;

    • certificate verify failed – Prometheus не доверяет сертификату или название сервера не совпадает с сертификатом;

    • permission denied для файла токена – Prometheus или blackbox_exporter не может прочитать файл с токеном.

  6. После восстановления сбора метрик проверьте саму метрику, по которой сработало оповещение.

    Если цель сбора находится в состоянии up, а значение проблемной метрики остается критическим, переходите к диагностике соответствующего компонента Astra Automation.

Проверка доступности Gateway#

Gateway является единой точкой входа к компонентам Astra Automation и предоставляет агрегированный статус платформы. Если Gateway недоступен или возвращает некорректный статус, остальные проверки могут давать неполную картину.

  1. Проверьте агрегированный статус Gateway:

    curl -sk \
  -H "Authorization: Bearer <token>" \
  https://<gateway_address>/api/gateway/v1/status/

    Здесь:

    • <token> – токен доступа с правами чтения;

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

    В корректном ответе общее поле status должно иметь значение good. Для каждого сервиса в массиве services поле status также должно иметь значение good.

    Пример корректного ответа:

    {
  "status": "good",
  "services": [
    {"service_type": "controller", "status": "good"},
    {"service_type": "hub", "status": "good"},
    {"service_type": "eda", "status": "good"},
    {"service_type": "redis", "status": "good"}
  ]
}

  2. Если запрос возвращает 401 или 403, проверьте токен доступа.

  3. Если запрос не получает ответ от сервера, проверьте сетевую доступность Gateway, DNS и TLS.

  4. Проверьте разрешение доменного названия Gateway:

    getent hosts <gateway_address>

    Команда должна вернуть IP-адрес Gateway. Если ответ пустой, проверьте запись в DNS или локальную настройку /etc/hosts.

  5. Проверьте соединение TLS:

    openssl s_client -connect <gateway_address>:443 -servername <gateway_address> </dev/null

    В выводе команды не должно быть ошибок сертификата. Проверьте следующие признаки:

    • срок действия сертификата не истек;

    • значение <gateway_address> соответствует названию в сертификате;

    • цепочка сертификатов доверена узлу мониторинга;

    • соединение завершается без ошибок TLS handshake.

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

  6. Если Gateway возвращает статус, отличный от good, определите неисправный сервис по значению service_type и переходите к диагностике соответствующего компонента.

Метрики Automation Controller недоступны#

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

Проблема может проявляться следующими признаками:

  • цель aa_controller находится в состоянии down в Prometheus;

  • запрос up{job="aa_controller"} возвращает 0;

  • запрос up{component="controller",platform="astra_automation"} возвращает 0 в Kubernetes;

  • в поле lastError для цели сбора указана ошибка авторизации, TLS или подключения.

Для проверки точки доступа метрик Automation Controller выполните следующий запрос:

curl -sk \
  -H "Authorization: Bearer <token>" \
  https://<gateway_address>/api/controller/v2/metrics/ | head

Здесь:

  • <token> – токен доступа с правами чтения;

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

Если команда возвращает строки с метриками Prometheus, точка доступа метрик Automation Controller доступна. В таком случае проверьте конфигурацию Prometheus.

Для проверки конфигурации Prometheus выполните команду:

promtool check config /etc/prometheus/prometheus.yml

Команда должна завершиться без ошибок. Если конфигурация содержит ошибку, исправьте файл /etc/prometheus/prometheus.yml и перезагрузите Prometheus.

Для проверки файла токена выполните команду:

sudo ls -l /etc/prometheus/aa-controller.token

Файл должен существовать и быть доступен пользователю, от имени которого запущен Prometheus. Для пакетной установки Prometheus это обычно пользователь prometheus. Если используется проверка Gateway через blackbox_exporter, пользователь blackbox_exporter также должен иметь право прочитать файл. Для конфигурации из раздела настройки Prometheus это достигается включением пользователя blackbox_exporter в группу prometheus и правами 0640 на файл токена.

Для просмотра пользователя, от имени которого запущен Prometheus, выполните команду:

ps -o user= -C prometheus

Если Prometheus запущен в контейнере, учитывайте пользователя внутри контейнера. Файл токена должен быть доступен именно этому пользователю.

После исправления конфигурации или прав доступа перезагрузите Prometheus:

sudo systemctl reload prometheus

Если перезагрузка конфигурации (reload) не поддерживается текущей установкой, перезапустите сервис:

sudo systemctl restart prometheus

Для проверки результата выполните запрос PromQL:

up{job="aa_controller"}

Значение должно быть равно 1.

Gateway возвращает некорректный статус компонента#

Если Gateway доступен, но в ответе /api/gateway/v1/status/ один из сервисов имеет статус, отличный от good, проблема находится на стороне соответствующего компонента или маршрута от Gateway к нему.

Значение service_type помогает определить дальнейший путь диагностики:

  • controller – проверьте Automation Controller;

  • hub – проверьте Private Automation Hub;

  • eda – проверьте Event-Driven Automation;

  • redis – проверьте Redis и связанные с ним сервисы.

Для развертывания на ВМ проверьте журналы Gateway. Выполните следующие действия:

  1. Проверьте основной журнал Gateway:

    sudo tail -n 200 /var/log/astra-automation/gateway/gateway.log

  2. Проверьте журнал gRPC-сервера Gateway:

    sudo tail -n 200 /var/log/astra-automation/gateway/grpc_server.log

  3. Проверьте журнал Envoy:

    sudo tail -n 200 /var/log/astra-automation/gateway/envoy.log

В журналах не должно быть постоянных ошибок подключения к внутренним компонентам, ошибок разрешения доменных названий, ошибок TLS или ошибок маршрутизации.

Для Kubernetes проверьте маршрутизацию к сервисам Astra Automation. Выполните следующие действия:

  1. Получите список сервисов в пространстве имен Astra Automation:

    kubectl -n astra-automation get svc

  2. Проверьте точки доступа сервисов:

    kubectl -n astra-automation get endpoints

    Для каждого сервиса, к которому должен обращаться Gateway, должна существовать точка доступа с IP-адресом пода (pod). Если список точек доступа пустой, проверьте состояние подов и соответствие меток у сервиса.

  3. Проверьте ресурсы входящего доступа (ingress):

    kubectl -n astra-automation get ingress

    Если ресурс входящего доступа отсутствует или указывает на неверное название узла, проверьте конфигурацию маршрутизации Gateway и Ingress Controller.

Растет очередь ожидающих заданий Automation Controller#

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

  1. Проверьте состояние очереди и емкость в Prometheus или Grafana Explore.

    Выполните следующие запросы PromQL:

    • awx_pending_jobs_total – показывает количество заданий, ожидающих запуска. Если значение растет, Automation Controller не успевает запускать новые задания.

    • awx_running_jobs_total – показывает количество выполняемых заданий. Если ожидающих заданий много, а выполняемых мало, проверьте планирование, группы экземпляров и доступность узлов выполнения.

    • awx_instance_remaining_capacity – показывает свободную емкость узлов. Значение 0 или близкое к 0 на активных узлах означает, что у Automation Controller нет свободной емкости для запуска новых заданий.

    • awx_instance_consumed_capacity / awx_instance_capacity – показывает долю занятой емкости. Значение, близкое к 1, означает почти полную загрузку узла.

    • task_manager_tasks_blocked – показывает количество заблокированных задач. Рост значения указывает, что задачи не могут перейти к выполнению из-за зависимостей, ограничений емкости или проблем планировщика.

  2. Проверьте доступность узлов выполнения.

    Узел выполнения – узел, на котором запускаются задания автоматизации.

  3. Проверьте состояние групп экземпляров.

    Группа экземпляров – логическая группа узлов, на которые Automation Controller может распределять задания.

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

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

    Гибридный узел (hybrid node) – узел, который может совмещать управляющие функции и выполнение заданий.

  6. Проверьте загрузку процессора, использование памяти и задержки дисковой подсистемы на узлах выполнения.

Для развертывания на ВМ проверьте журналы Automation Controller. Каждый журнал проверяйте отдельной командой.

  1. Проверьте журнал жизненного цикла заданий:

    sudo tail -n 200 /var/log/tower/job_lifecycle.log

  2. Проверьте журнал диспетчера:

    sudo tail -n 200 /var/log/tower/dispatcher.log

  3. Проверьте журнал подсистемы задач:

    sudo tail -n 200 /var/log/tower/task_system.log

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

Для Kubernetes проверьте состояние подов Automation Controller.

  1. Получите список подов:

    kubectl -n astra-automation get pods

    Поды, связанные с Automation Controller, должны находиться в состоянии Running.

  2. Проверьте подробное состояние пода Automation Controller:

    kubectl -n astra-automation describe pod <pod_name>

    Здесь <pod_name> – название пода Automation Controller из вывода команды kubectl -n astra-automation get pods. В выводе команды не должно быть постоянных рестартов, ошибок выделения ресурсов, событий OOMKilled и сообщений о невозможности назначить под на узел.

Растет очередь событий Redis#

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

  1. Проверьте очередь событий и скорость обработки в Prometheus или Grafana Explore.

    Выполните следующие запросы PromQL:

    • callback_receiver_events_queue_size_redis – показывает размер очереди событий Redis. Рост значения означает, что обработчик событий не успевает разбирать поступающие события.

    • callback_receiver_event_processing_avg_seconds – показывает среднее время обработки события. Рост значения указывает на деградацию подсистемы обработки событий, PostgreSQL или дисковой подсистемы.

    • callback_receiver_batch_events_errors – показывает ошибки пакетной записи событий. Увеличение значения требует проверки PostgreSQL и журнала callback receiver.

    • callback_receiver_events_insert_db – показывает количество событий, записанных в базу данных. Если очередь растет, а количество записанных событий не увеличивается, проблема может быть связана с callback receiver, PostgreSQL или дисковой подсистемой.

  2. Проверьте PostgreSQL:

    • доступность сервиса;

    • количество подключений;

    • наличие блокировок;

    • задержки запросов;

    • загрузку дисковой подсистемы на узле PostgreSQL.

  3. Проверьте загрузку процессора и памяти на управляющих узлах Automation Controller.

  4. Проверьте задания, которые формируют большой объем вывода.

Для развертывания на ВМ проверьте журнал приемника обратных вызовов (callback receiver):

sudo tail -n 200 /var/log/tower/callback_receiver.log

В журнале не должно быть постоянных ошибок записи событий в базу данных, ошибок подключения к Redis и ошибок пакетной вставки событий.

Для Kubernetes проверьте состояние подов Automation Controller.

  1. Получите список подов:

    kubectl -n astra-automation get pods

  2. Проверьте события пода Automation Controller:

    kubectl -n astra-automation describe pod <pod_name>

    Здесь <pod_name> – название пода Automation Controller. В выводе команды проверьте, нет ли событий OOMKilled, частых рестартов и превышения ограничений ресурсов.

Ошибки импорта или выгрузки артефактов в Private Automation Hub#

Ошибки Private Automation Hub влияют на доступность коллекций, синхронизацию контента и выгрузку артефактов. Проблема может быть связана с самим Private Automation Hub, хранилищем, внешним реестром, сетью, учетными данными или файловой системой.

  1. Проверьте метрики Private Automation Hub в Prometheus или Grafana Explore.

    Выполните следующие запросы PromQL:

    • increase(galaxy_api_collection_import_failures_total{job="aa_hub"}[30m]) – показывает прирост ошибок импорта коллекций за последние 30 минут. Значение больше 0 означает, что необходимо проверить журнал Private Automation Hub и доступность хранилища.

    • increase(galaxy_api_collection_artifact_download_failures_total{job="aa_hub"}[30m]) – показывает прирост ошибок выгрузки артефактов за последние 30 минут. Значение больше 0 требует проверки доступности артефактов, хранилища и внешних реестров.

    • sum by (status) (rate(django_http_responses_total_by_status_total{job="aa_hub"}[5m])) – показывает скорость HTTP-ответов Private Automation Hub по кодам состояния за последние 5 минут. Рост ответов 5xx указывает на ошибку сервера Private Automation Hub или зависимого сервиса. Рост ответов 4xx чаще связан с правами доступа, некорректным запросом или ошибкой авторизации.

  2. Проверьте доступность хранилища, к которому обращается Private Automation Hub.

  3. Проверьте заполнение файловой системы или постоянного тома.

  4. Проверьте доступность внешнего реестра, если используется синхронизация контента.

  5. Проверьте учетные данные для внешнего реестра.

  6. Проверьте сетевую доступность внешнего реестра с узла Private Automation Hub.

Для развертывания на ВМ проверьте журналы Private Automation Hub. Каждый журнал проверяйте отдельной командой.

  1. Проверьте журнал доступа Private Automation Hub:

    sudo tail -n 200 /var/log/galaxy_api_access.log

  2. Проверьте журнал доступа Nginx для Private Automation Hub:

    sudo tail -n 200 /var/log/nginx/automationhub.access.log

  3. Проверьте журнал ошибок Nginx для Private Automation Hub:

    sudo tail -n 200 /var/log/nginx/automationhub.error.log

В журналах проверьте коды 4xx и 5xx, ошибки подключения к хранилищу, ошибки авторизации и ошибки обращения к внешним реестрам.

Для Kubernetes проверьте состояние подов Private Automation Hub.

  1. Получите список подов:

    kubectl -n astra-automation get pods

  2. Проверьте журнал пода Private Automation Hub:

    kubectl -n astra-automation logs <pod_name>

    Здесь <pod_name> – название пода Private Automation Hub.

Event-Driven Automation недоступен по API состояния#

Event-Driven Automation не предоставляет точку доступа метрик Prometheus. Для контроля Event-Driven Automation используйте API состояния, агрегированный статус Gateway, системные метрики узла или пода и журналы компонента.

Для проверки выполните следующие действия:

  1. Проверьте API состояния Event-Driven Automation:

    curl -sk https://<gateway_address>/api/eda/v1/status/

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

    Если запрос возвращает успешный HTTP-ответ, точка доступа состояния Event-Driven Automation доступна. Если запрос не получает ответ или возвращает ошибку, проверьте Gateway, маршрутизацию и состояние Event-Driven Automation.

  2. Проверьте агрегированный статус Gateway:

    curl -sk \
  -H "Authorization: Bearer <token>" \
  https://<gateway_address>/api/gateway/v1/status/

    Здесь <token> – токен доступа с правами чтения.

    Если сервис eda имеет статус, отличный от good, проверьте состояние Event-Driven Automation.

Для развертывания на ВМ проверьте журналы Event-Driven Automation. Выполните следующие действия:

  1. Проверьте журнал доступа Nginx для Event-Driven Automation:

    sudo tail -n 200 /var/log/nginx/automationedacontroller.access.log

  2. Проверьте журнал ошибок Nginx для Event-Driven Automation:

    sudo tail -n 200 /var/log/nginx/automationedacontroller.error.log

  3. Проверьте журнал Redis на узле Event-Driven Automation:

    sudo tail -n 200 /var/log/redis/redis-server.log

Для Kubernetes проверьте состояние подов Event-Driven Automation. Выполните следующие действия:

  1. Получите список подов:

    kubectl -n astra-automation get pods

  2. Проверьте журнал пода Event-Driven Automation:

    kubectl -n astra-automation logs <pod_name>

    Здесь <pod_name> – название пода Event-Driven Automation.

Если Event-Driven Automation доступен, но пользовательские сценарии не работают, проверьте потоки событий и активации правил. Эти проверки относятся к синтетическому мониторингу, так как стандартные метрики Prometheus не показывают успешность пользовательского сценария целиком.

Redis недоступен или работает нестабильно#

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

  1. Проверьте метрики Redis в Prometheus или Grafana Explore.

    Выполните следующие запросы PromQL:

    • redis_up{job="aa_redis"} – показывает доступность Redis с точки зрения экспортера. Значение должно быть равно 1 для каждого Redis-узла. Если значение равно 0, сначала проверьте сам экспортер.

    • redis_memory_used_bytes{job="aa_redis"} – показывает объем памяти, который использует Redis. Используйте результат для поиска узла с повышенным потреблением памяти.

    • redis_memory_used_bytes{job="aa_redis"} / redis_memory_max_bytes{job="aa_redis"} – показывает долю использованной памяти, если для Redis задано ограничение maxmemory. Значение, близкое к 1, означает риск исчерпания доступной памяти.

  2. Если redis_up возвращает 0, проверьте состояние сервиса Redis exporter на ВМ:

    sudo systemctl status redis_exporter

    Сервис должен находиться в состоянии active (running).

  3. Проверьте журнал Redis:

    sudo tail -n 200 /var/log/redis/redis-server.log

    В журнале не должно быть постоянных ошибок подключения, переполнения памяти, отказов записи и ошибок кластера.

  4. Проверьте выражение правила оповещения о памяти Redis.

    Если redis_memory_max_bytes равно 0, ограничение maxmemory не задано. В таком случае правило оповещения о заполнении памяти Redis должно учитывать это условие и не выполнять деление на 0.

    Используйте выражение с проверкой redis_memory_max_bytes:

    redis_memory_max_bytes{job="aa_redis"} > 0
and
redis_memory_used_bytes{job="aa_redis"} / redis_memory_max_bytes{job="aa_redis"} > 0.9

PostgreSQL недоступен или близок к лимитам#

PostgreSQL влияет на интерфейс, запуск заданий, запись событий и работу компонентов Astra Automation. Проблемы PostgreSQL часто проявляются не только как ошибка базы данных, но и как рост очередей, задержки API и ошибки обработки событий.

  1. Проверьте метрики PostgreSQL в Prometheus или Grafana Explore.

    Выполните следующие запросы PromQL:

    • up{job="aa_postgres"} – показывает доступность PostgreSQL exporter. Значение должно быть равно 1. Если значение равно 0, проверьте состояние экспортера.

    • sum(pg_stat_activity_count{job="aa_postgres"}) by (instance) / sum(pg_settings_max_connections{job="aa_postgres"}) by (instance) – показывает долю занятых подключений. Значение, близкое к 1, означает, что PostgreSQL близок к лимиту подключений.

  2. Для развертывания на ВМ проверьте состояние PostgreSQL exporter:

    sudo systemctl status postgres_exporter

    Сервис должен находиться в состоянии active (running). Если экспортер установлен как отдельный сервис systemd с другим названием, используйте название сервиса, указанное при установке.

  3. Проверьте приложения, которые создают большое количество подключений.

  4. Проверьте длительные запросы.

  5. Проверьте блокировки.

  6. Проверьте загрузку дисковой подсистемы.

  7. Проверьте свободное место на файловой системе PostgreSQL.

  8. Проверьте рост таблиц и работу autovacuum.

Для развертывания на ВМ проверьте журнал PostgreSQL.

  1. Если журналы пишутся в systemd journal, выполните команду:

    sudo journalctl -u postgresql -n 200

  2. Если журналы пишутся в файлы, проверьте каталог журналов PostgreSQL:

    sudo ls -lah /var/log/postgresql/

  3. Откройте актуальный файл журнала:

    sudo tail -n 200 /var/log/postgresql/<log_file>

    Здесь <log_file> – название актуального файла журнала PostgreSQL.

Файловая система или постоянный том почти заполнены#

Нехватка места может привести к ошибкам PostgreSQL, Redis, Private Automation Hub, записи журналов и выполнению заданий. При таком оповещении важно определить не только процент заполнения, но и тип данных, которые занимают место.

Для развертывания на ВМ проверьте файловые системы. Выполните следующие действия:

  1. Получите сведения о заполнении файловых систем:

    df -h

    В выводе команды определите точку монтирования с высоким значением в столбце Use%.

  2. Проверьте размер журналов:

    sudo du -xh /var/log | sort -h | tail

  3. Проверьте размер данных в каталоге /var/lib:

    sudo du -xh /var/lib | sort -h | tail

Для Kubernetes проверьте постоянные тома. Выполните следующие действия:

  1. Получите список постоянных томов:

    kubectl -n astra-automation get pvc

  2. Проверьте подробную информацию о постоянном томе:

    kubectl -n astra-automation describe pvc <pvc_name>

    Здесь <pvc_name> – название постоянного тома из вывода команды kubectl -n astra-automation get pvc.

Выполните следующие действия:

  1. Определите точку монтирования или постоянный том, на котором заканчивается место.

  2. Определите, какие данные занимают основной объем: журналы, артефакты заданий, данные PostgreSQL, данные Private Automation Hub или временные файлы.

  3. Для PostgreSQL проверьте рост таблиц, накопление неочищенных строк (dead tuples) и работу autovacuum.

  4. Для Private Automation Hub проверьте объем хранилища коллекций и артефактов.

  5. Для развертывания на ВМ проверьте настройки ротации журналов.

  6. Для развертывания на ВМ расширьте файловую систему или LVM, если очистка данных невозможна.

  7. Для Kubernetes расширьте постоянный том, если класс хранилища (storage class) поддерживает расширение.

Проверка результата после устранения неисправности#

После выполнения исправлений проверьте, что источник данных восстановлен и правило оповещения перестало срабатывать.

Для проверки результата выполните следующие действия:

  1. Проверьте состояние целей сбора:

    curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {job: .labels.job, instance: .labels.instance, health: .health, lastError: .lastError}'

    Для проблемной цели значение health должно быть up, а поле lastError должно быть пустым.

  2. Проверьте активные оповещения в Prometheus:

    curl -s http://localhost:9090/api/v1/alerts | jq '.data.alerts[] | {alertname: .labels.alertname, state: .state, severity: .labels.severity}'

    После устранения проблемы оповещение должно исчезнуть из списка: точка доступа возвращает только активные оповещения в состояниях pending и firing. Если правило содержит параметр for, изменение состояния произойдет не сразу, а после истечения указанного времени.

  3. Проверьте доставку уведомлений в Alertmanager:

    curl -s http://localhost:9093/api/v2/alerts | jq

    Если оповещение устранено, оно не должно отображаться как активное в Alertmanager.