ты же можешь посмотреть метрики, который экспортер возвращает, не?

в браузере прям

зачем, если лучше посмотреть прямо в прометее

там на треш и угар

как билд, так новая метрика

весело будет

говорюж докер зло....

как билд, так новая метрика

Метрика та же, тэги другие

говорюж докер зло....

Не ной, а то и тут в ро улетишь

и на уровне чего мне тогда это править?

чтобы в графане была 1 линия красивая

и на уровне чего мне тогда это править?

Этна уровне запроса

это про графану?

{name=~".+"}[$interval])) by (name) * чтот тип такого?

Ребят а есть ли готовые репозитори для prometheus и exporters которые официальные ?

для экспртёров нет

нету

для рпм дистров есть https://packagecloud.io/prometheus-rpm/release

для самого прометея есть репы

Добрый день. Подскажите, пожалуйста, кто чем может: зачем в алертменеджере разделены cluster.listen-address и cluster.advertise-address?

для рпм дистров есть https://packagecloud.io/prometheus-rpm/release

в федора он в основном наапример есть

это может у них позиция какая то чтобы exporter использовали в докерах ?

там и экспортеры есть

Добрый день. Подскажите, пожалуйста, кто чем может: зачем в алертменеджере разделены cluster.listen-address и cluster.advertise-address?

для ната и кластера

для ната и кластера

А кто будет подключаться через нат, если не кластер?

Аа, понял

Спасибо

как билд, так новая метрика

Дропай лейлб с ид или возьми https://gitlab.com/SirEdvin/docker-prometheus-exporter

а его дропать надо на уровне чего, твой экспортёр посмотрю спасибо

На уровне прома, через релейбелинг

А мой еще может в фильтр и статус контейнера)

а cadvisor не может?

ну ладно, фильтра там нет

В статусы точно не может. Ну, раньше не мог.

В духе, конейнер запущен или нет

ну у меня куберовский цадвизор и он может

кубер у нас старый уже, 1.8

кубер у нас старый уже, 1.8

Все еще поддерживается же

Какой старый

По хипстамеркам софт вышежший полгода назад уже устарел

@Yuri7L будет жить. Поприветствуем!

Терминатор, настало твоё время

Господа, у меня есть куча серваков с разным количеством ядер. Я же правильно понимаю, что лучше как-то нормализовать значения load average по их количеству для каждого?

А что такое load average?

Господа, у меня есть куча серваков с разным количеством ядер. Я же правильно понимаю, что лучше как-то нормализовать значения load average по их количеству для каждого?

В целом да среднюю температуру по больнице делить на количество ядер, получится тоже средняя по больнице но возможно чуть информативнее

А что такое load average?

насколько я знаю - количество потоков, ожидающих выполнения

https://m.habr.com/company/mailru/blog/335326/

насколько я знаю - количество потоков, ожидающих выполнения

Вообще нет

Ну то есть да, но нет

В целом да среднюю температуру по больнице делить на количество ядер, получится тоже средняя по больнице но возможно чуть информативнее

Есть же метрика про кол-во ядер? Можно одну на другую поделить

Есть же метрика про кол-во ядер? Можно одну на другую поделить

Можно, да

ERROR: S client not available

Ну то есть да, но нет

Эээ

а можно подробнее

LA очень спорная метрика. И очень непоказательная. Лучше замеряйте разные виды utilization

насколько я знаю - количество потоков, ожидающих выполнения

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

И сети )

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

Это я знаю, что комплексная, но в конечном счете

В конечном счёте она показывает значения какие-то

Можно на кофейной гуще гадать

Или на картах таро

С вероятностью больше 50% если LA/количество ядер больше 1 - повод посмотреть чем там занят сервер, дальше уже другие метрики

А ещё можно метрики по кпу и диску смотреть сразу

Утилизация скажет тебе о том же, но точнее

Но в целом ответ на твой вопрос - да, нормализуй ЛА по количеству потоков процессора

С вероятностью больше 50% если LA/количество ядер больше 1 - повод посмотреть чем там занят сервер, дальше уже другие метрики

Главное не делать пейджинг по этому

спасибо за советы

А задача то какая?

Просто так, посмотреть на "нормализованный" LA?)

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

И распределять нагрузку пропорционально этому.

Если там несколько разных сервисов крутится, то нужно выделить группы одинаковых серваков и расселить сервисы по разным группам.

LA - всего лишь индикатор что что-то идёт не так. Для этого можно его и не нормализовать.

Как вариант для мониторинга - стандартное правило про три сигма для детекции аномалий. Но лучше сочетать с правилами по времени ответа сервисов.

Ты ведь не пойдешь в воскресенье чинить сервак с 90 LA если сервис продолжает нормально отвечать?

Ты ведь не пойдешь в воскресенье чинить сервак с 90 LA если сервис продолжает нормально отвечать?

Вообще, пойду

Как вариант для мониторинга - стандартное правило про три сигма для детекции аномалий. Но лучше сочетать с правилами по времени ответа сервисов.

Во, а это интересно, спасибо