Если нужны консультации, помощь или саппорт - обращайтесь info@victoriametrics.com

лучше тикет систему прикрутите

ибо емейлы не всегда норм и удобно

ну и форму обратной связи, ибо ну блин, 2019

Например модификация лейблов кубернетес сервисов/подов при группировке

см. https://5pi.de/2017/11/09/use-prometheus-vector-matching-to-get-kubernetes-utilization-across-any-pod-label/

На примеры использования ExtendedPromQL и подобных манипуляций можно посмотреть тут - http://play-grafana.victoriametrics.com:3000/d/4ome8yJmz/node-exporter-on-victoriametrics-demo?orgId=1

Парни, а что насчет Алертменеджера? ) начали? Где репа?)

Не начали пока

В июне начнём тогда же и будет решение

да, нужно что-нибудь прикрутить. Но тикетная система все равно сводится к общению по емейлу, просто в тикете видна история этого общения. А так она видна в gmail thread'е :)

функции для работы с лейблами удобны в следующих случаях:
- alias - удобна для указания общего имени для набора метрик. Например, alias(rate(http_requests_total), "http_requests_rate") вернет временные ряды с именем http_requests_rate. Движок promql удаляет имя http_requests_total из временных рядов внутри rate, поэтому в итоге получаются временные ряды без имени. alias позволяет быстро добавить нужное имя для метрик.
- label_set - удобна для установки дополнительных лейблов. Например, label_set(memory_usage, "foo", "bar") добавит лейбл foo со значением bar во все временные ряды memory_usage.
- label_transform - удобна для преобразования лейблов во временных рядах. Например, label_transform(q, "ip", "\\.", "-") заменит точки на тире во всех лейблах ip из временных рядов q. Т.е. айпишка 1.2.3.4 преобразуется в 1-2-3-4.

вышла версия v1.18.6 , которая умеет записывать в лог медленные запросы и которая умеет парсить числа в строковых данных в influx line protocol. @vnsoldatov , вторая фича для вас :) см. https://github.com/VictoriaMetrics/VictoriaMetrics/releases

привет, а если я отправляю в VM метрики в формате graphite каим образом я могу прочитать их в VM?

промкуэлем же

Насколько я понял, сейчас VM можно кормить метриками через telegraf/graphite/opentsdb протоколы, а через remote write только прометей пишет. Так?
Если хочется исключить из схемы прометей и кастомный коллектор будет сам через remote write писать - это нормальный сценарий будет или есть какие грабли по дороге? Должен ли кастомный коллектор пачки сам собирать перед insert или можно оставить это дело VM?

@valyala спасибо, теперь понятно про ts. Либо чаще опрашивать, либо смириться.

Сделал rpm для VM.
https://copr.fedorainfracloud.org/coprs/antonpatsev/VictoriaMetrics/
код тут
https://github.com/patsevanton/victoriametrics-rpm

я пока не использую VM. Что еще добавить в rpm? если конфиги и т.д., то нужны их примеры. отправьте мне их в личку. я добавлю в rpm

да, через remote write пишет только прометей, но по этому протоколу может писать данные любой коллектор напрямую в вм. Размер пачки - без разницы, какой - хоть по одному значению на один пакет. Будут немного выше накладные расходы, но при небольшом потоке метрик это неважно. Но я бы записывал данные из стороннего коллектора по graphite протоколу с поддержкой тэгов, т.к. он проще, чем remote write и он текстовый, т.е. его легче дебажить. По одному TCP коннекшну можно отправлять произвольное количество показаний. См. https://graphite.readthedocs.io/en/latest/feeding-carbon.html#the-plaintext-protocol и https://graphite.readthedocs.io/en/latest/tags.html .