Друзья, Сообщество DevOps в России помогает готовить конференцию по DevOps и эксплуатации RootConf (http://rootconf.ru/), которая пройдёт в Москве, Сколково, 28 и 29 мая. На конференции мы собираемся поговорить о разработке, тестировании и эксплуатации IT-проектов через призму DevOps: логгирование и мониторинг, технологии виртуализации и контейнеризации, управление конфигурацией, непрерывное развёртывание и деплой, технологии отказоустойчивости и катастрофоустойчивости, а также управление в эксплуатации. Уже прошло много времени с тех пор, как мы озаботились мониторингом, а до сих пор мониторинг сакс, люди умеют настраивать системы мониторинга, но не знают как мониторить свой проект или наоборот. Так ли плох Zabbix и так ли хорош Prometheus, как уговорить разработчиков описывать свой продукт в виде метрик, как эти метрики разбирать — ничего непонятно. Если вам все понятно или хотя бы немного из этого или вы знаете людей, которые с чем-то разобрались, то мы ждем заявки на доклады и от вас и от них. Приглашаем докладчиков! Я в ПК, готов помочь с выбором тем. Организаторы обещают сделать всё, что мы придумаем и привести всех докладчиков, кого мы придумаем, за свой счёт.

Друзья, Сообщество DevOps в России помогает готовить конференцию по DevOps и эксплуатации RootConf (http://rootconf.ru/), которая пройдёт в Москве, Сколково, 28 и 29 мая. На конференции мы собираемся поговорить о разработке, тестировании и эксплуатации IT-проектов через призму DevOps: логгирование и мониторинг, технологии виртуализации и контейнеризации, управление конфигурацией, непрерывное развёртывание и деплой, технологии отказоустойчивости и катастрофоустойчивости, а также управление в эксплуатации. Уже прошло много времени с тех пор, как мы озаботились мониторингом, а до сих пор мониторинг сакс, люди умеют настраивать системы мониторинга, но не знают как мониторить свой проект или наоборот. Так ли плох Zabbix и так ли хорош Prometheus, как уговорить разработчиков описывать свой продукт в виде метрик, как эти метрики разбирать — ничего непонятно. Если вам все понятно или хотя бы немного из этого или вы знаете людей, которые с чем-то разобрались, то мы ждем заявки на доклады и от вас и от них. Приглашаем докладчиков! Я в ПК, готов помочь с выбором тем. Организаторы обещают сделать всё, что мы придумаем и привести всех докладчиков, кого мы придумаем, за свой счёт.

Саша канал для конфы есть ?

Есть чатик конфы t.me/ritfest если ты об этом

У тех кто использует carbon-clickhouse, не было проблемы что часть путей метрик не пишется в graphite_tree?

Молюсь за вас, братие

В общем у кого есть, что рассказать, но не уверен, не знает, не готов, пишите мне, я помогу

Ребят, кто чем мониторит http endpoint’ы? Так чтобы, например, в yaml описать все и запустить (локально)? Нужно что-то вроде https://github.com/ivpusic/httpcheck

prometheus + blackbox_exporter?

Локально!

В кластере и куб проверит

а почему из прометея убрали протобаф из коммуникации?

prometheus + blackbox_exporter?

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

Эм ... возможно я не совсем понимаю, но зачем мониторить что-то локально?

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

официально поддерживаемый производителем экспортер выглядит как костыль ))) А что для Вас не костыль, позвольте полюбопытствовать?

Эм ... возможно я не совсем понимаю, но зачем мониторить что-то локально?

Не мониторить, а протестировать работоспособность поднятого локально сервера

Ну есть же всякие InSpec для тестов

Нагрузочное тестирование, что ли?

а почему из прометея убрали протобаф из коммуникации?

https://github.com/prometheus/prometheus/issues/2788 ответ на вопрос выше

Ну есть же всякие InSpec для тестов

Inspec это руби, нафиг руби. Хочется бинарь гошный) Мы уже писали такую утилиту, сейчас стоит вопрос поддерживать её дальше или не велосипедить

Inspec это руби, нафиг руби. Хочется бинарь гошный) Мы уже писали такую утилиту, сейчас стоит вопрос поддерживать её дальше или не велосипедить

DSL все равно надо на чем-то писать. На руби получается отличный DSL.

У нас был в yaml/toml

Все отлично, кроме руби

Locust?

https://github.com/aelsabbahy/goss

Уже кучу лет есть goss

Уже кучу лет есть goss

Есть, но он достаточно топорен. Нужна хотя бы валидация корректного xml/json. Подстановка доменов для теста. Он ближе к inspec’у, ориентирован на систему

