Мониторинг серверов: с чего начать

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

Что мониторить в первую очередь

• Доступность — HTTP/HTTPS, ping, порты (SSH, 1С, PostgreSQL).
• Ресурсы — CPU, RAM, диск (свободное место и inode), load average.
• Сервисы — systemd-юниты, процессы ragent/rphost для 1С, nginx/apache.
• Логи ошибок — 5xx в веб-сервере, критичные записи в журнале 1С.

Инструменты

Для SMB подойдут Zabbix (универсально), Uptime Kuma (простые проверки), Prometheus + Grafana (если уже есть контейнеры). Облачные варианты — Datadog, Selectel Monitoring — быстрый старт без своего сервера мониторинга.

Алерты

Правило: алерт должен требовать действия. «Диск 85%» — да; «CPU 60% 5 минут» — скорее шум. Настройте эскалацию в Telegram или почту, назначьте ответственного.

Дашборд для руководителя

Техническому директору нужен один экран: uptime за месяц, открытые инциденты, диски ближе 80%. Детальные графики CPU — для инженера, не для еженедельного совещания.

• Настройте maintenance window — плановые работы не должны будить ночью.
• Храните историю метрик минимум 30 дней для разбора инцидентов.
• Проверяйте алерты тестовым срабатыванием раз в квартал.

Интеграция с 1С

Отдельно мониторьте службу 1С: ragent, rphost, SQL. Падение кластера не всегда видно по ping сервера. Настройте проверку HTTP публикации или TCP-порта. Журнал регистрации 1С с критическими ошибками можно отправлять в syslog или парсить агентом.

Итог

Главное — не откладывать решение до аварии или срыва сроков. Зафиксируйте текущее состояние, определите ответственных и согласуйте бюджет с подрядчиком или внутренней командой. Команда ITRTS помогает на всех этапах: от консультации до внедрения и сопровождения. Актуальные тарифы — на странице прайса, связанные материалы — в разделе блога.