скорее всего, ты его не для правильных вещей используешь, раз такие вопросы появляются;)

ага, ртфм)

ну, я так не говорил :)

я его юзаю, для оповещений если бэкап не сделался

двухфазно, когда инвокается скрипт, потом когда чекалка пришла и посмотрела что есть файло и оно приблизительно похоже на бэкап, шлётся что типа "ок" (на деле просто date +%s)

ну, я получаю 1 если данные пришли, мне нужно что бы он автоматически в 0 падал

что бы алертить если данных нету больше 20 секунд

а что это такое вообще?

джава апликуха, которая получает пуши

ну тип, инструментарий впилить и с неё снимать может?

не, там половину логики переписывать тогда

так что я просто удаляю метрику раз в 10 секунд)

ну костыль; а так ты можешь в том месте где инвокается "обработка" сделать и счётчик с инструментария

и его паблишить

счетчик чего?

номера пуша?

ну что у тебя там делаеся; пришёл пуш, мы его обрабатываем каунтер ++

и если номер не менялся n времени алертить? тоже вариант

спасибо, подумаю

https://prometheus.io/docs/instrumenting/pushing/ https://prometheus.io/client_java/io/prometheus/client/exporter/PushGateway.html

а ты какой ресивер используешь слек?

у меня целая серия ресиверов, в качестве "fallback" планируется alerta

а тут еще описание про их Alert Route https://dev.gitlab.org/cookbooks/runbooks/blob/master/howto/alerts_manual.md

спасибо!

у меня тоже алерта настроена на отправку в телеграм

там в prometheus нужно указывать url к вебхуку

У меня случилось внезапное: девелоперы согласились, что писать логи и прочее в syslog/journald/whatever это не модно и не стильно. Вопрос: что взять, что бы прямо из кода писать красивые и правильные логи и собирать их в кучу. Типа сентри/прометея, но для логов

greylog?

graylog и потом его в елку? ничего молодежней не придумали? (ну вдруг)

под "грейлог" наверно подразумевался GELF

ну а грейлог сжади держит elk так что "потом" нет смысла

точнее он там держит Е

ага, http://docs.graylog.org/en/2.2/pages/sending_data.html#gelf-sending-from-applications

У меня случилось внезапное: девелоперы согласились, что писать логи и прочее в syslog/journald/whatever это не модно и не стильно. Вопрос: что взять, что бы прямо из кода писать красивые и правильные логи и собирать их в кучу. Типа сентри/прометея, но для логов

Пиши в редис, а редис разгреба елкой

нахер редис

возьми что нибудь типа кашки

у меня через реббит

syslog/journald/whatever это не модно и не стильно. ничоси это ж наоборот самое то, по 12 факторам

приложение не роутит логи, ими занимается отдельная система

тут сложна

если эта система не подвластна тому кто поставляет логи, то роутинг этих логов это контракт между поставщиком и тем кто держит инфраструктуру логов

а их реализация редко получается "красивой"

возьми что нибудь типа кашки

от нагрузки зависит. Если там полтора сервера - нафига там кафка? На белазе за булкой ездить?

ну неткат в продакшн предлогаешь?

а потом они такие выросли и давай ещё раз архитектуру придумаем

от нагрузки зависит. Если там полтора сервера - нафига там кафка? На белазе за булкой ездить?

за тем что она меньше чем кажется, и за тем что в редисе фейловер нормальный замучаетесь делать

@Civiloid ты вроде интересовался недавно https://octobox.io

я не очень понимаю что оно делает )

за тем что она меньше чем кажется, и за тем что в редисе фейловер нормальный замучаетесь делать

какой минимум машин для установки кафки и минимум ресурсов для устойчивой работы кафки? В мегабайтах оперативы и диска?

мне как раз нужны были нотификейшены о релизах не в моих репозиториях )

но я себе уже бота написал

я не очень понимаю что оно делает )

ну это такой "клиент" для твоих сабскрайбов на гитхабе.

там и релизы в отдельном раздельчике есть, если они есть в видер релизов на гитхабе

А, ок ) но у меня мои сабскрайбы не совпадает с тем о чем я хочу оповещения получать )

но в общем не суть, тоже норм )

мне как раз нужны были нотификейшены о релизах не в моих репозиториях )

Есть еще sibbell.com . Но он на емайл. Я его юзаю - нравится

Есть еще sibbell.com . Но он на емайл. Я его юзаю - нравится

ну я себе бота на Го наваял )

какой минимум машин для установки кафки и минимум ресурсов для устойчивой работы кафки? В мегабайтах оперативы и диска?

гиг оперативы, диска столько, сколько эвентов ты хочешь хранить

сказочный подход. Гиг туда, гиг сюда. Причем, как я понимаю - гиг - это только на запуск

сказочный подход. Гиг туда, гиг сюда. Причем, как я понимаю - гиг - это только на запуск

лол.

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

