Но всё равно список делается на основе ассоциаций и DevOps у вас больше ассоциируется с C/C++(хотя я вообще не знаю что он тут делает), чем с BASH. Это крайне странно.
Ну тоесть: в списке порядок по личной асоциации автора в рейтинге порядок на основе исследований
skip_unavailable пропускает только в том случае, если сервер ответил "Я не работаю" В режиме sniff когда один кластер упал, сказать я не работаю некому, поэтому кластер не пропускается. В режиме прокси когда кластер падает, haproxy переключает на локальный ElasticSearch, который выдет ошибку, аналог "я не работаю", по этому кластер пропускается.
Под фразой "я не работаю" я имею ввиду любой ответ с сервера.
Насколько я помню, если сервер ответил что кластер недоступен. Кластер пропуститься весь. Например, если упадёт ElasticSearch, но сам сервер будет доступен, тогда без каких либо проблем кластер припустится. Но если кластер не отвечает, например пакеты дропаются, то мы будем получать ошибку timeout.
Нет, пустой ответ ElasticSearch не закэширует. Да, в планах было что будет получать пустой результат, но по факту он сейчас получает ошибку 500 и пропускает этот кластер.
Чтобы хранить на клиенте столько же данных как в кластерах, мне не удастся обойтись одним серверов. Мне придётся делать ещё один полноценный кластер.
Согласитесь, помимо необходимых кластеров платить за VDS которая делает только запросы в кластер намного дешевле. Чем иметь несколько железный серверов с хорошим ядром, много RAM и с дисками несколько сот терабайт. Если я где то ошибся, поправьте меня пожалуйста
Пробежался по статье, как я понял она про репликацию. Это хорошо когда у тебя мало данных. Но что делать если в кластерах очень много данных и кластеров не 3, а 10, 20 или больше? Тратить ещё пару миллионов ради поиска, как мне кажется плохая идея.
Или я что то упустил? Если да, то просвяти пожалуйста.
Приём сообщений прост, качаешь страницу, и парсишь её по id чата и всё. Это есть по ссылке на создание чат бота. Поэтому не думал что это надо описывать.
Там же есть пример.
Когда делаешь бота тебе дают ключ и id бота. Вставляешь их в нужное место в ссылке. И всё.
Тебе осталось написать текст уведомления.
Или имеется ввиду момент приёма сообщений от бота?
Я это писал не для того, чтобы показать какой я крутой программист, а чтобы показать народу что можно использовать мессенджеры для мониторинга. И что это просто и не требует каких либо специфических знаний. О чём вы подтвердили. Спасибо.
Потому что когда я искал как сделать, мне никто подобного не предлагал.
Это статья была написана как идея для будущих свершений.
Релокации планы:
Уезжать готовы 58% + не уезжать 59% =117%
Откуда ещё 17% опрошенных?
Прям выборы в призиденты
Но всё равно список делается на основе ассоциаций и DevOps у вас больше ассоциируется с C/C++(хотя я вообще не знаю что он тут делает), чем с BASH.
Это крайне странно.
Ну тоесть:
в списке порядок по личной асоциации автора
в рейтинге порядок на основе исследований
А почему Bash только на 6 месте?
Мне он видится как минимум на 2 если не на 1 месте.
Хм, занятная штука, пойду поставлю себе=)
Мне кажется у всех всегда один вопрос:
Как выйти из VIM?
skip_unavailable пропускает только в том случае, если сервер ответил "Я не работаю"
В режиме sniff когда один кластер упал, сказать я не работаю некому, поэтому кластер не пропускается.
В режиме прокси когда кластер падает, haproxy переключает на локальный ElasticSearch, который выдет ошибку, аналог "я не работаю", по этому кластер пропускается.
Под фразой "я не работаю" я имею ввиду любой ответ с сервера.
У меня эта песня ассоциируется с Укупником=) Он тоже её пел
Насколько я помню, если сервер ответил что кластер недоступен. Кластер пропуститься весь.
Например, если упадёт ElasticSearch, но сам сервер будет доступен, тогда без каких либо проблем кластер припустится. Но если кластер не отвечает, например пакеты дропаются, то мы будем получать ошибку timeout.
Нет, пустой ответ ElasticSearch не закэширует.
Да, в планах было что будет получать пустой результат, но по факту он сейчас получает ошибку 500 и пропускает этот кластер.
Чтобы хранить на клиенте столько же данных как в кластерах, мне не удастся обойтись одним серверов. Мне придётся делать ещё один полноценный кластер.
Согласитесь, помимо необходимых кластеров платить за VDS которая делает только запросы в кластер намного дешевле. Чем иметь несколько железный серверов с хорошим ядром, много RAM и с дисками несколько сот терабайт.
Если я где то ошибся, поправьте меня пожалуйста
Пробежался по статье, как я понял она про репликацию. Это хорошо когда у тебя мало данных.
Но что делать если в кластерах очень много данных и кластеров не 3, а 10, 20 или больше? Тратить ещё пару миллионов ради поиска, как мне кажется плохая идея.
Или я что то упустил? Если да, то просвяти пожалуйста.
Мы используем бесплатный Elasticsearch, нам его хватает с лихвой.
Да мы смотрели Kibana+Clickhouse, нам показалось это не жизнеспособным, поэтому мы отказались от этой идеи.
Loki стоит использовать совместно с k8s. Но у нас нет кубера.
Когда делаешь бота тебе дают ключ и id бота. Вставляешь их в нужное место в ссылке. И всё.
Тебе осталось написать текст уведомления.
Или имеется ввиду момент приёма сообщений от бота?
Потому что когда я искал как сделать, мне никто подобного не предлагал.
Это статья была написана как идея для будущих свершений.