Это конечно прикольно, но нам пока такое не нужно. Выбрать бы для начала как в ванильном формате передавать эти всякие счетчики.

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

Это конечно прикольно, но нам пока такое не нужно. Выбрать бы для начала как в ванильном формате передавать эти всякие счетчики.

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

вот кстати для statsd не знаю есть ли поддержка тегов

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

а теги IMHO позволяют одну и туже метрику раскидывать на разные подмножества не грузясь конвенциями =)

ну и потом наверное из grafana в clickhouse через clickhouse-grafana можно ходить а не через graphite-clickhouse если припрет и делать SQL запросы

Ребят, а как правильно структурировать пути к метрикам? Вот у нас большая монорепо в основном на питоне, имеется множество разных кравлеров. Нормально ли отражать пути к сорцу который сгенерировал метрику, внутри пути к метрике? Например src.org.scripts.facebook.crawl_profiles.py:persist. Что кроме точки имеет семантичкское значение в этих путях, где почитать?

Стек я таки собрал и настроил как вот тут https://github.com/kolobaev/graphite-clickhouse-tldr

Я так понимаю что графит он чисто для numeric time series.

Но в коннекторе Графаны к КХ есть демо дешборд который показывает топ ИП адресов, и мне интересно чем следует такие данные заливать в Кликхауз? bioyino/carbon-clickhouse вроде бы не подойдет.

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

дело оказалось вот в чем:
у прометеуса такие селекторы были:
   serviceMonitorSelector:
     matchLabels:
       release: prom

а у сервис монитора:
component: stolon-keeper

добавил к сервис монитору лэйбл
release: prom
и все заработало.  
правильно ли так делать? или эти лэйблы надо в самом конфе прометея добавлять для разных сервис мониторов:

ну это ... я так понимаю, для того чтобы сформировать список endpoint в prometheus
там в pod рядом с prometheus запускается еще один контейнер config-reloader
который скрейпит в k8s kind: ServiceMonitor и генерит из них уже конфиги прометеус, отыскивая сервисы которые прописаны в ServiceMonitor

дело оказалось вот в чем:
у прометеуса такие селекторы были:
   serviceMonitorSelector:
     matchLabels:
       release: prom

а у сервис монитора:
component: stolon-keeper

добавил к сервис монитору лэйбл
release: prom
и все заработало.  
правильно ли так делать? или эти лэйблы надо в самом конфе прометея добавлять для разных сервис мониторов:

всем привет, вопрос по прометею
expr: time() - rates_last_updated{environment="mainnet",source="1"} > 3600
expr: time() - rates_last_updated{environment="mainnet",source="2} > 3600
можно это как то запихать в один expression или надо делать несколько. Ну и где можно про это почитать подробнее а то в офф документации очень куцо написано