Каковы общие варианты показателей сегментирования для разных компонентов куберенте?

1) В кубернетах многие компоненты (то есть узлы) имеют метаданные, которые вы хотите просматривать по группам. Примеры:

  • контролировать использование ЦП
  • отслеживать использование ЦП на всех машинах с графическими процессорами
  • контролировать использование памяти
  • отслеживать использование памяти на всех машинах (кубеле), которые помечены определенной зоной (например, "ASIA-EAST-1")

И т.д.

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

Одно решение: множество мастеров Прометея

Пока что я придумал одно решение: отдельный мастер Prometheus для разных логических групп узлов. Это позволит администратору создавать мастера, которые собирают метрики по произвольной метке, т. Е.

  • кластер запросов для всех узлов с меткой = SSD = 16 ГБ,
  • создать CSV из этого списка,
  • использовать его как конечные точки для мастера Прометея,
  • использовать это как конкретный источник данных ".

2) Есть ли более элегантные решения этой проблемы?

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

3) Еще несколько безумных идей ... просто для того, чтобы способствовать более широкому разговору о том, как хосты сегментировать метрики в кубернетах ...

  • Может быть, графана достаточно умен, чтобы как-то добавлять свои группы?
  • Или может быть расширена графана для выполнения опроса / накопления основного сервера Prometheus?

person jayunit100    schedule 20.03.2017    source источник
comment
Я действительно не понимаю проблемы, но несколько машин Prometheus не звучат как хороший масштабируемый ответ. вы говорите «поскольку метрики не генерируются вместе с этими метаданными» - и я не уверен, почему это так. Мы используем Telegraf (внутри докера) для вывода наших метрик. он излучает все, что мы говорим, поэтому я думаю, вы могли бы сделать это с помощью кубелец. Однако следует иметь в виду, что некоторые метрики не имеют смысла в контейнере - например, использование процессора, поскольку это метрика уровня хоста, а не метрика уровня контейнера.   -  person FuzzyAmi    schedule 21.03.2017
comment
Это простая проблема - группировать запросы по атрибутам узлов. Один из вариантов - экспортировать все метки узлов и загрязнения с каждой метрикой уровня узла, но это может быть связано с большими затратами данных. Другой вариант - сделать так, чтобы серверы считывали данные с разных хостов - это связано с более высокими затратами на сложность.   -  person jayunit100    schedule 21.03.2017
comment
Благодарность! Я понимаю, о чем вы говорите. Но действительно ли это проблема? действительно ли существует так много метрик на уровне узлов? Я считаю, что может быть много метрик на уровне хоста (общих для всех узлов на этом хосте), но по большей части метрики на уровне узлов берутся исключительно из приложения, которое вы запускаете - они, вероятно, ограничены по количеству (по крайней мере, по моему опыту).   -  person FuzzyAmi    schedule 21.03.2017
comment
Метрики уровня хоста - это действительно то, о чем я говорю. CPU, используемый для определенных аппаратных зон   -  person jayunit100    schedule 21.03.2017
comment
Prometheus может выполнять «соединения» в запросах PromQL, чтобы вы могли экспортировать метки, порчи и аннотации узлов в отдельные временные ряды / с отдельными экспортами и присоединяться к времени запроса, чтобы ввести измерение, по которому вы хотите сгруппировать. Это то, что мы делаем для показателей модуля - см. weave.works/.   -  person tom.wilkie    schedule 22.03.2017


Ответы (1)


Как правило, у вас должен быть один Prometheus на каждый центр обработки данных, чтобы держать все в одном домене сбоя. Вы можете разделить это в будущем, если возникнут проблемы с загрузкой, но это маловероятно для статистики экспортера узлов.

https://www.robustperception.io/scaling-and-federating-prometheus/ описывает общий подход к масштабированию.

https://www.robustperception.io/how-to-have-labels-for-machine-roles/ описывает, как агрегировать на основе таких вещей, как наличие графического процессора.

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

person brian-brazil    schedule 22.03.2017