Мониторинг systemd-сервисов с помощью Proto Observability Platform

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

• Сбор метрик systemd
  • Конфигурация ProtoOBP агента
    • Если агент запускается в виде службы systemd на хосте
    • Если агент запускается в виде Docker контейнера
  • Параметры конфигурации
  • Мониторинг нескольких юнитов
  • Учет CPU памяти и задач службы
  • Проверка
  • Список метрик
  • Просмотр в веб-интерфейсе Proto

Сбор метрик systemd

Интеграция systemd собирает метрики самого systemd и управляемых им юнитов (служб, сокетов и т.п.): состояние и uptime юнита, потребление CPU и памяти службой, число перезапусков и задач, статистику соединений сокетов, а также сводные счётчики юнитов по состояниям. Данные читаются через приватный сокет systemd (/run/systemd/private) — отдельный экспортёр или агент внутри мониторируемой службы не нужен.

Юниты, за которыми ведётся наблюдение, задаются явно в конфигурации (unit_names и/или unit_regexes). Метрики по конкретному юниту помечаются меткой unit (например, unit="ssh.service"); системные и сводные метрики (systemd_can_connect, systemd_system_state, systemd_units_total и т.п.) метки unit не имеют. Ко всем метрикам платформа добавляет метку хоста (host).

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

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

Когда агент сам работает как systemd-служба на хосте, приватный сокет systemd доступен по пути по умолчанию (/run/systemd/private), поэтому private_socket указывать не нужно.

1. Создайте файл конфигурации /etc/protoobp-agent/conf.d/systemd.d/conf.yaml и перечислите юниты, которые нужно мониторить:

   init_config:
   
   instances:
     - unit_names:
         - ssh.service        # Debian/Ubuntu; на RHEL/CentOS — sshd.service
     # private_socket: /run/systemd/private   # путь по умолчанию для хоста
   

2. Перезапустите ProtoOBP агента:

   systemctl restart protoobp-agent
   

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

В этом сценарии приватный сокет systemd хоста и каталог конфигурации монтируются с хоста внутрь контейнера агента. Ниже — на примере оркестрируемого compose-файла /opt/protoobp/docker-compose-200.yaml.

1. Добавьте сервису protoobp-agent два новых volume — приватный сокет systemd (только чтение) и каталог конфигурации интеграции:

  protoobp-agent:
    <<: *dns-config
    container_name: protoobp-agent
    image: ${DOCKER_REGISTRY}/protoobp-agent:200
    restart: always
    networks:
      protoobp:
    pid: host
    volumes:
      - /run/systemd/private:/host/run/systemd/private:ro
      - ./conf.d/systemd.d:/etc/protoobp-agent/conf.d/systemd.d:ro

2. Создайте каталог конфигурации интеграции:

mkdir -p /opt/protoobp/conf.d/systemd.d

3. Создайте файл /opt/protoobp/conf.d/systemd.d/conf.yaml с перечнем юнитов. Обратите внимание: для контейнера приватный сокет смонтирован по пути /host/run/systemd/private, поэтому private_socket указывается явно:

init_config:

instances:
  - private_socket: /host/run/systemd/private
    unit_names:
      - ssh.service        # Debian/Ubuntu. На RHEL/CentOS → sshd.service

4. Пересоздайте контейнер агента из каталога /opt/protoobp:

docker stop protoobp-agent
docker rm protoobp-agent
docker compose -f docker-compose-200.yaml up -d

Параметры конфигурации

Мониторинг нескольких юнитов

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

init_config:

instances:
  - unit_names:
      - ssh.service
      - docker.service
      - docker.socket
    # Дополнительно отобрать юниты по регулярным выражениям (синтаксис Go):
    unit_regexes:
      - cron\.service
      - nginx.*
    tags:
      - env:prod

Метрику systemd_unit_substate можно включить и настроить под конкретный юнит — задайте сопоставление substate → статус (без этого параметра метрика не публикуется):

init_config:

instances:
  - unit_names:
      - ssh.service
    substate_status_mapping:
      ssh.service:
        running: ok
        dead: critical

Учет CPU памяти и задач службы

Метрики systemd_service_cpu_time_consumed, systemd_service_memory_usage и systemd_service_task_count доступны только если для соответствующей службы включён учёт ресурсов (accounting) в systemd. На многих современных дистрибутивах учёт памяти и задач включён по умолчанию; учёт CPU чаще требуется включить явно.

Включить учёт для отдельной службы можно через drop-in:

# /etc/systemd/system/ssh.service.d/accounting.conf
[Service]
CPUAccounting=yes
MemoryAccounting=yes
TasksAccounting=yes

После этого перечитайте конфигурацию и перезапустите службу:

systemctl daemon-reload
systemctl restart ssh.service

Учёт можно включить и глобально, прописав DefaultCPUAccounting=yes, DefaultMemoryAccounting=yes, DefaultTasksAccounting=yes в /etc/systemd/system.conf.

Проверка

Запустите проверку вручную и убедитесь, что проверка собирает метрики:

docker exec protoobp-agent agent check systemd

(для агента-службы на хосте — agent check systemd без docker exec).

Ожидаемый вывод — Instance ID: ... [OK] и ненулевое Metric Samples:

  Running Checks
  ==============

    systemd
    -------
      Instance ID: systemd:69bbed4048f9672a [OK]
      Configuration Source: file:/etc/protoobp-agent/conf.d/systemd.d/conf.yaml
      Total Runs: 1
      Metric Samples: Last Run: 16, Total: 16
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 3, Total: 3
      Average Execution Time : 14ms
      Last Execution Date : 2026-06-05 15:33:31 UTC (1780673611000)
      Last Successful Execution Date : 2026-06-05 15:33:31 UTC (1780673611000)

Состояние интеграции можно также посмотреть в общем статусе агента:

docker exec protoobp-agent agent status | grep -A 10 "systemd"

Строка Service Checks: 3 в выводе — это проверки systemd (доступность, состояние системы и состояние одного юнита). В protoobp их результаты доступны как числовые метрики systemd_can_connect, systemd_system_state и systemd_unit_state (см. Список метрик).

Список метрик

Метрики по конкретному юниту помечаются меткой unit (например, unit="ssh.service"); сводные и системные метрики метки unit не имеют. Ко всем метрикам добавляется метка хоста (host).

Метрики состояния и здоровья

Это результаты проверок systemd, опубликованные как числовой код статуса: 0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN. В исправном состоянии значение равно 0.

Метрика systemd_unit_substate (код статуса по substate юнита) публикуется только если в конфигурации задан параметр substate_status_mapping.

Метрики юнитов

Метрики служб (.service) — требуют включённого accounting (см. Учет CPU памяти и задач службы)

Метрики сокетов (.socket)

Появляются только если в unit_names / unit_regexes указан юнит-сокет (.socket). При мониторинге одних только служб (как в примере с ssh.service) этих метрик нет.

Просмотр в веб-интерфейсе Proto

После того как проверка поднялась, метрики доступны в веб-интерфейсе Proto. Например, потребление памяти службой ssh.service:

systemd_service_memory_usage{unit="ssh.service"}

Состояние юнита (код статуса: 0 — OK, 2 — CRITICAL):

systemd_unit_state{unit="ssh.service"}