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

Mon, 01 Jan 0001 00:00:00 +0000

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

Сбор метрик systemd

Сбор метрик 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 указывать не нужно.

Создайте файл конфигурации /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 # путь по умолчанию для хоста

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

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

Приватный сокет /run/systemd/private доступен только пользователю root. Чтобы интеграция могла читать данные systemd, процесс агента должен иметь соответствующие права на этот сокет. Если метрика systemd_can_connect принимает значение 2 (CRITICAL) с ошибкой доступа к сокету — убедитесь, что агент запущен с достаточными привилегиями для чтения /run/systemd/private.

Если агент запускается в виде 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_names`	Список полных имён systemd-юнитов для мониторинга. Имя указывается с суффиксом типа (`.service`, `.socket`, `.mount` и т.п.). Маски/шаблоны здесь не поддерживаются — нужно точное имя.
`unit_regexes`	Регулярные выражения (синтаксис Go `regexp`), которыми отбираются имена юнитов. Применяется вместе с `unit_names`. Должен быть задан хотя бы один из параметров: `unit_names` или `unit_regexes`.
`private_socket`	Путь к приватному сокету systemd, через который агент читает данные. По умолчанию `/run/systemd/private`; для агента в Docker — `/host/run/systemd/private`.
`substate_status_mapping`	Сопоставление substate юнита со статусом метрики `systemd_unit_substate` (`ok` / `warning` / `critical` / `unknown`). Substate без явного сопоставления даёт статус `unknown`. Без этого параметра метрика `systemd_unit_substate` не публикуется.
`tags`	Статические теги, добавляемые ко всем метрикам этого инстанса.
`min_collection_interval`	Минимальный интервал сбора на уровне агента, секунды.

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

В одном инстансе можно перечислить несколько юнитов и/или задать их шаблоны регулярными выражениями. Метрики каждого юнита помечаются меткой 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.

Требования к версии systemd

Часть метрик зависит от версии systemd: systemd_service_cpu_time_consumed требует systemd ≥ 220, systemd_service_restart_count — systemd ≥ 235, systemd_socket_connection_refused_count — systemd ≥ 239. На более старых версиях такие метрики просто не публикуются.

Проверка

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

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_can_connect`	gauge	Доступность systemd: смог ли агент подключиться к приватному сокету. `0` (OK) — норма, `2` (CRITICAL) — подключиться не удалось.
`systemd_system_state`	gauge	Общее состояние systemd. `0` (OK) при `running`; `2` (CRITICAL) при `degraded` / `maintenance` / `stopping`; `3` (UNKNOWN) при `initializing` / `starting`. Текстовая расшифровка — в метке `message`.
`systemd_unit_state`	gauge	Active-состояние юнита (метка `unit`). `0` (OK) при `active`; `2` (CRITICAL) при `inactive` / `deactivating` / `failed`; `3` (UNKNOWN) при `activating`.

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

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

Метрика	Тип	Описание
`systemd_unit_active`	gauge	Находится ли юнит в состоянии `active` (1 / 0).
`systemd_unit_loaded`	gauge	Загружен ли юнит (1 / 0).
`systemd_unit_monitored`	gauge	Признак того, что юнит под мониторингом (значение всегда `1`).
`systemd_unit_uptime`	gauge	Время с момента активации юнита, секунды.
`systemd_units_total`	gauge	Общее число юнитов в системе.
`systemd_units_loaded_count`	gauge	Число загруженных юнитов.
`systemd_units_monitored_count`	gauge	Число юнитов под мониторингом.
`systemd_units_by_state`	gauge	Число юнитов в разбивке по состоянию (метка `state`: `active`, `inactive`, `activating`, `deactivating`, `failed`).

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

Метрика	Тип	Ед.	Описание
`systemd_service_cpu_time_consumed`	gauge	нс	Суммарное потребление CPU службой (`CPUUsageNSec`). Требует `CPUAccounting=yes`, systemd ≥ 220.
`systemd_service_memory_usage`	gauge	байт	Текущее потребление памяти службой (`MemoryCurrent`). Требует `MemoryAccounting=yes`.
`systemd_service_restart_count`	gauge	—	Сколько раз служба была перезапущена по `Restart=` (`NRestarts`). Требует systemd ≥ 235.
`systemd_service_task_count`	gauge	задачи	Текущее число задач в службе (`TasksCurrent`). Требует `TasksAccounting=yes`.

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

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

Метрика	Тип	Описание
`systemd_socket_connection_accepted_count`	gauge	Число принятых соединений сокета (`NAccepted`).
`systemd_socket_connection_count`	gauge	Текущее число соединений сокета (`NConnections`).
`systemd_socket_connection_refused_count`	gauge	Число отклонённых соединений сокета (`NRefused`). Требует systemd ≥ 239.

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

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

systemd_service_memory_usage{unit="ssh.service"}

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

systemd_unit_state{unit="ssh.service"}

Документация Proto Observability Platform – systemd