Логи растут быстрее данных: как спроектировать небольшой контур наблюдаемости
Метрики, логи и трассировки отвечают на разные вопросы. Метрика показывает изменение числа или распределения, лог описывает событие, трассировка связывает шаги выполнения запроса. Нельзя автоматически заменить одно другим или хранить всё одинаково долго только ради общего дашборда.
Роль серверной платформы
Для локального контура можно выделить узел с приёмниками, хранилищем и интерфейсом поиска. Варианты HPE ProLiant DL380 Gen10 предлагает Сервер Молл. Конфигурацию следует оценивать по потоку записи, типовым запросам и срокам хранения, а не только по количеству наблюдаемых приложений.
Если наблюдаемость размещается на той же физической платформе, что и основные сервисы, при общей аварии можно потерять и работу, и диагностику. Допустимость такой схемы зависит от проекта. Как минимум внешний сигнал о доступности и история критичных событий не должны полностью зависеть от одного отказавшего узла.
До выбора оборудования фиксируют нагрузку каждого компонента. Быстрая запись журналов и поиск по месяцу истории конкурируют за ресурсы. Объём хранения не говорит, сколько одновременных запросов система выполнит с приемлемой задержкой.
Расчёт объёма логов
Предположим, приложения создают 20 миллионов событий в сутки со средним полезным размером 800 байт. Получается 16 ГБ данных ежедневно в десятичных единицах. За семь суток — 112 ГБ до индексации, служебных структур и репликации.
Если по результатам пилота полный объём хранения составляет в среднем 1,5 размера входящих данных, семидневный набор займёт около 168 ГБ. Для 20% свободного пространства требуется 210 ГБ полезной ёмкости. Коэффициент 1,5 здесь измеренное условие примера, а не универсальное свойство любой системы логирования.
Для 30 суток исходный набор вырастет до 480 ГБ, а при тех же условиях — до 720 ГБ полного хранения. Поэтому решение увеличить срок истории с недели до месяца нельзя считать небольшой настройкой. Оно меняет ёмкость, время поиска и процедуру удаления.
Отдельно учитывают пики. Средний поток 20 миллионов событий в сутки — около 231 события в секунду. Во время ошибки приложение может создавать значительно больше, особенно если повторяет запросы и пишет подробный стек для каждой попытки. Именно аварийный режим способен первым заполнить диск.
В замерах различают объём исходных сообщений, сетевую передачу после сжатия и фактическое место в хранилище. Они не обязаны совпадать. Если команда использует только статистику отправленного трафика, коэффициент хранения получится неверным, а срок до заполнения диска окажется неожиданно коротким.
Почему метки могут стать главной проблемой
В Prometheus каждая уникальная комбинация значений меток создаёт отдельный временной ряд. Документация Metric and label naming прямо предостерегает от неограниченных значений вроде идентификаторов пользователей и почтовых адресов. Удобный дополнительный разрез может резко увеличить объём данных.
В условном наборе 100 экземпляров приложения, десять маршрутов и пять классов ответа дают до 5000 сочетаний. Добавление измерения со 100 тысячами пользовательских идентификаторов увеличивает теоретическое число комбинаций до 500 миллионов, если сочетания действительно возникают. Это верхняя оценка произведения, не прогноз фактического числа рядов.
В метриках полезнее хранить ограниченные измерения: сервис, шаблон маршрута, класс ответа. Полный URL с уникальным номером заказа тоже может стать неограниченной меткой. Подробный идентификатор запроса сохраняют в предназначенном для этого журнале или трассировке с согласованным доступом.
Как выбрать содержание события
Структурированный лог должен содержать время, сервис, уровень, тип события, технический идентификатор и результат. Поля имеют согласованные названия и типы. Тогда поиск «ошибки оплаты» не зависит от того, написал один разработчик «payment failed», а другой — произвольную фразу.
В логи не помещают пароли, токены и полные платёжные данные. Идентификатор позволяет найти событие без копирования секретного содержимого. Маскирование проверяют на тестовых ошибках: именно аварийные сообщения иногда включают больше данных, чем обычный успешный путь.
Время записывают однозначно, а системы синхронизируют. Для связывания операций используют идентификатор запроса или операции, а не только близость по секундам. На высокой нагрузке множество независимых событий происходят почти одновременно, поэтому простой поиск по времени даёт ложные цепочки.
Приёмник недоступен: что делает приложение
Нужно определить, допустимо ли приложению блокировать рабочий запрос ради отправки лога. Для большинства обычных диагностических событий это нежелательно. Но требования к отдельным аудитным записям могут отличаться, поэтому политику задают по классу данных, а не одной настройкой для всего.
Если агент буферизует данные, у буфера есть предел. При 16 ГБ в сутки двухчасовой перерыв в среднем требует около 1,33 ГБ полезного места. Это оценка без пиков и служебных расходов. После восстановления приёмника агент должен передавать очередь, не создавая новую перегрузку.
Решение при переполнении фиксируют заранее: остановить приём определённого класса, удалить по принятому правилу или применить иной механизм. Потери должны становиться видимыми. Молчаливое исчезновение логов во время аварии создаёт ложное ощущение, что событий просто не было.
Сроки хранения и поиск
Разные события могут иметь разные сроки. Подробная отладка нужна недолго, агрегированные метрики — дольше, аудитные записи — по согласованным требованиям организации. Технический срок не следует выдавать за юридически обязательный без отдельной проверки оснований.
Приёмка включает типовые запросы: найти цепочку одного запроса, ошибки сервиса за час, изменение задержки и события после обновления. Испытание запускают во время продолжающегося приёма данных. Быстрый поиск в остановленном демонстрационном наборе не показывает рабочую конкуренцию за ресурсы.
Очистку старых данных также наблюдают. Если удаление или перестроение индексов регулярно замедляет запись, график обслуживания и ресурсы требуют изменения. Ёмкость и производительность оцениваются вместе на полном жизненном цикле данных.
Проверяют и стоимость одного неограниченного запроса. Поиск по всей истории без фильтра может мешать приёму новых событий. Для пользователей задают разумные начальные интервалы и доступные ограничения, сохраняя возможность расширенного анализа по согласованной процедуре.
Что проверить до эксплуатации
- Измерить средний и пиковый поток на характерных событиях.
- Проверить метки на неограниченное число значений.
- Остановить приёмник и испытать поведение буфера.
- Выполнить поиск одновременно с восстановлением очереди.
- Проверить удаление по сроку, доступ и отсутствие секретов в событиях.
Доступ к диагностике не должен означать доступ ко всем данным приложения. Командам дают необходимый круг сервисов и операций, а изменения политики хранения сохраняют в истории. Тогда сам контур наблюдаемости не становится бесконтрольным архивом внутренних сведений.
У самого контура нужны метрики: задержка поступления, число отброшенных событий, свободное место и состояние очередей. Успешный дашборд приложения не доказывает полноту данных, если приёмник уже теряет часть потока. Поэтому отсутствие потерь проверяют отдельным счётчиком и контрольной последовательностью событий.
Управляемая наблюдаемость начинается с вопросов и расчётов. Если известны поток, кардинальность, глубина хранения и поведение при отказе, можно выбирать сервер под реальную нагрузку. Без этих данных дополнительный диск лишь откладывает очередную аварию заполненного хранилища.
