Производительность и масштаб

Во время инцидента сервис повторяет запросы и пишет больше ошибок. Поиск нужен чаще, а в хранилище одновременно идёт больше записей. Добавить двадцать шардов звучит как открыть двадцать касс, но каждая касса требует сотрудника и места. Маленький магазин от этого не ускорится.

Сначала измерь узкое место

Наблюдай скорость входа, задержку доставки, ошибки индексации, очередь Logstash, CPU, heap, диск и время поиска. «Kibana медленная» может означать дорогой запрос, забитый диск или свежие логи, которые ещё стоят в очереди. Не лечи все три причины настройкой refresh.

При 20 ГБ первичных данных в день за неделю накапливается около 140 ГБ. При целевом размере первичного шарда 35 ГБ это примерно четыре первичных шарда для этого объёма, а не обязательно четыре шарда на каждый день. С одной репликой копий восемь. Существующий индекс нельзя произвольно перевести с одного первичного шарда на пять настройкой; планируй будущие индексы, rollover, split или переиндексацию.

Что стоит один шард

Шард

хранит данные, сегменты и структуры поиска. Тысяча крошечных шардов может стоить дороже, чем меньший набор крупных. Рекомендация от 10 до 50 ГБ это отправная точка, не закон: измеряй поиск и время восстановления на своих данных.

Реплика повышает доступность и может обслуживать чтение, но не бесплатна: ещё одна копия данных и индексации. На одном узле реплика не размещается рядом с первичным шардом. Почему кластер становится yellow, мы разбирали в уроке о шардах.

Пачка и видимость

Отправлять каждую строку отдельным HTTP-запросом дорого. _bulk собирает операции пачкой. Успешный HTTP-статус пачки не гарантирует успех каждой операции: смотри errors и отдельные items.

Refresh

делает свежие записи доступными поиску. Более длинный refresh_interval уменьшает частоту публикации, но дежурный дольше ждёт свежие логи. Выбирай задержку, допустимую для оповещений.

Первая выдача пуста, после _refresh оба документа доступны. Поменяй bulk на _bulk?refresh=true: они станут видны сразу. Это демонстрация семантики, не сравнение скорости серверов. Браузер не моделирует диски, JVM, сетевую нагрузку и автоматическое течение 30 секунд.

Увеличивай без гадания

1. Зафиксируй поток, запросы и допустимую задержку на стенде.
2. Меняй размер пачки и число отправителей по одному параметру; прекращай рост, если очередь и 429 растут.
3. Отдели частый поиск свежих логов от редкого архива; ILM поможет с переходами, реальные tier-узлы потребуют ресурсов.
4. Уменьши лишний поток: DEBUG и проверки здоровья, дубли исходного текста, ненужные индексируемые поля.

Не отключай реплики в рабочем кластере ради красивого результата стенда без принятого риска потери доступности. Не отправляй force merge на активно записываемый индекс как универсальное ускорение: слияние расходует I/O.

Больше серверов не заменит защиту логов: большой индекс с паролями остаётся большой утечкой.