Агрегации часто помогают

Ребя а давайте буферами помереемся

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

У нас были по 80гб вроде бы

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

Ну а кроме шуток для carbon-c-relay кто какой буфер (иммется в виду размер) использует?

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

Ну а кроме шуток для carbon-c-relay кто какой буфер (иммется в виду размер) использует?

какой именно буфер интересует?

Ну а кроме шуток для carbon-c-relay кто какой буфер (иммется в виду размер) использует?

-q 200000000

хм

есть у меня график один не хороший

дропы на нем

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

-q 200000000

вероятно серверов в кластерах немного. Мы используем -q 3000000

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

-q это очередь на выходе с релея. одна очередь на каждый destination

а вообще альтернатив carbon-c-relay не особо много?

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

заню еще grafsy

а вообще альтернатив carbon-c-relay не особо много?

@Civiloid пилит замену https://github.com/go-graphite/gorelka

если хочешь юзать - читай внимательно readme

там есть пока пара серьезных недоделок

однако у нас один carbon-c-relay спокойно прокачивает через себя до 1 000 000 метрик в секунду

но в целом оно метрики роутит

это тоже знаю

и быстро

рабочая нагрузка 150К-300К

он не любит много метрик через один коннект. ни на вход ни на выход. если это ваш кейс то можете попробовать https://github.com/chbuescher/carbon-c-relay

Кому релевантно @ru_gitlab

рабочая нагрузка 150К-300К

Да, это похоже мой кейс, у меня бывают спайки до 3M

Да, это похоже мой кейс, у меня бывают спайки до 3M

в секунду?

в секунду получается что около 200 разом прилетает

размер буфера не влияет в целом на производительность. Он позволяет придержать метрики в памяти если store или следующий релей лежит.

то есть при дропах на релее проблема как правило не в нем

вот и у меня такая догадка была :(

разве что правила аггрегации и изощренная логика с кучей regex могут к этому приводить

не аггрегации нету, немного изощренный роутинг

а куда с релея данные уходят? что там? go-carbon carbon-cache?

carbon-clickhouse

но судя по его метрикам не он витноват

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

carbon-clickhouse

здесь не подскажу. Опыта нет. Автор присутствует здесь в канале

go-carbon у нас тянул до 1000000 точек в секунду(IN) на один сервер

в норме держим менее 300К

попробую форк - глядишь поможет

он не любит много метрик через один коннект. ни на вход ни на выход. если это ваш кейс то можете попробовать https://github.com/chbuescher/carbon-c-relay

у нас он кажется в go-graphite форкнут

но я не уверен

а, не форкнут

go-carbon у нас тянул до 1000000 точек в секунду(IN) на один сервер

carbon-clickhouse и 2млн в секунду держит легко

мда, увеличение буфера нисколечко не помогло

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

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

по моему c-relay не посчитает такие метрики у себя в статистике

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

А есть кто собирает с filebeat его метрики?

metricbeat? ?

metricbeat? ?

не-не. это намек на ELK стек для мониторинга и статистики. для меня это не вариант

не-не. это намек на ELK стек для мониторинга и статистики. для меня это не вариант

Елк неплох. Но если нужны метрики, именно метрики, то думаю, что елк не вариант

Для логов и json'ов - да, он божественнен

Кек

как

мм, а как дебажится prometheus? только по логам? Есть ощущение что не собираются метрики самого себя.

мм, а как дебажится prometheus? только по логам? Есть ощущение что не собираются метрики самого себя.

загляни в /targets в веб-морде

ERROR: S client not available

Там нет самого сервера prometheus - речь о селф метриках. Хотя в конфиге: scrape_configs: - job_name: 'prometheus' scrape_interval: 5s static_configs: - targets: ['localhost:9090']

> там нет самого сервера а должен быть

Елк неплох. Но если нужны метрики, именно метрики, то думаю, что елк не вариант

Чего? а Timelion?

отсюда и вопрос

metricbeat же под него же и заточен

дратути

Там нет самого сервера prometheus - речь о селф метриках. Хотя в конфиге: scrape_configs: - job_name: 'prometheus' scrape_interval: 5s static_configs: - targets: ['localhost:9090']

Посмотри в логи прома: он пишет, какой конфиг файл использует. Также стоит проверить, что тот файл действительно такой, каким ожидается

Да, уже разобрался - не правильно понял структуру. Указывал несколько раз scrape_comfig, а не внутри job. Проверял с помощью promtool конфиг, но ему на это пофигу.

это надо yaml изучать, а не прометей

Ну да. Пром тупо игнорит кривые инструкции если они не фатальны для его работы.

не игнорит он ничего

игнорирует в данном случае

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

Дык это относится к фатальным ошибкам :)

туту я могу поспорить

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

зачем вообще руками генерировать ямль файлы

с таким же вопросом. можно спросить - зачем вообще его использовать

вопрос из разряда - я дартаньян

нет, это странный вопрос

зачем вообще конфиги руками делать?

разве что от большой скуки

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

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

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

wat

Кто-нибудь мониторит vsphere, hp ilo? Через telegraf? Или лучше даже не пытаться, нашел только powershell скрипты, которые пишут напрямую в бд.

ilo можно через ipmi частично мониторить

ilo можно через ipmi частично мониторить

Просто добавить как плагин?

ну там надо смотреть что доступно именно в твоей платформе