спасибо )

О, теперь мы знаем секретные команды бота))

они не очень секретные :)

и доступны админамтока

А кажется он меня админом не считает :)

Тут

Не заслужил :D

Телеграм сам решает!

/subscribe lomik/carbon-clickhouse all

А кажется он меня админом не считает :)

нет. дело в том что он перестал отвечать на сабскрайб

нет. дело в том что он перестал отвечать на сабскрайб

В личку мне отвечает

Хм

Тут была какая то фигя что он сообщения переставал слушать пока не выгонишь и не добавишь снова

/subscribe lomik/carbon-clickhouse all

Короче я его поправлю как нибудь

Нашел https://uptimerobot.com может кому пригодиться. У нас оповещения приходят в телеграм, как привязать оба сервиса здесь https://torunar.tk/2017/05/15/uptime-telegram.

Он совсем простой вроде

Отрывок из книги специально для фанатов Z)) «Anti-Pattern #5: Manual Configuration I’m sure we all can agree that automation is awesome. That’s why it’s surprising to me how often monitoring configuration is manual. The question I never want to hear is “Can you add this to monitoring?» Отрывок из книги: Julian, Mike. «Practical Monitoring.» O'Reilly Media, Inc., 2017

Справедливости ради, у систем, которые поддерживают push логику в целом нет такой проблемы. И да, Z умеет в push логику)

Шаблоны он тоже пушем себе добавит для нового сервиса?

Это классическая защита З - у нас есть автодискавери ответ на все

А про то, что нужно не только добавлять хосты как будто не замечают

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

Зато теперь еластик есть, который они считают tsdb ))

для логов?

нет. tsdb

для метрик you know

так у них уже есть реляционная бд для метрик

вместе к ней да

а. как интересно.

Справедливости ради, у систем, которые поддерживают push логику в целом нет такой проблемы. И да, Z умеет в push логику)

Мониторинг - это все таки процесс, а не "соберем все метрики в одной бд". Те же пороги для алертов (а без них мониторинга быть не может) автоматически вывести нереально.

это какая-то проф деформация. только в плохом смысле

от долгого пользования заббиксом что-то отмирает, возможно. у нас, например, есть люди, которые делают cat 10gb file> что-то там чтобы грепом забрать из него 4 числа и отдать заббиксу

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

самого эта собака еще не упарила ?

Это мой вымышленный друг, мне с ним хорошо ))

:)

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

Эти же упоротые товарищи считают нормальным слать логи в заббикс и смотреть как БД распухает нафиг

и еще они не любят смотреть в slow_queries_log при этом

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

Вообще, если от скана 10ГБ файла никуда не деться (это и надо в первую очередь чинить), то греп - неплохой вариант, он пробежится по файлу намного быстрее, чем наивная реализация поиска в каком-нибудь агенте

конечно деться. можно делать tail, для начала

там не так много сообщений в минуту. можно спокойно делать tail -n50

и снова скажу mtail

Вообще, если от скана 10ГБ файла никуда не деться (это и надо в первую очередь чинить), то греп - неплохой вариант, он пробежится по файлу намного быстрее, чем наивная реализация поиска в каком-нибудь агенте

Вспомнилась статья с habra про ускорение grep в сотни раз

Мониторинг - это все таки процесс, а не "соберем все метрики в одной бд". Те же пороги для алертов (а без них мониторинга быть не может) автоматически вывести нереально.

Пороги можно. Не так хорошо, как анализом работы приложения, но в целом можно попробовать. Но смысла в этом вроде мало.

Мониторинг - это все таки процесс, а не "соберем все метрики в одной бд". Те же пороги для алертов (а без них мониторинга быть не может) автоматически вывести нереально.

Запихнуть в json конфиги

Тогда можно автоматизировать

А про то, что нужно не только добавлять хосты как будто не замечают

Врага нужно знать в лицо, между прочим. Добавлять хосты не обязательно: https://www.zabbix.com/documentation/2.2/ru/manual/discovery/auto_registration. Реальные проблемы zabbix отлично описаны в faq, на самом деле.

конечно деться. можно делать tail, для начала

Положим, rsyslog может просто парсить логи "на лету", подсчитывая чего там надо и отдавая куда надо.

Врага нужно знать в лицо, между прочим. Добавлять хосты не обязательно: https://www.zabbix.com/documentation/2.2/ru/manual/discovery/auto_registration. Реальные проблемы zabbix отлично описаны в faq, на самом деле.

Я говорю про то, что автоматом он сможет только добавить новые хосты. Шаблоны новые от этого не появятся

Я говорю про то, что автоматом он сможет только добавить новые хосты. Шаблоны новые от этого не появятся

Ну камон) Шаблоны из воздуха браться должны что ли?) Они уже есть и прицепятся к хосту.

И кода должны

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

