Комментарии 3
Эм, если бы все было так просто. В мониторинге не в вакууме, у вас есть очень много факторов, которые влияют на анализ. А ещё ограниченный бюджет (тратить на систему мониторинга больше, чем стоимость системы не каждый заказчик готов).
Например (из реального опыта), есть веб приложение, на каком нибудь lamp, с bare metal и балансировщиком (между несколькими экземплярами), вынесенными бд и прочим. И замечаете, что приложение падает с 504 или с 500 каждое первое воскресение или понедельник месяца (причем в случайный промежуток времени, а ещё может и не упасть).
Пара бессонных ночей, куча анализов логов веб приложений и метрик сервера приводит к тому, что с приложением все в порядке (количество запросов стабильно), но все равно повышается ожидание от дисков (wa), которые по smart в идеальном состоянии. И это все происходит до тех пор, пока вы не замечаете процесс ребилда софтварного рейда (который в iotop не отображается), а также не находите systemd таймер (с речеком рейда), заботливо добавленный мейнтейнерами пакета. А чтобы вы не расслаблялись, они добавят запуск каждое первое воскресение, со случайным смешением в 24 часа.
По итогу оказывается, что проблему можно решить, руками разнеся речек рейдов, чтобы вероятность возникновения проблемы была низкой.
Ещё, какашек, может накидать производитель дисков и разработки (точнее эффективные менеджеры, которые хотят повысить эффективность каждого вложенного цента/рубля), где экспериментально можно узнать, что со снижением места, скорость чтения/записи падает причём только на некоторых моделях диска, что приводит к повышенному wait access, при низких обращениях к диску, когда cdn инстанс забивается под завязку неизменяемыми данными (ради экономии места).
Конкретно то, что вы описали в статье можно применить при хороших бюджетах на мониторинг, а также в типовых ситуациях (сканы ботов, ддосы на l7). Но корреляцию, без абсолютно полной информации о состоянии системы, вы увидеть не сможете. А с учётом того, что могут вносить новые показатели без вашего уведомления, только и остаётся фиксировать аномалии по базовым показателям и реагировать на них.
Спасибо за ваш комментарий, очень интересная информация!
Со всем этим страхом и пытаемся разобраться. Но полномочия действительно могут быть "всё", если логируется малая часть айсберга или мониторинг слабый. А в случае скрытых причин можем только сузить область поиска.
Вот вопрос, а насколько успешно гуглятся подобные неожиданные случаи? Может быть уже после выяснения причины. В отсутствие точных наблюдений остаётся либо гадать, либо ожидать того, что происходило у других.
И какие графики / диаграмки / развитие ситуации во времени или прочие объекты наблюдений истории, могли бы упростить вам задачу? Или просто больший охват логирования решил бы большую часть проблем?
Вот вопрос, а насколько успешно гуглятся подобные неожиданные случаи? Может быть уже после выяснения причины.
Не очень хорошо всё гуглится (на каких-то начальным стадиях поиск работал, но чем более специфичней проблема, тем меньше по ней репортов и решений), с теми же дисками первым ответом в гуле - обновить прошивку (что не особо помогло). Как потом выяснилось - проблема в SLC Cache (причем для дисков одной линейки, значения разные оказались...).
В отсутствие точных наблюдений остаётся либо гадать, либо ожидать того, что происходило у других.
Как первый бастион, в случае, если нет понимания ситуации - подойдет. Но, к сожалению, чаще встречаются треды, где жалуются ровно с той же проблемой, но на него нет ответа как несколько лет.
И какие графики / диаграмки / развитие ситуации во времени или прочие объекты наблюдений истории, могли бы упростить вам задачу?
Не совсем понятно что вы хотите / имеете в виду. Есть экспортеры метрик, по которым можно построить огромное количество графиков и диаграмм, но они не показатель проблемы или показатель, но не полный. Например, есть показатель wa - на сервере с SSD / NVME дисками, значение больше 3 - 5 может сигнализировать о проблеме, а может сигнализировать о том, что какой-то менеджер запустил выгрузку для рассылки. А на бэкапном сервере, wa 40 хотя и кажется запредельным, но может являться нормальной ситуацией при наличии HDD дисков.
Вобще, мониторинг делается таким образом (по моему опыту, возможно есть куда более лучшие варианты и буду открыт к их изучению :) ):
Есть проект, у проекта есть требования к архитектуре (бюджеты, показатели, уровни логгирования, мониторинга и прочее)
С заказчиком определяем, что нужно и за какие деньги (бэкапы, сбор метрик и прочее)
Формируем стенд (приобретаем ВМ / сервера) и все разворачиваем
Даем тестовые нагрузки (просто руками потыкать, нагрузочные тесты и прочее), некоторые не могут подготовить тесты и сразу в прод (с мотивацией, что если будет не хватать - расширятся)
Некоторое время наблюдаем (от пары недель, до месяца), корректируем пограничные значения и настройки (в моих же интересах сделать так, чтобы система работала без постоянного вмешательства).
Живем до первого срабатывания превышения, смотрим что не так, решаем проблему и TODO 5 по необходимости.
Много чего в таком действии со временем обрастает готовыми решениями (ротации логов, видоизмененные настройки в sysctl, забаненные подсети, и прочее). Да и большая часть мониторинга также уже обложенна проверенными временем решениями (например мониторинг дисков, система против ботов, парсинг логов и их анализ).
Но могу точно сказать, что встреченное количество разных проблем, однозначно облегчает их решение :)
Совпадение? Не думаю! Удивительные сходства нашего мышления и систем IT-мониторинга в поиске причин проблем (Часть 1)