Comments 15
Интересны абсолютные цифры объёма и скорости достигнутого логгирования. Допустим, на один сервер 12 ГБ в час, 50 серверов в одном датацентре. Просто общался с kibana, и не очень она была полезна именно для изучения логов, всё равно приходилось идти к тексту
Про запись логов могу поделиться точными цифрами. В среднем, одна hot-нода (24 CPU, 64 RAM, 2Гб SSD) записывает 6000 документов в секунду. Один кластер с 10 hot нодами (на наших данных и настройках инджеста) тянет в пике 120к документов в секунду (при этом ноды могут писать не равномерно, хотя у нас есть несколько джобов, которые приводят шарды к похожему размеру(не более 10Гб), но клиентские данные разномастны по своей структуре).
Мы вывели (под свои запросы) идеальную формулу кластера данных Opensearch: 3 cluster_manager (в прошлом master), 10 Hot(они же с типом ingest), 10 warm, 3 coordinating ноды; В идеале запись должна распределяться по gslb pickclosest. Но исторически у нас было много ресурсов в одном из ДЦ, в нем сейчас 3 кластера (указанной выше конфигурации), а в остальных ДЦ по одному дата-кластеру.
Про чтение подробней отвечу в комментарии ниже (про шумных соседей на чтение).
Впервые слышу, что удобней смотреть логи в тексте, чем в kibana. Наши пользователи бывает, что жалуются на скорость загрузки Opensearch dashboards, на лаг в Кафка из-за которого могут быть задержки записи/отображения логов. Клиенты все время хотят писать/читать больше логов (мы даем рекомендации по оптимизации для скорости и тд, так как имеющиеся мощности накладывают ограничения на объемы), хотят полнотекстовый поиск (по всем полям) и динамический маппинг, и повышать все возможные лимиты elastic/opensearch, но менять инструмент на другой пытались, предлагали grafana-loki - отказываются, говорят не удобно.
У нас на один сервер приложений генерировалось где то 6 ГБ сжатых инфо и выше текстовых логов в сутки, примерно такой же объём уходил в кафку. В kibana был доступ только к инфологам, и для двух дц по несколько десятков основных серверов достаточно тормозной, на какой инфрастрвктуре это работало было тайной. Да и толку от инфо логов кроме как для статистики особо не было, ну разве что локализовать инцидент. Дебаг в кафку не пускали, поэтому приходилось всё равно брать 1-3 сжатых часовых лога и изучать в less. К счастью логи были внутренние
Было бы неплохо узнать объем "сырых" логов, в том же jsonl формате, да ещё пожатых банальным gzip. Как бы там 400тб в 40 не превратились.
Ротацию логов действительно нужно делать, да.
Спасибо за статью, очень интересно, особенно кейс с рейтлимитом при вычитке из Кафки.
А не приходилось бороться с "шумными соседями", которые данные не пишут, а читают? Например разносить индексы разных продуктов по разным нодам opensearch. Какой вообще rps на поиск, и сколько чтения выполняет какой-то средний запрос?
И про подход к хранению в opensearch тоже интересно. Разные продукты пишут в разные индексы? Индекс, куда идёт запись, задаёт отправитель, или он вычисляется например в логстэше? Количество шардов у индекса как-то автоматически регулируется в зависимости от объема данных, или регулируется вручную?
Не думали переливать старые данные, по которым объективно никто не ищет, но формально их нужно хранить, в другое хранилище? С снапшотами в S3 понятно, но если логи деиндексировать (сделать из них строку) и сжать текст, то гипотетически коэффициент сжатия будет х10, и при этом не будет индексов. И уже это переложить в S3. В подобном формате данные хранит loki. Как вариант, в loki можно сразу из kafka читать вторым потоком, и он поместит все в S3. Профит будет не х20, а х200 (наверное). Соответственно, при прочих равных, данные можно хранить не год, а 10 лет
Да, с шумными соседями, которые много читают, тоже ведем борьбу.
Разносить индексы именно из-за чтения не приходилось, так как это мы это делаем уже для записи.
У нас есть два типа пользователей: 1) тех. пользователи, которые используют только _search API и 2) Живые юзеры, которые пользуются opensearch dashboards.
С первыми мы поступили так: ограничили rate limit на чтение до 3 запросов в минуту на пользователя. Запретили использовать scroll api, аггрегации и сортировку (предлагаем клиентам делать это на уровне своих приложений).
Вторых сложнее ограничить, умудряются сделать жирный запрос через discover или devtools, или тяжелый дашборд сделать. Отрабатывают curcuit breakers для RAM, для ограничения CPU - сейчас пробуем search backpressure, и еще нужно учитывать, что search-запросы идут на координационные ноды, через которые search cluster подключается к data-cluster'ам. А еще датасорс-opensearch в графане был отдельной головной болью (через балансировщик запросы пустили).
Про хранение: да, разные продукты пишут в разные индексы, причем на продукт можно сделать несколько индексов (главное чтобы они укладывались в квоты для хранения). Индекс, куда идет запись задает отправитель, явно прописывая в самом логи поле indexName, но у нас есть проверка заказан ли данный индекс и проставлены ли на него квоты. В зависимости от indexName определяется топик в Кафке, через который пойдет пайплайн.
Количество шардов у новых индексов = 1. Далее в зависимости от того, сколько документов в него пришло, джоб считает нужное количество шардов. Из рассчета 10 млн. документов в час на один шард. Увеличение кол-ва шардов происходит раз в час - добавляется высчитанное число в темплейт и принудительно запускается ролловер, создается индекс с нужным кол-вом шардов). В сторону уменьшения рассчет идет за день, чтобы снизить количество ролловеров и шардов соотвественно.
Да, несколько крупных продуктов в loki пробовали писать, параллельно вычитывали из Кафки - и туда, и в opensearch. Не взлетела пока эта идея, хотят полнотекстовый поиск и много полей.
Хотим попробовать кластерную версию VictoriaLogs, как альтернативу.
Как вы переносили из горячего в холодные? Просто запрос к эластику , пагинация через курсор и удаление ?
Самописный сервис, заменивший встроенные ism policy (спойлер: под большой нагрузкой встроенные тормозили). Основные вызовы к index APIs: rollover (индексы объединены к алиасам), settings-> index.routing.allocation.require.temp ставим warm, после проверки, что index не write=true, потом delete (ну и перед этим всем проверки на достижение условий хранения). Для снепшотов используются Snapshot APIs
В случае с МТС, сколько раз просил техподдержку посмотреть логи — ни разу не посмотрели. Это касается и проблем с МТС.Кешбэк, и с плохим RSSI, и по другим вопросам.
Добрый день!
До какой скорость обработки данных из Kafka + Logstash вы разогнали OpenSearch? Я уперся в 3.4 млн. логов в секунду на 20 физ нод OpenSearch без репликации. Советую почитать ребят https://e-mc2.net/blog/elasticsearch-garbage-collection-hell/ их борьба помогла увеличить стабильность кластера.
До какой скорость обработки данных из Kafka вы разогнали Logstash? Также уперся в 50k/сек для одного Logstash.
Добрый день.
У нас цифры поскромнее (подробнее я уже отвечала выше). В пике у нас одна hot-нода индексирует до 12 тыс. документов в секунду. Но у нас данные от разных клиентов, в индексах до 3к полей и динамический маппинг. Сейчас работает над глобальной оптимизацией маппингов (постоянная борьба с ошибками парсинга, которые к тому же замедляют запись - утомляет), хотим дать клиентам возможность самообслуживания по редактированию маппинга, и за счет приведения количества полей к необходимому минимуму и включению dynamic:false разогнать запись.
Garbage collection - это действительно hell, почитаю статью, спасибо! и если с записью мы подобрали для себя оптимальные настройки, то с чтением - еще в процессе.
Спасибо за ответ! А вы пользуетесь dead letter в logstash? Из-за этого функционала я уже несколько лет не могу использовать альтернативы Logstash. Используете ли pipeline to pipeline в log stash? https://www.elastic.co/docs/reference/logstash/pipeline-to-pipeline
Поделитесь пожалуйста своим опытом по оптимизации jvm для opensearch и Logstash.
Не желаете ли митап по логам провести? Было бы здорово обсудить все вопросы оффлайн.
Логи-логи-логи, иногда кажется что все полезное что делает сервис - это пишет логи, даже тогда когда ничего не делает.
А потом борьба с повышенным потреблением памяти в сервисах (в java миллионы маленьких объектов типа String от которых случаются конвульсии у GC) и проблемы с хранением и анализом этого всего.
Тут как будто изначально проблем в том, что не нужно писать так много логов.
Логи направляете на координтор ноды (по каким критериям определяли количество координаторов?) или сразу на data hot (как определяете сколько нод нужно и почему 10?
Как у вас производится именование индекса?
На какое максимальное число шардов рассчитан кластер (data nodes * 600)? Сколько в среднем число шардов на ноду?
Почему вы не распределяете шарды индекса 1 на ноду, лимитом в кол-во нод, а выбираете значение динамически? Не бывает случаев перекоса по нагрузке в вашем случае? Даже если шарды распределяются каким-то скриптом, то можно получить ребаланс.
Как происходит блокировка на уровне топика в kafka?
Интересная статья, волнует, почему максимальная скорость индексации 12000, что явилось бутылочным горлышком. С учетом такой низкой скорости индексации не планируете ли вы размещать кластера в k8s, один кластер на проект.
Спасибо.
Забавно, что крупная компания которая генерит миллионную прибыль и казалось бы может себе позволить оплачивать лицензии. Чтобы таким образом поддерживать развитие продуктов и программистов которые их разрабатывают...
...в итоге переходит на OpenSearch, чтобы вообще не платить ни копейки :/
Мне кажется, что в свободные лицензии Open Source приложений надо внести пункт, ограничивающий их использование крупным корпорациям.
Как сделать централизованное логирование и крепко спать по ночам