Алерты прома в ямликах, дашборды графана из json умеет тянуть

Алерты прома в ямликах, дашборды графана из json умеет тянуть

А шаблончики в xml и могут добавляться через api)

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

Алерты прома в ямликах, дашборды графана из json умеет тянуть

Из того, что я слышал, научится только в 5+. Хотя у нее есть api

Если для графаны есть куча готовых обвязок для этого, то для болезного нужно самому вприсядку наяривать, натыкаясь на разные версии апи и другие интересные места

5 уже бета и вот-вот выйдет, а за это время к Z успели прикрутить эластик только зачем-то.

ERROR: S client not available

Отрывок из книги специально для фанатов Z)) «Anti-Pattern #5: Manual Configuration I’m sure we all can agree that automation is awesome. That’s why it’s surprising to me how often monitoring configuration is manual. The question I never want to hear is “Can you add this to monitoring?» Отрывок из книги: Julian, Mike. «Practical Monitoring.» O'Reilly Media, Inc., 2017

вы явно не понимаете кейса, для которого создавался заббикс и контекста его (заббикса) создания

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

Я в целом предлагаю свернуть этот разговор, потому что за нами выедут) Алсо, нельзя развиватся, если весь продукт построен на концепциях, которые устарели. Тут только все выкинуть и сделать новый продукт. Ну, мне так кажется) Пройдет еще 20 лет и prometheus будет как Z или в лучшем случае, нагиос)

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

некоторым – не пора. Для некоторых З - идеальный вариант. Но работников подобных компаний в данном чате, думаю, нет. Кстати интересный вопрос – как бы мог выглядеть мониторинг через 20? Учитывая повсеместный ИИ и туманные вычисления?

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

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

это и заббикс умеет в общем-то. Нет, слишком просто. Тем более – для 20 лет эволюции :)

Ну, ему все равно нужны конфигурации. А вот этой штуке не нужно будет)

Хотя, судя по всему, будем собирать просто БЕЗУМНОЕ количество данных, вплоть до построчного выделения памяти) Потому что сложность растет и как оно все работает уже никто не понимает)

Хотя, судя по всему, будем собирать просто БЕЗУМНОЕ количество данных, вплоть до построчного выделения памяти) Потому что сложность растет и как оно все работает уже никто не понимает)

А вот это больше похоже на правду

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

субботнее пинание макаронного монстра? :)

Хотя, судя по всему, будем собирать просто БЕЗУМНОЕ количество данных, вплоть до построчного выделения памяти) Потому что сложность растет и как оно все работает уже никто не понимает)

просто собирать недостаточно – утонуть в этих данных элементарно, толку от них самих по себе – ноль

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

Хотя, судя по всему, будем собирать просто БЕЗУМНОЕ количество данных, вплоть до построчного выделения памяти) Потому что сложность растет и как оно все работает уже никто не понимает)

Да, будем. Всякие zipkin, opencensus они как раз в том числе и про это

главный вопрос даже не в том, как их собирать и как хранить (это интересный вопрос тоже, но он – не главный). Главный вопрос – как это все анализировать

ибо данных там будет очень много. И в них очень просто утонуть, это снижает их ценность до нуля

Скорее всего будет как-то так же. Топовые компании или разработчики будут диктовать, что надо собирать, а остальные будут собирать это и учится с ним работать :) Опять же, возможно я не прав, но мне кажется, что нет никаких проблем в большом количестве данных, если есть понимание, как извлечь нужные.

ибо данных там будет очень много. И в них очень просто утонуть, это снижает их ценность до нуля

Ждём статей от Гугла и фб у которых такие штуки уже давно

Для начала было бы неплохо хотя бы заиметь масштабируемый и отказоустойчивый мониторинг (сбор метрик+алерты по ним) с push-семантикой, который растягивается на несколько дц, умеет давить флапы, имеет продвинутую эскалацию и все это через CLI. То есть, было бы неплохо иметь, для начала, хорошо исполненный с технической точки зрения мониторинг с базовой функциональностью

Ждём статей от Гугла и фб у которых такие штуки уже давно

у фб всё в ин-мемори горилле

Касательно push/pull - это похоже на холивар, а остальные вещи я думаю, у крупных компаний свои точно есть.

у фб всё в ин-мемори горилле

Эт про мониторинг. У них есть и сборка трейсов

И пр

а, вы про трейсы обсуждали?

Мы обсуждали как будет выглядеть мониторинг будущего)

Ну будут вероятно приготовленные срезы с выбором по тегам

И водможностью спуска

@alexanderzobnin привет! а есть идеи переменную с типом интервал корректно в авторефреш и в кештаймаут прокидывать?

@alexanderzobnin привет! а есть идеи переменную с типом интервал корректно в авторефреш и в кештаймаут прокидывать?

Привет. Не уверен. Если в issues нет, то лучше создать.