telegraf юзаем

Глеб, а как генерируете конфигурации агента ? Руками?

Глеб, а как генерируете конфигурации агента ? Руками?

нам одной достаточно, у нас идентичные серверы везде

но вообще там несложно наверное

но вообще там несложно наверное

Понятно, спасибо. Если с https://github.com/lxndrp/pdh2zabbix не полетим пожалуй возьмемся за telegraf .

я вот не следил последнее время

а, кажется было, да

Как и обещал - анонс митапа про мониторинг от DevOps Moscow. Мониторинг(prom) облака(k8s) от Авито, автодискавери метрик от Окметра, Инцидент-менеджмент от Badoo https://devops-moscow.timepad.ru/event/712678/

А записи будут?

как понять, почему алертменеджер не групит алерты по alertname, хотя group_by: ['alertname', 'cluster', 'country', 'type', 'job', 'instance']

он будет по всем этим лейблам группировать

если все совпадают - будут сгруппированы

а если один не совпадет, то не будет, получается?

а чо делать, если я хочу и по instance и по alertname

inhibition?

ты сначала определись чо ты хочешь

ок, тогда другой вопрос. у меня есть алерт, типа, JobDown (for 3m), он warning, и есть JobDownCritical (for 5m), который critical

можно оба алерта в один упаковать ведь?

ты понимаешь что "группировка" - это не "упаковать два алерта в один"?

просто они пришлются вместе

судя по твоему описанию - тебе нужен inhibition

я понимаю, да, это уже другой вопрос

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

А записи будут?

Да, конечно

Есть у меня внутреннее решение, которое умеет line_protocol инфлюкса писать в кликхауз. Плюс графит протокол как его ест инфлюкс. Но слишком на коленке и медленновато. Что есть лучше? Т.е. насколько я буду изобретать велосипед, если решу нормально реализовать, а не на коленке?

Инфлюкс в кх?

А зачем тогда не графит сразу, там вроде есть готовое решение

Ну тогда его не было

Сейчас-то есть

А так, всё, что умеет line protocol попадает в клик

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

Вот это-то я и подхватил оттуда

Всем привет. Помогите вкурить, как запилить алерты в графане? Есть pid = true, нету = false. И алертилку (вот с ней самый главный вопрос)

А по другому никак никак? в смысле не в графане

а зачем костылить в другом месте?

потому что в другом месте оно к месту

какой datasource у графаны ?

prometheus

1) научись класть какую то метрику через node_exporter на тему того что нужный тебе pid есть 2) в prometheus есть свои алерты, лучше чем в графане

https://groups.google.com/forum/#!topic/prometheus-users/Y2htzgG9FjM

привет! подскажите плиз, правильно ли я понимаю что графхаус не создаёт предвычисленных роллапов? к примеру если я имею два rollup - неделя по 1 минуте и год по пол часа, то графхаус в базе будет хранить целый год данных “по минуте” и только в момент формирования запроса делать огрубление данных(если нужно).

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

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

роллап правила в КХ отрабатывают во время оптимайза партиции, в доке как то не очень конкретно было написано когда КХ это делает сам (и делает ли вообще), крон с курлом решает эту задачу

Это хорошая новость. в документации кажется этого вообще нет. запустил optimize, жду результата )

дорогие коллеги стоит задача технического мониторинга приложений (jvm в основном) и инфраструктуры (postgres, kafka, cassanrda) есть в команде упоротые фанаты ELK которые говорят что можно всё делать через metric beat, и графану поверх этого повесить я в целом не фетишист, но хотелось бы понять, чего ожидать и ещё вопрос, как алерты прикручивать поверх ELK если не брать xpack

почему не брать x-pack?

ну денег стоит же

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

ну денег стоит же

https://www.elastic.co/products/x-pack/open

то что его заопенсорсили, не означает что он стал бесплатным))

дорогие коллеги стоит задача технического мониторинга приложений (jvm в основном) и инфраструктуры (postgres, kafka, cassanrda) есть в команде упоротые фанаты ELK которые говорят что можно всё делать через metric beat, и графану поверх этого повесить я в целом не фетишист, но хотелось бы понять, чего ожидать и ещё вопрос, как алерты прикручивать поверх ELK если не брать xpack

Можно убить двух зайцев и взять Z с еластиком и страдать в 2 раза больше))

Коллеги, а помогите разгадать загадку 1) коннекчусь из браузера к серверу без прокси меряю время запроса получаю waiting TTFB в браузере 300ms ;( 2) смотрю в логи nginx для request_time и upstream_response_time там вижу картинку что оно все 0.200 sec откуда еще может быть 100ms ? левых? nginx же выдает правильные цифры в логе?

Коллеги, а помогите разгадать загадку 1) коннекчусь из браузера к серверу без прокси меряю время запроса получаю waiting TTFB в браузере 300ms ;( 2) смотрю в логи nginx для request_time и upstream_response_time там вижу картинку что оно все 0.200 sec откуда еще может быть 100ms ? левых? nginx же выдает правильные цифры в логе?

