как связаны ansible и dnf?

Человек говорил про yum

а, с этой точки зрения. Возможно. Я не знаю. К yum много вопросов

Ансибл в каком-то нон продакшен режиме умеет в 3-й питон

они сами говорили, что это глубокая альфа, там нет 80% модулей, если не 90%

и все работает крайне нестабильно

Зато можно бегать по граблям

Привет всем. Нужна подсказка по графане, а именно - как правильно вычесть один график из другого. Нюанс в том, что не всегда есть точки, снятые в один момент, их мы видим как "null value connected". Обычным diff, как я понял, без наличия точек снятый в один момент вычесть графики не смогу. Как быть?

Сделать avg и вычитать А из Б

Точки сильно раскиданы по таймлайну?

Раскиданы не сильно, точки дискретные, 0 или 1.

Хм, не знаю тогда

Привет всем. Нужна подсказка по графане, а именно - как правильно вычесть один график из другого. Нюанс в том, что не всегда есть точки, снятые в один момент, их мы видим как "null value connected". Обычным diff, как я понял, без наличия точек снятый в один момент вычесть графики не смогу. Как быть?

Поправить код и снимать точки всегда

Например если точки нет то слать все равно что то значимое - 0 например

Поправить код и снимать точки всегда

Точки - факт того, что произошло событие. Произошло первое событие - отправляет единицу. второе событие - ноль. слать трапы постоянно - неудобно

Точки - факт того, что произошло событие. Произошло первое событие - отправляет единицу. второе событие - ноль. слать трапы постоянно - неудобно

А какой смысл имеют null тогда?

null - значит нет изменений

И какой результат вычитания числа из null или null из числа хочется?

null - значит нет изменений

Ну так шли прошлую точку

то есть значение берём как предыдущее, да

Или если графит, то накатывай keeplastvalue

то есть значение берём как предыдущее, да

А что мешает продолжать в приложении слать что оно там слало?

А что мешает продолжать в приложении слать что оно там слало?

некрасиво слать трапы постоянно

Почему?

Некрасиво в time series базу складывать события

А слать прошлое значение очень даже ок

как вариант да, но так существеннно увеличивается количество точек

допустим события могут не происходить сутки. а точность до минуты. придётся слать каждую минуту

как вариант да, но так существеннно увеличивается количество точек

А ты в чем их хранишь?

графит

графит

Виспер?

да, виспер

А в чем тогда проблемы?

Тогда я не понимаю какая разница много точек или мало

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

А я не думаю что у тебя даже близко столько

Файл все равно преаллоцирован

"Или если графит, то накатывай keeplastvalue" - есть смысл смотреть в эту сторону?

И что нулл, что число съест свои 12 байт

"Или если графит, то накатывай keeplastvalue" - есть смысл смотреть в эту сторону?

Как временное решение

Я бы слал каждую точку

за забикс тут не любят?

за забикс тут не любят?

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

ну ладно)

а чем сейчас можно snmp собирать?

трапы точнее

про трапы в тайланде шутили уже?

про трапы в тайланде шутили уже?

не, ты тут первый петросянить начал

а чем сейчас можно snmp собирать?

можно или модно?

можно или модно?

интересны оба варианта

и на чем сейчас строят кореляцию событий в мониторинге?

Подскажите по конфигу прометея: - source_labels: [_ _address_ _] regex: '(.*)' replacement: '_ _meta_kubernetes_pod_host_ip:9913' target_label: _ _address_ _ Как я могу сделать что-то подобное? Хочу, чтобы переменная "_ _meta_kubernetes_pod_host_ip" разворачивалась в значение. ( я специально пробелы поставил, чтобы телеграм не делал текст наклонным. Там две земли _ _ подряд на самом деле)

Некрасиво в time series базу складывать события

а куда складывать?

а куда складывать?

куда-нибудь в другое место :)

или конвертировать в нормальные time-series без дырок

имеющих сакральный смысл

- source_labels: [__address__] regex: '(.*)' replacement: '__meta_kubernetes_pod_host_ip:9913' target_label: __address__

Подскажите по конфигу прометея: - source_labels: [_ _address_ _] regex: '(.*)' replacement: '_ _meta_kubernetes_pod_host_ip:9913' target_label: _ _address_ _ Как я могу сделать что-то подобное? Хочу, чтобы переменная "_ _meta_kubernetes_pod_host_ip" разворачивалась в значение. ( я специально пробелы поставил, чтобы телеграм не делал текст наклонным. Там две земли _ _ подряд на самом деле)

ты куда эту метку хочешь складывать-то?

ты куда эту метку хочешь складывать-то?

Я хочу, чтобы адрес был = внешний_адрес_ноды. И чтобы он с него метрики брал. Там экспортер. Может, я, конечно, чего-то не понимаю...

Чтобы это был endpoint

то есть тебе надо взять pod_host_ip и положить в __address__?

Да.

ну так и пиши

- source_labels: - __meta_kubernetes_pod_host_ip regex: '(.*)' target_label: __address__ replacement: $1:9913

берёшь метку

матчишь её на регэксп (.*)

дописываешь :9913

и кладёшь в метку __address__

Ааа. Блин. Наоборот просто сделать надо было. Спасибо!

то есть значение берём как предыдущее, да

fill(previous)?

fill(previous)?

это где такое искать

спасибо!

Колгги, а кто-нибудь скрещивал графану и ntopng?

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

imho - лучше другой

я тоже за другой

если нет каких-либо причин

ок, спасибо

(типа софт не умеет в два индекса ходить и т.п.)

а вообще - почему так лучше? просто интересно

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

а вообще - почему так лучше? просто интересно

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

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

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

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

ну тут зависит от ловкости рук

ну понятно) ок, спаибо

ну вообще не вижу ничего плохого в том, что дев и прод в одном кластере. Мало того, что их надо засунуть в разные индексы, дак вы еще и можете настроить разные правила по очистке этих индексов. Например продовские данные важные и вы храните на A серверах по B дней. А дев данные вы во-первых пишите с оч большой частотой уровня trace, дак еще и срок жизни можете им поставить в C дней и хранить только в одном экземпляре. Удобство в том, что у вас одна точка входа для поиска логов. Однако если данных ну просто пипец много или вы любите именно настраивать сам elk стэк (индексы там подкручиваете постоянно) или же вы хотите именно ограничить работу с продовскими логами (чтобы 400 человек не искало по тексту что-то постоянно) , то тогда определенно точно стоит сделать отдельный кластер

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

разработчики решат что-нибудь погонять в дебаг моде

и насрут тебе пару ТБ логов

за пол дня

или будут тебе слать 100к сообщений в секунду )

они еще могут запустить jMeter и попутно сеть уложить :)

поэтому не очень хорошая идея смешивать это все