Это низкий чарн рейт можно кстати посмотреть на tsdb/status страницу она покажет кто виноват

churn rate считается относительно активных серий. Даже если churn rate 1% (new_series/active_series * 100) это уже много и не оптимально 🙂 Особенно, если 1% стабильный - значит что-то всё время генерирует уникальные серии.

для кубернетес кластера в 10к подов у нас обычно черн рейт держался в районе 30-50 но потом вырос до 130, пытаюсь понять в чем причина но не могу понять методику выявления проблемы (есть подозрение что массовый падеж контейнеров из за проблем с сетью нарожал этот черн рейт) но тупо не могу это вывести в виде метрики какойто

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

Коллеги, добрый день.
Есть несколько офисов, в них есть тонкие клиенты, которые коннектятся к главному серверу. С них собирается метрика по количеству попыток реконнектов за минуту (то есть и 1 и 3 и 16 можно кастануть в булево значение 1, которое означает, что не было связи с главным сервером, и для этого сервера тонкий клиент был в оффлайне).

Пром/Виктория раз в минуту забирает вот такое:

reconnects{client_id="036",office_id="18"} 1
reconnects{client_id="284",office_id="12"} 14
reconnects{client_id="285",office_id="12"} 11
reconnects{client_id="286",office_id="12"} 11
reconnects{client_id="287",office_id="12"} 3
reconnects{client_id="289",office_id="12"} 16

Подскажите, как можно подсчитать длительность метрики простоя, по ТК, по офису, в том числе за указанный период, а не общую сумму?

ребят, говорят у графаны есть возможность экспорта в CSV. у нас grafana 7.4.3 и этой опции нет. её убрали?

В inspect -> Data должна быть кнопочка

точно, благодарю

Всем привет.

Есть такой запрос у меня, он считает сколько процентов CPU используется от общего capacity

sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name!="",owner="st-k8s-prod-env-monitoring"}[5m]))/ sum(kube_node_status_capacity_cpu_cores{owner="st-k8s-prod-env-monitoring"})

тут все ок

Далее я хочу считать это относительно нод кластера. В этих запросах используются разные лейблы для получения node_names,  instance и node соответственно. Вот думаю поэтому и получаю ошибку, но не уверен.

sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name!="",owner="test-k8s-prod-env-monitoring"}[5m])) by (instance)/sum(kube_node_status_capacity_cpu_cores{owner="test-k8s-prod-env-monitoring"}) by (node)

count() выдает низкие значения, т.к. он показывает количество рядов в конкретный момент времени. Если ряды постоянно меняются (aka churn rate), то общее количество рядов за определенный период может быть намного выше, чем количество рядов в конкретный момент времени

Попробуйте вот такой хапрос для вм: share_gt_over_time(reconnects[$__range], 0) * (end()-start())

Он должен вернуть время простоя в секундах за выбранный интервал $__range . См. подробности про использованные функции на https://victoriametrics.github.io/MetricsQL.html

Если нужна агрегация по лейблам, то заверните запрос в sum(...) by (needed_label)

есть куб ингрес, который деплоится из дефолтного чарта (последний или предпоследний), включен сервис монитор и пром оператор скрапит с него метрики, метрики скрапятся, НО по некоторым ингресам (kind: ingress) не отображаются nginx_ingress_controller_check_success вообще

кто-нибудь сталкивался?

т.е. вот абсолютно идентичные ингресы

один условно /api/v1, второй /api/v2, в названии тот же v2

но по первому всё скрапится, по второму нет

не знаю даже куда копнуть

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