dstat был хорош (RIP), но sar есть буквально везде

Видимо у старой школы. Но у них и pcp тоже ещё жив

Sar хорош для оффлайн диагностики, когда метрики надо хранить на той же ноде где они собираются

Привет всем.
Никогда не трогал прометеус. Вчера поставил его вместе с танос-кластером. Крутится как деплоймент в кубере. Все что касается таноса тупо рядом сайдкарами (танос нужнен тупо для S3 стораджа).
Подскажите пожалуйста следующий шаг, чтоб настроить мониторинг кубера с нормальным дашбородом в графане.
Чот я запутался в репозиториях: node exporter, kube-state metrics, сAdvisor, prometheus-operator, kube-prometheus и еще куча всего.

возьми kube-prometheus

См.  https://prometheus.io/docs/prometheus/latest/querying/api/#tsdb-stats . Пром с викторией поддерживают эту страничку

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

Если рейд на hdd дисках, то для них задержки чтения/записи в пределах 10-20мс - норм, т.к. им нужно физисески переместить головки для чтения данных с нужной дорожки на диске. Это может занять до 10-20мс.

спасибо

Я прошу прощения за глупый вопрос:
У меня есть метрика container_ooms, в которой есть label pod c именем контейнера экспортера, я хочу из метрики kube_pod_info по имени пода получить ноду, как сделать такой join?

sum(containers_ooms * on(pod) group_left(node) kube_pod_info{}) by(node,exported_pod)

Ругается:
Error executing query: found duplicate series for the match group {pod="monitoring-kube-state-metrics-558bccc948-wq4wq"} on the right hand-side of the operation:

Но в метрике containers_ooms в label pod нет такого значения monitoring-kube-state-metrics-558bccc948-wq4wq, там только названия контейнеров экспортера событий oom

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

Можно еще посмотреть запросы, используемые в grafana-официальных дашбордах для вм / прома

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

уже, хотелось бы какой-то алерт сразу с именами метрик ну и вообще за тенденцией роста конкретной сетрики наблюдать это пока только апи дает

Ряд будет один и тот же, но потребление ресурсов на вм может возрасти, т.к. вырастет размер кэша для поиска идентфикатора ряда по имени метрики с лейблами в виде, полученном от мсточника метрик. Также можеь неправильно считаться количество активных рядов. Поэтому лучше отдавать в вм лейблы в одном и том же порядке

спасибо. И тогда сопуствующий вопрос - если есть map[string]string в коде с лейблами, как их быстро и тп получить в отсортированном по ключе виде ?

ну то есть тупой вариант - получить ключи, отсортировать как строки, и получить из мапы значения по этим ключам

Одноуровневый простой  даунсемплинг в вм  можно эмулировать с помощью дедупликации - см. https://victoriametrics.github.io/#downsampling .
Фильтровать ненужные метрики можно как на уровне прома / vmagent'a, так и на уровне вм с помощью релебелинга. См. https://victoriametrics.github.io/#relabeling

Этот вариант - самый лучший (обычно самые простые варианты являются саммыми лучшими с точки зрения дальнейшей поддержки кода). Особенно если его завернуть в отдельную функцию и везде использовать ее вместо копипаств пяти строчек кода для сортировки лейблов.