даже хуже. в кафке можно отдать ей 2 гига, и если 99% времени, у вас не будет пул раздуваться больше 2 гигов у вас будет по факту тот же редис, а если будет раздуваться данные съедут на диск. В случае же с редисом вам придется ноду с такой памятью, на сколько ваш пул может раздуть

ну да. Но если у меня пул в 128 метров - мне гиг на запуск кажется некоторым барством напомню, мы подбираем инструменты под задачи, а не задачи - под инструменты

а тут еще описание про их Alert Route https://dev.gitlab.org/cookbooks/runbooks/blob/master/howto/alerts_manual.md

о, спасибо! continue: true - это как раз то что я искал всю последнюю неделю чтобы решить проблему как форвардить одно и то же в основной и + в резервный бот!

вы хотите сказать что на данный момент разница в стоимости при аренде виртуалки на 128мб и на 1гиг ?

или что для вас 1гигабайт для очереди \ брокера \ незаменимой прослойки в мейнтенйнансе является "ключевым" фактором ?

типа вы готовы пожертвовать 1гигом памяти и поиметь гемороя в оперейшонсе ?

ERROR: S client not available

типа вы готовы пожертвовать 1гигом памяти и поиметь гемороя в оперейшонсе ?

нет, скорее я готов сначала выяснить цель, а потом выбирать средство. А не покупать машины вагонетками, потому, что, оказывается, для решения простейшей задачи с минимальным трафиком 16 гиг оперативы просто не хватает

нет, скорее я готов сначала выяснить цель, а потом выбирать средство. А не покупать машины вагонетками, потому, что, оказывается, для решения простейшей задачи с минимальным трафиком 16 гиг оперативы просто не хватает

откуда выдумки про 16гигов ? Я объяснил вполне обоснованно чем кафка лучше как "решение в общем случае" по сравнению с редисом.

от вас пока стандартная отмазка "ну вы объясните нормально задачу а то я вам не могу ничего сказать"

от вас пока стандартная отмазка "ну вы объясните нормально задачу а то я вам не могу ничего сказать"

не понял наезда

а расскажите лучше как это на редисе сделать?

через их очередь?

вы предлагаете выкинуть гиг оперативы в работающей инфраструктуре, не зная о задаче вообще ничего. И считаете подобный подход нормой. Нет, если за этот банкет кто-то платит - это прекрасный подход, не спорю

а расскажите лучше как это на редисе сделать?

думаю да

Если разработчики будут писать красивые правильные логи, зачем вообще вам редис и кашка?

у rsyslog'а есть output в elasticsearch, умеет batch'ами слать данные, умеет добавлять поля от себя. Можно даже парсинг простых конструкций на базе rsyslog'а сделать при желании.

В простейшем случаи нафига вам что-то еще?

В простейшем случаи нафига вам что-то еще?

ППКС

хз.

Извините, как начавший это гавно. У меня примерно две с половиной тысячи виртуалок, которые срут всяким. И мне надо с этим всяким справиться без регистраций и смс

rsyslog и прочие в качестве центров сбора логов тупо умирают.

Извините, как начавший это гавно. У меня примерно две с половиной тысячи виртуалок, которые срут всяким. И мне надо с этим всяким справиться без регистраций и смс

если у вас 2500 виртуалок и терять данные вам нельзя - пишите в кафку или логстеш. Локально плюс аплинк

умирают от чего?

от записи или передачи по сети?

терять логи можно, это в общем основное свойство логов.

если у вас 2500 виртуалок и терять данные вам нельзя - пишите в кафку или логстеш. Локально плюс аплинк

Ну вот я и пришел адептиться :)

новый syslog-ng умеет сразу и в редис и в кафку вроде

если вам нельзя терять логи, то это уже не логи должны быть.

рсислог не может экспортировать более 50 гигов логов в сутки (примерно), помирает процесс

вот да, я думаю вопрос в том, что стоит оптимизировать транспорт логов и выбрать ОК хранилище под них

от записи или передачи по сети?

Когда как. Зависит от кучи параметров. Которые на потоках в 1500-2000 сообщений в секунду тяжко отследить :)

а нечто другое с другими требованиями к доставке, хранилищу и т.п.

Когда как. Зависит от кучи параметров. Которые на потоках в 1500-2000 сообщений в секунду тяжко отследить :)

локально как шиппите?

Когда как. Зависит от кучи параметров. Которые на потоках в 1500-2000 сообщений в секунду тяжко отследить :)

собирайте метрики с машины с rsyslog'ом, он может переварить намного больше 2к сообщений в секунду

локально как шиппите?

Пока на диск. Но там с ним все хорошо, за диском стоит толстый сторадж кластер

и смотрите что там с ним происходит

Пока на диск. Но там с ним все хорошо, за диском стоит толстый сторадж кластер

а "вверх" как отправляете?

Пока на диск. Но там с ним все хорошо, за диском стоит толстый сторадж кластер

Если диск умирает - это одно, если сам rsyslog - это другое.