А как вообще без количества ядер сырой LA воспринимать?

Дрочить на него можно

Так он и снимает сырую, но в шаблонах по-умолчанию она пересчитана уже в полезную величину вместо бесполезной

Вот я не согласен во первых с таким умолчанием, во вторых с таким подходом

Так он и снимает сырую, но в шаблонах по-умолчанию она пересчитана уже в полезную величину вместо бесполезной

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

Вот я не согласен во первых с таким умолчанием, во вторых с таким подходом

Некоторые и в жопу долбятся

А кто смотрит LA не опираясь на знания количества ядер?

Некоторые и в жопу долбятся

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

Ваше право

А кто смотрит LA не опираясь на знания количества ядер?

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

Если у меня 8 ядер и однопоточное приложение, которое грузит ядро, скажем, на 5, то la pecpu будет ~0.6. Это, мне кажется, не очень отражает картину происходящего.

ага

Начнем с того, что percpu должно быть именно per CPU, то есть это должно быть столько величин сколько цпу в системе, но Линукс такую статистику не предоставляет

и поэтому у нас и так и сяк сейчас хранится (я с жаббикса мигрирую)

Общепринятого?

команда uptime 24 года так показывает LA.

(а точнее, немного больше)

и это учитывая какой там фронтенд прям "очень" удобно

Во вторых в общем метрика не самая полезная в целом

Особенно с учётом того как она рассчитывается

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

Да, она для одноядерных систем еще более-менее, а для многоядерных сложно найти вменяемое объяснение.

(для тех кто думает что это список процессов, я предлагаю пройти в loadavg.c и посмотреть как оно сейчас считается, а потом как бонус - как оно считается для nohz)

потому что в ином случае можно ее собственно достаточно точно посчитать из этих данных

Да, она для одноядерных систем еще более-менее, а для многоядерных сложно найти вменяемое объяснение.

Там даже для одноядерных систем она очень интересно рассчитывается

Начнем с того, что percpu должно быть именно per CPU, то есть это должно быть столько величин сколько цпу в системе, но Линукс такую статистику не предоставляет

На этом ядре 4 процесса ожидают исполнения а на это 20.

На этом ядре 4 процесса ожидают исполнения а на это 20.

Для тех кто наивно считает что там процессы я уже предложил пройти в код.

LA - это вообще хер пойми что, но на него почему-то принято теребонькать кончик

Какой-то натуральный карго-культ из времён однопроцессорных пней, FreeBSD 2.2.7, пятого редхата и сайтов citforum и "всероссийский клуб вебмастеров".

Тогда девять из десяти этих "вебмастеров" фапали на LA в топе и "регулировали" количество чайлдов апача. Уже тогда не понимая смысла.

По идее, это просто индикатор того, что стоит посмотреть остальные счетчики и проверить, все ли нормально.

а не проще алертить по остальным счетчикам сразу? и не заставлять себя делать лишнее движение

Че вообще шум

Собирайте и то и то

Не?

скучно людям за утренним кофе

а не проще алертить по остальным счетчикам сразу? и не заставлять себя делать лишнее движение

просто алертилка не резиновая. а тут одна метрика LA показывает погоду, и в общем то обращает внимание на возросшую нагрузку (шеф, что-то пошло не так), чем свою функцию выполняет.

Можно алертить в разное

Одно будет будить тебя в холодном поту, другое можно смотреть за утренним кофе

ну это да. безусловно. однако вот есть 4к метрик с узла и предложение алертить по остальным счетчикам подразумевает что.

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

+1

даешь богу метрик алерты на 100 страниц кода учитывающие вообще все :)

ну, я бы предпочел алертить по отдельным метрикам, чем по LA

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

а подход собирать но не отрисовывать не кажется слегка излишним?

а подход собирать но не отрисовывать не кажется слегка излишним?

нет. это экономия ресурсов. в базе они всегда есть но не каждый день все разрезы во всем метрикам нужно смотреть. прикинь 4k графиков посмотреть за кофе?

