забей на IF-MIB для счётчиков байтов на интерфейсе

бери HC

...или как они там...

- name: ifHCOutOctets oid: 1.3.6.1.2.1.31.1.1.1.10 indexes: - labelname: ifDescr type: Integer32 lookups: - labels: [ifDescr] labelname: ifDescr oid: 1.3.6.1.2.1.2.2.1.2

вот такого вида у меня в snmp_exporter

кафка - всё-таки очередь

скорее брокер не?

Инфа летит из таблицы IF-MIB::ifTable. Конкретнее ifInOctets, ifOutOctets по интерфейсам. [пример как вижу в инфлюксе] ifInOctets=324670323i ifOutOctets=227721653i

А NON_NEGATIVE_DERIVATIVE() не для этого? Нужно bits/sec получить?

@pipopolam когда у тя сломается telegraf при следующем обнволении — знай. я виноват тому. https://github.com/influxdata/telegraf/pull/2973

жопа ты...

:D

да. я такой.

ггг

я в шоке от факта самой таблицы.

но это хоть какие то правила

угу

Хтоничненько...

@pipopolam когда у тя сломается telegraf при следующем обнволении — знай. я виноват тому. https://github.com/influxdata/telegraf/pull/2973

У прометея в вики на гитхабе была табличка

А, оно и есть

ребята, а прометеус запускать отом каким-то демоном или скриптом?

Я через systemd запускаю

ага, ну уже лучше

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

?

Докер композ+ системд

могу демоном поделится

как сервера, так и алертменеджера

как сервера, так и алертменеджера

если не далко то поделись

Докер композ+ системд

к докеру только подходим

к докеру только подходим

там в любом случае обычные бинари

в системд завернуть не составит труда

далековато, до конца дня в лс отдам url с плейбуком, который все настраивает

Докер композ+ системд

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

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

а в 5м проксмоксе будет докер?

а в 5м проксмоксе будет докер?

если верить ребятам авторам то да

почитай оф форум

вопрос когда будет релиз, ато в этом месяце ток 2я альфа вышла

кстати, сейчач на херцнере аукцион идет, продают по ок цене дедики на i7

и 64 гб озу за ок цены

50-60 баксов

если верить ребятам авторам то да

хотелось бы конкретный тред

пока вижу только костыль с портейнером

к докеру только подходим

лучше мимо проходите

+1

Если можно обойтись без него - рекомендую это сделать

https://forums.servethehome.com/index.php?threads/proxmox-ve-5-0-and-docker-with-a-web-gui.13902/

Поделитесь, если не жалко, своим мнением относительно такой вот штуки - допустим есть БД в которую пишутся метрики, которая умеет теги и всякие интеграции (графана, collectd и тд), эта БД умеет работать только на одной машине, при этом производительности точно хватает на все (пропускная способность - миллионы точек в сек., на чтение - десятки тысяч запросов в сек, cardinality - десякти миллионов). К этой БД можно купить подписку на сервис, который обеспечивает HA, работает он так: в сеть ставится прокси (возможно не один а с hot standby), все метрики пишутся через этот прокси, при этом если БД падает данные не теряются, а отправляются в облако, когда БД поднимается (например из бэкапа после смерти жесткого диска) - она сразу становится доступна на запись и при этом то что было отправлено в "облако" постепенно в нее возвращается (без перерыва в обслуживании). Т.е. это конечно не кластеризация, но эффект почти такой же. Разве что метрики нельзя смотреть пока БД снова не поднимется. Собственно вопрос - вам такое было бы интересно?

если будет совместимо с прометеем, то интересно

вопрос в том, где это мифическое "облако"

вопрос в том, где это мифическое "облако"

это важно?

конечно важно

лично я не хочу сливать в какие-то сторонние сервисы свои данные, я хочу всё у себя хранить

конечно важно

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

Я бы написал свой прокси

Это дело недели

нахрен мне вообще трафик гонять в какой-то левый сервис через полмира?

нахрен мне вообще трафик гонять в какой-то левый сервис через полмира?

во первых, возможна колокация, во вторых - гонять не весь трафик, трафик гонится только тогда, когда БД недоступна

Я бы написал свой прокси

т.к. ты уже писал всякие прокси для графита, поэтому такой вариант возможен за неделю :)

т.к. ты уже писал всякие прокси для графита, поэтому такой вариант возможен за неделю :)

В проксе на простом уровне ничего сложного нет

В проксе на простом уровне ничего сложного нет

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

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

В простом случаи это приемник который данные складывает в очереди

ERROR: S client not available

kafka что ли?

И пишет из каждой очереди в свою бд

Ну или да, в кафку и из кафки потом

а из кафки само доставится

но это же сложно, нужно поддерживать кафку и какой-то свой код и все это деплоить

project vulkan?

а твою штуку будет хуяк-хуяк-и-в-продакшн?

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

а твою штуку будет хуяк-хуяк-и-в-продакшн?

ее будет проще, я исхожу из того, что всякие распределенные БД сложно эксплуатировать в проде (у меня есть опыт с неколькими), можно словить split-brain, например, это все сложно апдейтить, мониторить и бэкапить, а если у тебя есть БД которая может крутиться на одной машине - это все сильно упращает, операции становятся более традиционными. Это как поднять MySQL и работать с одним инстансом, настроив периодический бэкап, против того чтобы поднять кластер какого-нибудь Elastic-а. Сильно проще.

ну хз, эластик нифига не рокет-саенс нынче

а у мускуля миллиард крутилок

ну хз, эластик нифига не рокет-саенс нынче

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

мне про это не надо рассказывать

ее будет проще, я исхожу из того, что всякие распределенные БД сложно эксплуатировать в проде (у меня есть опыт с неколькими), можно словить split-brain, например, это все сложно апдейтить, мониторить и бэкапить, а если у тебя есть БД которая может крутиться на одной машине - это все сильно упращает, операции становятся более традиционными. Это как поднять MySQL и работать с одним инстансом, настроив периодический бэкап, против того чтобы поднять кластер какого-нибудь Elastic-а. Сильно проще.

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

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

это справедливо в каких-то случаях, а в каких-то нет, нужно сравнивать что-то определенное, иначе сравнение сферических коней в вакууме получается

это справедливо в каких-то случаях, а в каких-то нет, нужно сравнивать что-то определенное, иначе сравнение сферических коней в вакууме получается

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

Слушайте, а если у меня к примеру есть 4 фронта, которые проксируют запросы на 20 бекендов. если я сделаю в графите разрез в виде $front_host.$backend_host то у меня метрики будут занимать места х4, чем если бы я их хранил в виде $backend_host ? какие то дорогие разрезы получаются )

я прав или я прав ?

Кто может объяснить или подсказать где почитать про store: true в эластике? В каких кейсах это реально нужно? Храню в эластике документы, у них есть поле сумма по которому строятся агрегации и делаются запросы ( в т.ч. по другим полям) _source хранится. Как реально работает store: true и зачем оно? По доке не очень понятно

это просто оптимизация чтобы не выдергивать целиком _source если вы периодически выдираете value какого то поля

ну а для агрегаций?

а какая разица ?

если вы просто фильтруете, то _source не будет подниматься, если считаете то _source поднимется. если сделаете его store то не будет и во втором случае подниматься

Кто может объяснить или подсказать где почитать про store: true в эластике? В каких кейсах это реально нужно? Храню в эластике документы, у них есть поле сумма по которому строятся агрегации и делаются запросы ( в т.ч. по другим полям) _source хранится. Как реально работает store: true и зачем оно? По доке не очень понятно

https://t.me/elasticsearch_ru

спс

иии?

В е решился

Centreon community

Version