«Традиционные системы логирования изначально проектировались для монолитных приложений, работающих в предсказуемых средах — физических серверах или виртуальных машинах с ограниченным числом источников логов. Однако современные архитектуры изменились до неузнаваемости. Микросервисы, контейнеризация, гибридные и мультиоблачные среды, автоматизация через CI/CD [Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка] — все это создает новые вызовы, с которыми старые подходы уже не справляются.
Первый камень преткновения — масштабируемость. Централизованные системы сталкиваются с узкими местами при обработке терабайтов логов в день. Пропускная способность шины передачи данных (например, Kafka или Logstash) и индексации (Elasticsearch) достигает предела, что приводит к задержкам и потере данных. Это особенно критично в условиях, когда каждая миллисекунда задержки может привести к падению производительности или простою бизнес-процессов.
Второй фактор — высокая стоимость владения (TCO — total cost of ownership). Хранение и индексация всех логов в централизованном хранилище требуют огромных ресурсов: дискового пространства, оперативной памяти, вычислительной мощности. Особенно остро эта проблема проявляется при логировании на уровне DEBUG или TRACE, где объем данных может увеличиваться в разы. Для многих компаний это становится неподъемной финансовой нагрузкой.
Третья сложность — жесткая централизация управления. Единая точка управления требует высокой квалификации SRE/DevOps-инженеров, что замедляет адаптацию под нужды новых команд и сервисов. Кроме того, централизованные решения часто навязывают единый формат, политику хранения, уровень детализации, что не учитывает специфику отдельных сервисов. Например, команда фронтенда хочет логировать UX-события, бэкенд-команда фокусируется на ошибках и времени отклика, а команда безопасности требует аудита всех входов. Единая система не позволяет гибко настраивать эти параметры, что приводит к конфликтам интересов.
Наконец, нельзя не упомянуть проблемы с доступом и безопасностью. Разные команды требуют разного уровня доступа. Централизованная система часто либо слишком открыта (риски утечки), либо слишком закрыта (разработчики не могут диагностировать проблемы). Это создает дополнительные барьеры для эффективной работы.
Новые тренды
Ситуацию усугубляют современные тренды, которые меняют правила игры. Во-первых, растет объем данных. Каждый микросервис, контейнер, функция в FaaS — новый источник данных. Обработка такого объема в реальном времени невозможна без оптимизации. Во-вторых, распространение гибридных и мультиоблачных сред усложняет маршрутизацию логов. Логи рассеяны между облачными провайдерами, on-premise, edge-устройствами [on-premise — использование собственной инфраструктуры и ресурсов для размещения ПО, edge-устройства — обработка данных вблизи их источника]. Централизованный сбор требует сложной маршрутизации, что увеличивает задержки и стоимость.
Контейнеризация и оркестрация (Kubernetes) добавляют еще один слой сложности. Поды (pods) живут минуты, а логи нужно собирать до их уничтожения. Традиционные агенты не успевают за динамикой. Скорость изменений также играет против централизованных систем. Команды делают десятки деплоев в день, и логи должны быть доступны немедленно для диагностики.
Ставка на гибкость
Одним из решений, которое помогает преодолеть эти вызовы, является платформа контейнеризации «Боцман». Это гибридная облачная платформа для управления мультикластерами Kubernetes, которая предоставляет полную интеграцию сервисов через пользовательский интерфейс. Она позволяет компаниям переходить от жесткой централизации к гибкой модели, где каждая команда получает автономность, но при этом сохраняется единое управление.
«Боцман» предлагает стандартизацию и использование девопс-подхода для ускорения разворачивания, внедрения и эксплуатации сервисов. Встроенный каталог приложений и инструментов предоставляет все необходимые средства для разработчиков ПО. Строгие политики безопасности и аутентификации обеспечивают защиту данных, а поддержка от российского вендора гарантирует согласованный SLA [Service Level Agreement — соглашение об уровне обслуживания] на решение инцидентов.
Платформа может быть развернута в различных средах как облачных, так и на программно-аппаратном комплексе. Она использует инструменты открытого программного обеспечения, позволяющие выполнять такие операции по управлению мультикластерами Kubernetes, как установка, обновление, бэкап, тестирование. При этом пользовательский интерфейс позволяет использовать каталог приложений kubectl, API и CLI.
Кейс модернизации системы хранения данных
Примером успешного внедрения «Боцмана» стал проект с «Ренессанс Банком»*. В предыдущей архитектуре система логирования была жестко централизована, что ограничивало гибкость работы продуктовых и инженерных команд.
Одним из ключевых результатов проекта стало создание автономных, изолированных рабочих сред для проектных команд, которые получили возможность самостоятельно управлять параметрами сбора журналов, настраивать формат и частоту логирования в соответствии со своими задачами, а также вносить изменения без участия центральной ИТ-службы. Это обеспечило больший контроль над процессами, повысило гибкость и ускорило внутренние взаимодействия. Использование методологии GitOps обеспечило прозрачность изменений, контроль версий и возможность оперативного отката.
Особое внимание уделили вопросам информационной безопасности: внедрили строгую политику разграничения доступа, систему аутентификации источников событий и сквозное шифрование трафика. Архитектура системы хранения была переосмыслена с приоритетом на стабильность, отказоустойчивость и надежность. Выявленные при пиковых нагрузках проблемы были решены заменой Logstash на Vector, а журналы событий стали реплицироваться в два независимых дата-центра для обеспечения сохранности и синхронности данных даже в случае отказа одной из площадок.
По данным «Ренессанс Банка», такой подход позволил значительно сократить время восстановления: теперь RTO [Recovery Time Objective — целевое время восстановления] составляет не более одного часа, а синхронизация 10 тыс. шардов занимает всего шесть минут. На этапе промышленной эксплуатации платформа также доказала свою эффективность: пиковая нагрузка достигала 226 тыс. событий в секунду, объем хранимых данных — 650 ТБ на каждый ЦОД, число индексов — более 20 тыс.
Этот пример показывает, что современные вызовы логирования требуют новых подходов, а гибкие решения, такие как «Боцман», позволяют компаниям не только справляться с ростом объемов данных, но и повышать эффективность работы команд, обеспечивать автономность и безопасность, а также снижать эксплуатационные затраты».
18+
*«Ренессанс Банк» — КБ «Ренессанс Кредит» (ООО), лицензия Банка России № 3354 от 26.04.2013 г.
Реклама. Рекламодатель ООО «ПЛАТФОРМА БОЦМАН», bootsman.tech, erid:2SDnjeSPnt6