Да, с шумными соседями, которые много читают, тоже ведем борьбу.
Разносить индексы именно из-за чтения не приходилось, так как это мы это делаем уже для записи.
У нас есть два типа пользователей: 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, как альтернативу.
У нас цифры поскромнее (подробнее я уже отвечала выше). В пике у нас одна hot-нода индексирует до 12 тыс. документов в секунду. Но у нас данные от разных клиентов, в индексах до 3к полей и динамический маппинг. Сейчас работает над глобальной оптимизацией маппингов (постоянная борьба с ошибками парсинга, которые к тому же замедляют запись - утомляет), хотим дать клиентам возможность самообслуживания по редактированию маппинга, и за счет приведения количества полей к необходимому минимуму и включению dynamic:false разогнать запись.
Garbage collection - это действительно hell, почитаю статью, спасибо! и если с записью мы подобрали для себя оптимальные настройки, то с чтением - еще в процессе.
Самописный сервис, заменивший встроенные ism policy (спойлер: под большой нагрузкой встроенные тормозили). Основные вызовы к index APIs: rollover (индексы объединены к алиасам), settings-> index.routing.allocation.require.temp ставим warm, после проверки, что index не write=true, потом delete (ну и перед этим всем проверки на достижение условий хранения). Для снепшотов используются Snapshot APIs
Про запись логов могу поделиться точными цифрами. В среднем, одна 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 - отказываются, говорят не удобно.
Да, с шумными соседями, которые много читают, тоже ведем борьбу.
Разносить индексы именно из-за чтения не приходилось, так как это мы это делаем уже для записи.
У нас есть два типа пользователей: 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, как альтернативу.
Добрый день.
У нас цифры поскромнее (подробнее я уже отвечала выше). В пике у нас одна hot-нода индексирует до 12 тыс. документов в секунду. Но у нас данные от разных клиентов, в индексах до 3к полей и динамический маппинг. Сейчас работает над глобальной оптимизацией маппингов (постоянная борьба с ошибками парсинга, которые к тому же замедляют запись - утомляет), хотим дать клиентам возможность самообслуживания по редактированию маппинга, и за счет приведения количества полей к необходимому минимуму и включению dynamic:false разогнать запись.
Garbage collection - это действительно hell, почитаю статью, спасибо! и если с записью мы подобрали для себя оптимальные настройки, то с чтением - еще в процессе.
Самописный сервис, заменивший встроенные ism policy (спойлер: под большой нагрузкой встроенные тормозили). Основные вызовы к index APIs: rollover (индексы объединены к алиасам), settings-> index.routing.allocation.require.temp ставим warm, после проверки, что index не write=true, потом delete (ну и перед этим всем проверки на достижение условий хранения). Для снепшотов используются Snapshot APIs
Про запись логов могу поделиться точными цифрами. В среднем, одна 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 - отказываются, говорят не удобно.