Тогда возвращаемся к руби

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

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

Можно, но тот человек что начинал проект, давно ушел, а у меня и без того задач вагон(

Что не так? Ну да, у меня capistrano && chef, но еще и inspec, точно не хочу)

У нас был в yaml/toml

это пока вам не нужно что-то по-настоящему сложное сделать. У меня этот ямл есть в ансибле, и от, к примеру, циклов мне хочется кричать

А шеф тестируется чем?

Так там сложное и не нужно

А шеф тестируется чем?

Ничем. Им сейчас только базовая настройка сервера производится, все остальное в контейнерах

Молюсь за вас, братие

?

оч тупой вопрос. На go клиенте к прому, считаю latency. Оно же туда в наносекундах должно передаваться или нет?

latency.WithLabelValues("servcieProvider").Observe(float64(int64(date.GPS.GGNSTimestamp) - t.Unix()))

оч тупой вопрос. На go клиенте к прому, считаю latency. Оно же туда в наносекундах должно передаваться или нет?

в секундах

в секундах

уже выяснил. В нано секундах

а должно быть в секундах

у тебя там float64, разница между секундами и наносекундами будет в множителе

https://www.robustperception.io/who-wants-seconds/

а должно быть в секундах

вот тут не понял

зачем писать метрики не в стандартных единицах?

ну например, латенси меня интересует в микросекундах

пиши в секундах

будет 0.000332сек

с дробной частью?

в float

флоат дорогой очень

то есть 3.32*10^-4

в прометее это так и так будет float64

флоат дорогой очень

он по умолчанию зачем то в golang клиенте

и еще он погрешности имеет

он по-умолчанию не в golang клиенте

он по-умолчанию в прометее

других типов данных в прометее вообще нет

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

ERROR: S client not available

тебя интересует время, а не наносекунды

инфа 100%

дробная часть подарит мне только погрешность

что такое "дробная часть", если у тебя _всегда_ float64

большая ли разница, записать в значение число 239.00000 (подразумевая наносекунды) или записать 0.000000239 (подразумевая секунды) ? и там и там тип данных будет float64

большая ли разница, записать в значение число 239.00000 (подразумевая наносекунды) или записать 0.000000239 (подразумевая секунды) ? и там и там тип данных будет float64

более того, и там и там мантисса будет одна и та же, потому что так ieee 754 внутри устроен

ладно, может я не шарю

а разница в порядке дополнительной погрешности не даст

пойду читать матчасть

погрешность появляется только на мат операциях?

нет, она всегда есть при ieee754

и ты от него никуда не денешься в прометее, потому что всегда данные в float64

спс

пойду читать

более того, и там и там мантисса будет одна и та же, потому что так ieee 754 внутри устроен

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

но погрешность будет в любом случае

>>> math.frexp(239.00000) (0.93359375, 8) >>> math.frexp(0.000000239) (0.501219328, -21)

есть грабли что поле $request может содержать битый unicode, и $status может быть 000 (если не обернуть в кавычки, а писать числом, то стандартный питонячий json на этом ломается)

есть грабли что поле $request может содержать битый unicode, и $status может быть 000 (если не обернуть в кавычки, а писать числом, то стандартный питонячий json на этом ломается)

для этих граблей тоже есть фикс. читать сюда: http://nginx.org/ru/docs/http/ngx_http_log_module.html#log_format

ты намекаешь на escape=json??)

класть такое в эластик - жирно) если логгировать "очень простые запросы" в эластик, то очень быстро понимаешь что логгирование это вычислительно более сложная операция чем собственно обработка запроса)

надо очень хорошо подумать, нужен ли собственно лог

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

influxdata/telegraf was tagged: 1.6.0-rc1 Link: https://github.com/influxdata/telegraf/releases/tag/1.6.0-rc1 Release notes: Telegraf 1.6.0-rc1

influxdata/telegraf was tagged: 1.6.0-rc1 Link: https://github.com/influxdata/telegraf/releases/tag/1.6.0-rc1 Release notes: Arch Platform Package SHA256 amd64 Debian [`telegraf_1.6.0~rc1-1_amd64.deb`](https://dl.influxdata.com/telegraf/releases/telegraf_1.6.0%7Erc1-1_amd64.deb) `3bf1b42ca9a8c54daf03627628b97e4640ac97d4c0d171dc685b7fdf6ada6104`... More

influxdata/telegraf was tagged: 1.6.0-rc2 Link: https://github.com/influxdata/telegraf/releases/tag/1.6.0-rc2 Release notes: Telegraf 1.6.0-rc2

быстро они

да )