существует ли балансировщик с intermediate logging?

Пока смотрю в сторону haproxy с его sticky counters

https://www.haproxy.com/documentation/haproxy-configuration-tutorials/proxying-essentials/custom-rules/stick-tables/

Есть идеи, как собирать статистику?

Вы не с того конца заходите. Мы используем Fluentbit, он предоставляет метрики для Прометея по каждому input/filter/output, ну и healthcheck, конечно. Чем меньше передаточный звеньев тем лучше. Не знаю, впрочем, умеет ли filebeat так, но если нет, проще заменить его, всё равно у вас, судя по всему, вся логика в logstash’е происходит.

сколько приходит логов. чтобы понимать, кто создает основную нагрузку на базу (opensearch)

Так Opensearch Dashboard для этого и использовать. Вся информация уже в нём содержится.

Так Opensearch Dashboard для этого и использовать. Вся информация уже в нём содержится.

Можно подробнее, где искать эту информацию?

А, если речь про размер индексов и шардов, то не получится. Я заливаю однотипные логи в один index pattern. Приложения да, в разные

Вы не с того конца заходите. Мы используем Fluentbit, он предоставляет метрики для Прометея по каждому input/filter/output, ну и healthcheck, конечно

Это хорошая идея, спасибо :)

Добавлю проверки. Но пока все же попробую вытащить информацию из haproxy. Цель выглядит более-менее разумной, скорее всего это реализуемо

У вас есть какие-то метаданные, отвечающие на вопрос «кто шлёт логи», не может не быть. Допустим это поле host А значит можно создать dashboard, напримерт типа area, где по оси Y будет count, а по X — Date Histogram по полю какое у вас там дату показывает, обычно @timestamp, которую гистограмму можно затем split series по significant term, где оный терм это host.keyword.

После чего получается aggregation, какой host сколько документов присылал в какой момент времени.

А, если речь про размер индексов и шардов, то не получится

elasticsearch exporter подключить можете? Если да, то там опять же куча метрик из коробки готовых.

А зачем тебе прокладка в виде logstash? Можешь формировать логи в json и при помощи filebeat заливать их сразу в датастрим еластика.

Неа. filebeat тупой. А логи еще нужно

1. разобрать на поля (ну допустим)
2. залить в отдельные индексы (а это уже без шансов)

upd.

Можешь формировать логи в json

А. Это при условии, что логи пишет свое приложение. Но так бывает не всегда. Системные тоже нужны

з.ы. я присматривался к data-prepper, но у него в принципе единственный pipeline. одна опечатка и привет

когда подниму несколько инстансов за балансировщком, попробую сделать ещё один подход

Но и nginx, и haproxy пишут строку в лог уже после того, как клиент отключился.

Пропатчи чтобы писали и в начале сессии. Это, скорее всего, очень просто. И не надо будет ничего остального менять.

Ты можешь связку (filebeat - logstash) на vector (vector.dev) заменить. Vector умеет в прометеевские метрики и имеет настраиваемый буфер куда будут писаться логи, даже если твой opensearch недоступен.

даже если твой opensearch недоступен.

это лишь один из возможных варинтов

• сетевой доступ пропал (разные варианты)
• filebeat погасили (…) и забыли включить
• приложение теперь пишет в лог с другим именем
• разное (без комментариев, т.к. мой французский очень плох)

и filebeat без проблем переживает недоступность logstash или filebeat. когда доступ появится, продолжит с того же места

Я о том, что vector отлично заменит эту связку. И все эти проблемы он тоже отлично отработает + метрики + отличная конфигурируемость (включая парсинг и ремаппинг полей). Ну и haproxy не нужен, так как можно настроить routing между vector’ами. Зачем два инструмента, когда можно решить все это одним?

Включи сбор статистики на filebeat и logstash, каждый инстанс может сам у себя через loopback брать статистику и отправляй в индекс opensearch/ Дальше или в дашбордах или алертинг.

Звучит, как fluentbit.

Он тебе и на поля всё разложит, и индексы навесит какие хочешь, и системные логи прочитает.

И даже что-то там с прометеусом было.

Я поддержу @adn. Проблема в том, что ты вместо готовой функциональности начинаешь городить костыли (с патчем прокси-сервера, это мне особо понравилось). Когда готовые инструменты есть и давно используются. Не майся дурью, а сделай правильно.

Проблема в том, что ты вместо готовой функциональности начинаешь городить костыли

Нет, проблема в том, что предложенная готовая функциональность решает совсем другую задачу

с патчем прокси-сервера, это мне особо понравилось

А мне особенно понравилось, что ты где-то нашел прокси сервер и уверен, что я буду его патчить ;)

Предварительно, sticky counters именно то, что нужно

мне нужен счетчик sc_kbytes_out

и команды API

• show table
• clear table

Включи сбор статистики на filebeat и logstash, каждый инстанс может сам у себя через loopback брать статистику и отправляй в индекс opensearch/ Дальше или в дашбордах или алертинг.

С logstash давно собираю. Но, насколько я помню, там статистика по pipeline, и по отдельным плагинам. Это хорошо, но мне-то нужно по клиентским хостам

С filebeat посмотрю позже, но засада в том, что это будет не то, что мне нужно:

• на хосте владелец стенда может перенастроить filebeat на другой output. exporter будет рапортовать, что логи он шлет. а приходить они не будут. точнее будут, но не в тот opensearch
• сбор метрик со всех клиентских хостов тоже нужно настроить. и запросто возможна ситуация, когда кто-то шлет логи, и реально много, а по метрикам он как бы не при делах

В общем все это хорошо, но пока я попробую собрать нужные мне данные с балансировщика, это будет наиболее актуальная информация