ИНФРАСКОПИЯ
ИНФРАСКОПИЯ
Telegram

ФАКТОСКОПИЯ #01: active (running) — что доказано?

ИНФРАСКОПИЯ

Мы разбираем инфраструктуру по фактам: Linux, Zabbix, мониторинг, диагностика и архитектура. От симптома — к проверяемому выводу: что именно доказывает метрика, какие гипотезы остаются и как подтвердить решение. Без догадок там, где можно проверить. Если нужно понимать не только что сделать, но и почему — вам сюда.

Открыть в TelegramДругие публикации
systemdnginxмониторинг

Знакомая картина:

● nginx.service - A high performance web server
     Loaded: loaded (...)
     Active: active (running)

Сервис работает. Или всё-таки этого факта недостаточно для такого вывода? Начнём с того, что мы действительно наблюдаем.

active (running) означает, что в данный момент systemd считает unit активным, а его текущее состояние — running.

Это полезный факт. Но он доказывает значительно меньше, чем иногда кажется.

Что мы действительно подтвердили

Для обычного service unit такой статус позволяет утверждать:

  • unit находится в состоянии active;
  • его текущий substate — running;
  • systemd не считает сервис остановленным или failed в данный момент.

И всё.

Чего мы пока не доказали

Из active (running) само по себе не следует, что:

  • приложение функционально;
  • HTTP/API endpoint отвечает;
  • сервис доступен клиентам по сети;
  • backend-зависимости работают;
  • приложение выдаёт корректный результат;
  • в журнале нет существенных ошибок;
  • мониторинг получает актуальные данные;
  • сервис включён в автозапуск;
  • после reboot он успешно восстановится.

Например:

nginx.service
Active: active (running)

может прекрасно сосуществовать с:

HTTP/1.1 502 Bad Gateway

Почему? Потому что nginx как процесс работает, а backend приложения — нет. Для systemd nginx при этом действительно остаётся active (running). Для пользователя сервис — неработоспособен.

Один факт — разные утверждения

Допустим, нам нужно проверить четыре вещи.

  1. 1. «nginx сейчас запущен»

    systemctl status nginx

    Для проверки текущего состояния unit это подходящее evidence.

  2. 2. «nginx настроен на автоматический запуск»

    systemctl is-enabled nginx

    enabled подтверждает конфигурацию автозапуска. Но не фактическое успешное восстановление сервиса после reboot.

  3. 3. «Веб-сервис отвечает»

    Проверяем уже сам endpoint, например:

    curl -I https://example.org/

    Причём имеет значение и точка, из которой выполняется проверка. Успешный curl localhost ещё не доказывает доступность сервиса пользователю из другого сегмента сети.

  4. 4. «Сервис восстановится после перезагрузки»

    Ни active, ни enabled сами по себе этого не подтверждают. Для доказательства поведения после reboot необходимо наблюдать само это поведение — если такой тест допустим и безопасен для конкретной системы.

Где возникает ошибка

Мы получаем факт: active (running) а вывод делаем значительно сильнее: «Сервис исправен и готов к эксплуатации». Между этими утверждениями не хватает доказательств.

Полезнее мыслить так:

Наблюдение
    ↓
Какое утверждение мы проверяем?
    ↓
Достаточно ли этого наблюдения,
чтобы его подтвердить?

А не наоборот.

Факт ≠ вывод

active (running) — хороший факт. Просто не нужно требовать от него больше, чем он действительно способен доказать.

Наблюдение становится evidence только относительно конкретного утверждения.

#Фактоскопия #Linux #ПоФактам

Читайте так же