короче к чему это я

если ты посмотришь внимательно как некоторый софт высчитывает "утилизацию диска", то ты сам ответишь на вопрос, как эту метрику получать

но ты почти наверняка тогда же и поймёшь насколько оно пальцем в небо

но ты почти наверняка тогда же и поймёшь насколько оно пальцем в небо

то что оно пальцем в небо это я уже понял проблема в том что это пальцем в небо помогало понимать что есть проблемы с дисками и нужно что-то делать диски сейчас головная боль и хочется ее решить что можете посоветовать в прометее кроме стандартного node_exporter

если ты посмотришь внимательно как некоторый софт высчитывает "утилизацию диска", то ты сам ответишь на вопрос, как эту метрику получать

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

он считает длины дисковых очередей, насколько я помню

iowait это не нагрузка

не помню как именно

года два назад разбирался, а щас уже забыл

курить меньше надо)

iowait это не нагрузка

кажется что iowait как раз случается после того как утилизация близка к 100% вроде как другая метрика вообще поправьте если не прав

iowait это просто ожидание io, оно может быть вызвано чем угодно, в частности может указывать на "высокую утилизацию", но это не всегда

какая утилизация-то?

утильная!

и высокая!

кажется что iowait как раз случается после того как утилизация близка к 100% вроде как другая метрика вообще поправьте если не прав

ты сравниваешь текущий kb_read с рандомным read, который тебе производитель диска написал, и получаешь "утилизацию"

ток она неправильная немношк

вообще она неправильная

в общем в прометее нашел что-то подобное irate(node_disk_io_time_ms{instance=~"$node"}[5m])/10

в общем в прометее нашел что-то подобное irate(node_disk_io_time_ms{instance=~"$node"}[5m])/10

это тоже пальцем в небо

это тоже пальцем в небо

как уже выяснили выше считать утилизейшн это пальцем в небо вообще

в общем в прометее нашел что-то подобное irate(node_disk_io_time_ms{instance=~"$node"}[5m])/10

Что как бы говорит о том, что в node_exporter все уже есть

абстрактный "утилизейшн" - да, конкретные метрики - нет

ну и не считай её. считай прирост

ну и не считай её. считай прирост

прирост чего

ну что там тебе критично. иопсы, очереди, объемы

https://stackoverflow.com/a/4528813 к слову как iostat считает

https://stackoverflow.com/a/4528813 к слову как iostat считает

вот спасибо

но насчет того что утилизейшн это пальцем в небо когда я ловил утилизейшн в 100% всегда был пиздец

речь была про предложенные выше "способы измерения"

просто в этой самой утилизации кроме 100% вообще нет ни одного значения имеющего смысл

да и эти 100% тоже не всегда плохо

для контеенера это даже ок, наверное

у нас на тачках для какой-то математики и анализа почти всегда 100% по цпу. так что алерт стоит на цпу<80%

при утилизации выше 70% обычно начинает нестабильно svctime себя вести

когда тема затихнет можно начать про CPU LA :)

LA к CPU никакого отношения не имеет

Брендан уже все написал про это http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

ага, но его все меряют и на него смотрят... неуловимо похож на disk usage, разве что не в процентах

когда тема затихнет можно начать про CPU LA :)

а ты хорош!

ага, но его все меряют и на него смотрят... неуловимо похож на disk usage, разве что не в процентах

А что такое дискюсадж?

Я чот пропустил?

буквально 10 строк выше

А ок

ну смысле холт-винтерс вообще хорошо себя показывает только если коэффициенты подобраны

Ну так это логично. Это же модель процесса по сути. Параметры автоматически подбирать можно.

Ну так это логично. Это же модель процесса по сути. Параметры автоматически подбирать можно.

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

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

мониторить надо сервисы, а не компоненты

компоненты тоже надо

реши что тебе нужно от дисков и тогда уже будет понятно как их мониторить

чтобы знать чо чинить

метрик мало не бывает А вот алертить лучше на недоступность сервисов, которые затрагивают функциональность, да

и алертить тоже по-разному

вылетел диск - менять надо

но для сервиса не критично, так что не надо никого будить

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

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

нужно

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

даже если это не аффектит сервис

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

ты менеджер небось?

подозреваю что на заводах по сборке это меряют и записывают :)

и алертят !

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

регулярно проверяемыми (что по сути тоже мониторинг)

ну у них это сервис - собрать машинки чтобы работали

машина ездит - зачем масло менять?

ты хочешь сказать что диски вообще мониторить не надо?

или что?

я на AWS мониторю ровно один параметр - %свободного места

я на AWS мониторю ровно один параметр - %свободного места

а зачем? нет чтобы только сервис мониторить!

а потом "ой, чота сервис тормозит, а чо делать - хз"

Василий же написал почти все полезные метрики чуть выше и в каких кейсах они нужны

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

это потому что ты на темной стороне силы :)

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

забикс?

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

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

почему не s3? (сервис)

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

ппкс зависит от того, где границы сервиса, который ты предоставляешь

Ага, я тоже самое и говорю, важно не какой компонент мониторить, а какой сервис от него требуется

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

конечно

про это куча статей написано

но вот давай например возьмём сервис "хранилище данных", которое реализуется ceph'ом

для примера

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

"хранилище данных" это тоже сервис для других комманд, соответственно его мониторингом заинтересована команда, его предоставляющая

конечно

и производительность (QoS) самого сервиса и состояние внутренностей, включая диски

Привет, кто нить может подсказать, как мониторить доступность NFS шары через Alertmanager?

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

я имею ввиду какое условие написать в alert, если на сервере стоит node_exporter, там из похожего нашел ток node_filesystem_device_error{fstype="nfs"} но это не совсем то что надо

Через медиану, берём данные по этой метрике за N предыдущих дней/недель (timeSlice), получаем N метрик, выкидываем 95 персентили (чтобы отсечь пики и падения) и строим медиану по этой группе метрик, получаем бейзлайн.

имХо как раз обрезание краев даёт высокий false positive, который является основной проблемой со всеми автоматическими anomaly детекторами. Но без отбрасывания пиков оно наоборот перестает "настоящие" аномалии выявлять))

Я знаю как это глазами определить, не о ручной работе речь

Фурье берешь и если есть мода на частоте соответствующей дню/неделе - значит сезонность

имХо как раз обрезание краев даёт высокий false positive, который является основной проблемой со всеми автоматическими anomaly детекторами. Но без отбрасывания пиков оно наоборот перестает "настоящие" аномалии выявлять))

люто удваиваю этого человека.

~slow poke mode off~

коллеги, а я правильно понимаю, что bosun умер?