DNS?

DNS?

TTFB игнорирует dns

Коллеги, а помогите разгадать загадку 1) коннекчусь из браузера к серверу без прокси меряю время запроса получаю waiting TTFB в браузере 300ms ;( 2) смотрю в логи nginx для request_time и upstream_response_time там вижу картинку что оно все 0.200 sec откуда еще может быть 100ms ? левых? nginx же выдает правильные цифры в логе?

в твоем случае конечно надо изучить откуда эта сотня

вполне возможно +100 это расстояние между запуском запроса и его ответа

вот вот... я не понимаю просто как TTFB в браузере (повторюсь Proxy нет) может быть больше чем весь request_time в nginx ... ну ладно бы меньше

тоесть соединение между сетями +100мс

ну тогда connection был бы столько

тоесть nginx обрабатывает 200ms а сеть 100ms

ну типа nginx request_time это время когда отправлен последний байт клиенту ... но это ж вроде когда tcp ack на этот последний байт пришел

т.е. все равно непонятно

Коллеги, а помогите разгадать загадку 1) коннекчусь из браузера к серверу без прокси меряю время запроса получаю waiting TTFB в браузере 300ms ;( 2) смотрю в логи nginx для request_time и upstream_response_time там вижу картинку что оно все 0.200 sec откуда еще может быть 100ms ? левых? nginx же выдает правильные цифры в логе?

у вас между клиентом и nginx'ом логи которого вы смотрите нет какой-нибудь прокси?

у вас между клиентом и nginx'ом логи которого вы смотрите нет какой-нибудь прокси?

вот я только на это щас и уповаю щас попробую прямо на сервере через curl замерить

ERROR: S client not available

похоже что все таки что-то есть только непонятно где =(((

похоже что все таки что-то есть только непонятно где =(((

tcpdump в зубы

какое-нибудь дополнение против блокировок? :)

tcpdump в зубы

а что он покажет? у меня http если man in the niddle proxy будет то я ничего не пойму

добрый провайдер с транспарент-прокси?

ну =) это дополнение "отключено" сейчас

а что он покажет? у меня http если man in the niddle proxy будет то я ничего не пойму

адреса-то увидишь

man in the noodles

;) что? логи уже никто не читает?

всем графаночку облитую смузи подавай? ;)

читают. в кибане

Коллеги, а помогите разгадать загадку 1) коннекчусь из браузера к серверу без прокси меряю время запроса получаю waiting TTFB в браузере 300ms ;( 2) смотрю в логи nginx для request_time и upstream_response_time там вижу картинку что оно все 0.200 sec откуда еще может быть 100ms ? левых? nginx же выдает правильные цифры в логе?

а какое это имеет отношение к метрикам?

ну две метрики расходятся причем по неизвестным причинам хотя вроде расходиться должны не на 25% ...

ну ок =) спасибо в любом случае что навели на мысль проверить с локалхоста

Коллеги, а помогите разгадать загадку 1) коннекчусь из браузера к серверу без прокси меряю время запроса получаю waiting TTFB в браузере 300ms ;( 2) смотрю в логи nginx для request_time и upstream_response_time там вижу картинку что оно все 0.200 sec откуда еще может быть 100ms ? левых? nginx же выдает правильные цифры в логе?

Это разница во времени на передачу данных по сети

Nginx request time начинается когда получен запрос, а ttfb когда открыто соединение

Заканчивается nginx request time когда ответ готов и началась передача клиенту, а curl ttfb когда первый байт ответа получен

Nginx request time начинается когда получен запрос, а ttfb когда открыто соединение

ок. может какая нибудь настройка в nginx какой то обратный dns resolve делает... щас tcpdump посмотрю на эту тему

influxdata/kapacitor was tagged: v1.5.0-rc2 Link: https://github.com/influxdata/kapacitor/releases/tag/v1.5.0-rc2 Release notes: cut v1.5.0-rc2

Коллеги, а помогите разгадать загадку 1) коннекчусь из браузера к серверу без прокси меряю время запроса получаю waiting TTFB в браузере 300ms ;( 2) смотрю в логи nginx для request_time и upstream_response_time там вижу картинку что оно все 0.200 sec откуда еще может быть 100ms ? левых? nginx же выдает правильные цифры в логе?

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

;) что? логи уже никто не читает?

ты из Баку ?

ты из Баку ?

=) нет, не из баку =)

понятно )) значит аутсорсишь )) я про домен *.az

;) ну скорее консультирую и основную проблему вижу, но там какая то дополнительная с ttfb который непонятно откуда берется

Сделал лэндинг, зацените http://akumuli.org/

как обычно на лендингах: минимум информации, максимум пустого места

В лучших традициях

Сделал лэндинг, зацените http://akumuli.org/

Выглядит хорошо. Еще бы главную страницу вики обновить, а то как-то обрезанно выглядит. Можно оглавление добавить вместо боковой менюшки Pages.

и доке убунта 14.04

Ну это потому что пакеты только под 14.04 собираются, т.к. Travis ci ещё не сделали 16.04