Комментарии 7
Спасибо за пост. Как вы устанавливаете Zookeeper, Kafka, OpenSearch, Logstash и другие ? Puppet, ansible или может в Kubernetes?
Устанавливаем компоненты разными путями: всё зависит от ИТ-инфраструктуры и требований заказчика. Где-то всё ставится в Kubernetes/OpenShift, где-то компоненты распределяются частями: что-то в Kuber, что-то на виртуализации, бывает даже на железных серверах. Естественно, все процессы максимально автоматизируются плейбуками.
Что-то либо я не понял, либо проблема из пальца высосана с logstash.
Там где надо было поднять ELK стек, лично мы брали отдельный logstash на приёмку данных, если и применяли, то минимальную обработку, затем клали сообщение в очередь (тогда ещё RabbitMQ), а затем уже из очереди брали другим набором экземпляров logstash данные на обработку. В таком варианте так и не удалось положить это на лопатки, хотя поток отправляли знатный, а логи парсили сложными регулярками. При том такое решение масштабировалось довольно легко - добавляли новые инстансы logstash косюмеров. Был написан скрипт, который смотрел на очередь и если она продолжала расти какое-то время, то добавлялся новый консюмер.
Подозреваю, что проблема у вас была с тем, что разные команды по-разному обрабатывали логи, но как по мне, то в этом случае нужно было им отдать свой logstash, который умеет не только в очереди ложить, но и в другой logstash. Мутно, конечно, но решило бы проблему. Хотя последний абзац и эту идею рушит.
В общем выглядит так, как будто вы не до конца разобрались с возможностями logstash.
Почти во всех случаях возникающие проблемы – это результат тех или иных ограничений. Например, в одном проекте, где мы упёрлись в потолок производительности, проблемой было ограниченное число выделяемых на сервис виртуальных машин. А у заказчика из поста выше есть ограничения не только на число ВМ (ограничение продиктовано стоимостью обладания каждой отдельной машиной), но и на возможности команд, которые будут отдавать свои данные. Проблема производительности на тестовой инсталляции не возникала, она обозначена исключительно как потенциальная. И для решения её предложен вариант близкий к тому, какой вы описываете: поднимать дополнительные logstash для натравливания на разные очереди.
У ластика и opensearch в частности, есть lifecycle соответственно вопрос в том зачем писать какой-то отдельный скрипт или использовать куратор, когда можно встроенными средствами контролировать объёмы и сроки хранения?
Про это есть подробно в посте. Повторим:
Остановились на использовании Index State Management. Он позволяет настраивать ротацию индексов по объёму и удаление по возрасту. В идеальном мире этого достаточно: при стабильном равномерном потоке данных можно легко контролировать суммарный объём хранимых логов, что является главным параметром биллинга услуги для внутренних заказчиков. Заказывая сервис хранения логов, пользователь указывает средний объём за сутки и период хранения данных и платит за рассчитываемый произведением этих значений суммарный занимаемый объём. Но в реальности существуют простои сервиса, перенастройка логирования, дебаг-режим и т. д. и т. п. В таких случаях рассчитанный для ротации раз в сутки индекс может превысить свой объём в десятки раз, а период хранения его не изменится. Это приведёт к перерасходу объёма. Но самое опасное — это переполнение хранилища самого OpenSearch. Потому что пользователи запускаются в систему, исходя из расчётного суммарно занимаемого объёма, и масштабирование системы идёт по той же логике.
Олег, добрый день!
С OpenSearch и тенантами мапямищимися на основе Active Directory групп в целом понятно (хотелось бы конечно увидеть примерный пример ролевой модели))
Скажите, пожалуйста, какой механизм вы используете чтобы разграничить эти потоки данных на уровне кафки?
Как мы «завели» десятки команд в один кластер OpenSearch и разделили доступы