Pull to refresh

Comments 17

Спасибо за интересный пост. Какая версия и какая лицензия у вас используется? Смотрели ли вы в сторону Kibana+Clickhouse или Loki?

Мы используем бесплатный Elasticsearch, нам его хватает с лихвой.

Да мы смотрели Kibana+Clickhouse, нам показалось это не жизнеспособным, поэтому мы отказались от этой идеи.

Loki стоит использовать совместно с k8s. Но у нас нет кубера.

loki стоит смотреть и вне контекста k8s, потому что там отличная интеграция с метриками из прома, и минимально разумная интеграция по меткам между промом и loki - и вы получаете инструмент, который kibana обещала все эти годы (и не доставила) - показ и логов и аномалий метрик в одном view.

Пробежался по статье, как я понял она про репликацию. Это хорошо когда у тебя мало данных.
Но что делать если в кластерах очень много данных и кластеров не 3, а 10, 20 или больше? Тратить ещё пару миллионов ради поиска, как мне кажется плохая идея.

Или я что то упустил? Если да, то просвяти пожалуйста.

Не очень понял Ваш пассаж про "много данных", почему Вы считаете, что репликация не будет работать, если данных много?

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

Чтобы хранить на клиенте столько же данных как в кластерах, мне не удастся обойтись одним серверов. Мне придётся делать ещё один полноценный кластер.

Согласитесь, помимо необходимых кластеров платить за VDS которая делает только запросы в кластер намного дешевле. Чем иметь несколько железный серверов с хорошим ядром, много RAM и с дисками несколько сот терабайт.
Если я где то ошибся, поправьте меня пожалуйста

Честно говоря, не готов подсказать готовое решение, которое было бы оптимально для Вашего случая, так как мне неизвестны требования, текущая и планируемая нагрузка и состав самих данных.

В статье упомянуто что Elastic кеширует результаты. В этой конфигурации он не закеширует отсутствующий ответ? Он же не знает что кластер вернулся, может выдать старый пустой ответ. Или в нем есть механизмы это предотвращающие?

Нет, пустой ответ ElasticSearch не закэширует.
Да, в планах было что будет получать пустой результат, но по факту он сейчас получает ошибку 500 и пропускает этот кластер.

Да, эта функция действительно работает только в том случае, если упал только один сервер из всего кластера

Я не очень поняла, откуда это взялось. Раздел в документации называется "Skip unavailable clusters", в описании - "but none of its nodes", которое вроде бы значит "ни одна из нод", а не "одна из нод". И тем более не поняла, почему в другом режиме этот параметр взял и заработал иначе. Можно этот момент поподробнее осветить?

Насколько я помню, если сервер ответил что кластер недоступен. Кластер пропуститься весь.
Например, если упадёт ElasticSearch, но сам сервер будет доступен, тогда без каких либо проблем кластер припустится. Но если кластер не отвечает, например пакеты дропаются, то мы будем получать ошибку timeout.

На превью должен быть Цекало, а не Укупник.

На фото должна быть Лолита Милявская. Такое впечатления что наконец-то сломана защита от дурака.

Оказывается, в режиме proxy параметр «skip_unavailable» всё же может пропускать целые кластера.

Объясните пожалуйста, почему в режиме proxy работает, а в режиме sniff нет.

skip_unavailable пропускает только в том случае, если сервер ответил "Я не работаю"
В режиме sniff когда один кластер упал, сказать я не работаю некому, поэтому кластер не пропускается.
В режиме прокси когда кластер падает, haproxy переключает на локальный ElasticSearch, который выдет ошибку, аналог "я не работаю", по этому кластер пропускается.

Под фразой "я не работаю" я имею ввиду любой ответ с сервера.

Sign up to leave a comment.