У нас нет прозрачности на боевой инфраструктуре, и это регулярно бьёт по бизнесу. Логи живут по отдельности на каждом сервере, форматы у приложений разные, а диагностика сводится к ручному просмотру файлов через консоль. Инциденты мы ловим задним числом, часто от самих пользователей, а не от системы. Требуется навести здесь порядок: развернуть единый стек сбора логов и метрик, который стягивает данные со всех хостов и сервисов в одно хранилище с быстрым поиском, чтобы команда видела состояние продакшена целиком, не подключаясь к каждой машине по отдельности.
В качестве основы рассматриваем ELK или OpenSearch под логи и Grafana под метрики и панели. Нужно установить агенты-сборщики на серверах, привести разнородные потоки к структурированному виду с разбором по полям и собрать наглядные панели — отдельно для технической команды и для управленческой отчётности. Обязательная часть — оповещения: система должна сама сигнализировать о росте числа ошибок, о превышении порога времени ответа, о сервисе, переставшем присылать данные, и о нехватке диска или памяти. Каналы доставки уведомлений — наши текущие, пороги — выверенные, чтобы поток алертов не превратился в фоновый шум, который перестают читать.
Отдельно важны сроки хранения и связанные с ними расходы. Просим настроить ротацию и жизненный цикл индексов: свежие данные держим в горячем доступе для расследований, старые по регламенту переводим в архив или удаляем. Ждём внятную документацию по архитектуре, правилам разбора и процедуре подключения нового сервиса к конвейеру, чтобы поддержка и развитие остались на нашей стороне. Если у вас есть опыт эксплуатации подобных систем под нагрузкой, отдельно опишите, как рассчитаете ёмкость под наши объёмы трафика.
— Установка сборщиков на Linux-серверы и в контейнеры
— Разбор, индексация и регламент хранения логов
— Панели Grafana по ошибкам, задержкам и нагрузке
— Оповещения об ошибках, задержках и молчащих сервисах
В качестве основы рассматриваем ELK или OpenSearch под логи и Grafana под метрики и панели. Нужно установить агенты-сборщики на серверах, привести разнородные потоки к структурированному виду с разбором по полям и собрать наглядные панели — отдельно для технической команды и для управленческой отчётности. Обязательная часть — оповещения: система должна сама сигнализировать о росте числа ошибок, о превышении порога времени ответа, о сервисе, переставшем присылать данные, и о нехватке диска или памяти. Каналы доставки уведомлений — наши текущие, пороги — выверенные, чтобы поток алертов не превратился в фоновый шум, который перестают читать.
Отдельно важны сроки хранения и связанные с ними расходы. Просим настроить ротацию и жизненный цикл индексов: свежие данные держим в горячем доступе для расследований, старые по регламенту переводим в архив или удаляем. Ждём внятную документацию по архитектуре, правилам разбора и процедуре подключения нового сервиса к конвейеру, чтобы поддержка и развитие остались на нашей стороне. Если у вас есть опыт эксплуатации подобных систем под нагрузкой, отдельно опишите, как рассчитаете ёмкость под наши объёмы трафика.
— Установка сборщиков на Linux-серверы и в контейнеры
— Разбор, индексация и регламент хранения логов
— Панели Grafana по ошибкам, задержкам и нагрузке
— Оповещения об ошибках, задержках и молчащих сервисах