т.е. если брать мониторинг as a service как в Владимира - то норм. Просто периодически строить статы и говорить тому кто льет - вот смотри ты нам нагенерил 20Т данных но никогда их не читал - подумай над этим

т.е. если брать мониторинг as a service как в Владимира - то норм. Просто периодически строить статы и говорить тому кто льет - вот смотри ты нам нагенерил 20Т данных но никогда их не читал - подумай над этим

Если б 20... Ах, если б всего лишь 20

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

Если б 20... Ах, если б всего лишь 20

ну мне и такие цифры не дадут :) потому как сейчас это льется в хранилку за ахулион денег - просто потому что... не спрашивайте :)

а про метрики - тут есть два подхода

я так то в теории за то чтобы и 10к метрик в секунду (а лучше на каждый тик процессора) собирать хранить и в системе поиска аномалий прогонять с ИИ. если вот завтра будут квантовые компы и это будет бесплатно для ресурсов хоста

fuckup-driven и попытка спрогнозировать чо полезно

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

а подход собирать но не отрисовывать не кажется слегка излишним?

у @Civiloid другие объемы, масштабы, стэк и подход, соответственно. нет смысла сравнивать сотэн сервантов с прометеем у меня и тыщи серверов и виртуалок с кучей кастомных метрик.

во втором - берем и пишем все, а там авось пригодится

в первом случаи очевидно факапы дебажить сложнее будет

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

и заметить сложнее

а во втором дикий оверхед на хранилку

притом дикий это реально имеем 200ТБ данных из которых по кругу читаем гигабайты

одного и того же набора метрик

тут вопрос что важнее бизнесу, оверхед на данные или скорость разбора факапов

ну да

дальше оно идет по пути факдривен + скиллапанья человека по продукту

ага, и где то посередине суммы за систему мониторинга и за время на разбор встречаются

ну, я просто думаю что час простоя букинга стоит дороже 200ТБ данных

ну так букинг думаю написан не так чтобы там даже если что то стрельнуло это аффектило весь букинг :)

никогда не знаешь что стрельнет

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

ERROR: S client not available

ну, нам никто не скажет, как там что устроено

проблема в том что метрики дают неточную картину даже если их очень много - из разряда вот там пошли очереди начался затуп и в итоге это заафектило вот это и то

проблема в том что метрики дают неточную картину даже если их очень много - из разряда вот там пошли очереди начался затуп и в итоге это заафектило вот это и то

вам помогут нейросети и RCA.

лет через 10 может быть

чтобы такое получить от мониторинга

а дальше смотрят в профилировщики критичных систем (или сначала смотрят) и метрики в системе мониторинга это + к информативности а не панацея

угу

пока этого нет.

ну вот я доклад одноклассников смотрел - они запилили поиск аномалий поучили его месяца 3 и говорят что покрыли им достаточно хорошо их системы

вопрос сколько это стоит

я подобную систему буду наверное ближе к осени-зиме пилить

сказали 2.5 человека за 3 месяца запилили

до продакта

призвать бы их в церковь :)

а можно ссылку?

мне больше интересно сколько железо нейросетка скушала

сейчас покопаюсь в истории

по моему они не озвучивали... и это не нейросетка

сервак сидящий на потоке метрик и сравнивающий данные со смещением за 1 день за 1 неделю 1 месяц (с агреггрегацией ессна)

https://www.youtube.com/watch?v=liQVI5JK11Y

ну и как бы да... это бизнес метрики... их на порядки меньше чем системных

для бизнес много чего есть

эластик новый

prophet фейсбуковский

сервак сидящий на потоке метрик и сравнивающий данные со смещением за 1 день за 1 неделю 1 месяц (с агреггрегацией ессна)

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

думаю это тренды

RCA я в мониторинге не видел... оно хоть где то есть?

tivoli просьба не упоминать :) его нам продать не смогли

будет. лет через 10.

в tivoli тебе сначала нужно этот RCA наполовину самому написать и основное там - что первое случилось по времени.

т.е. примерно когда и квантовые компы :)

ну мы им выгрузили данные и они через пару месяцев сказали что вода мокрая а солнышко яркое...