Pull to refresh

Comments 6

Если я правильно понял, то таким образом можно распознать взаимосвязь между метриками, если задержка до реакции в среднем не больше 5 минут. А что делать со связями с большим лагом? Типа, начал сильно перегреваться сервер, и через сутки полетел диск.

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

Главное чтобы потом не получилось как в том анекдоте: "без ног — не слышит".

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


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

А как правильно выбрать временные ряды? Как правило, в типичном небольшом кластере кубера их уже тысячи.

в принципе, в фоновом режиме микросервис способен все ряды обсчитывать — коэффициенты корреляции мало меняются и для каждой пары КЕ достаточно его пересчитывать раз в день, а то и реже, чтобы обновлять матрицу корреляций. мы сортируем ряды по частоте изменения значений и берется верхняя сотня (как наиболее интересные) для отработки алгоритмов. кстати, из 3200 КЕ на одной из инсталяций за полгода только 25% изменили значения более 2 раз — поэтому полная корреляционная матрица почти вся «зелёная».
Only those users with full accounts are able to leave comments. Log in, please.

Articles