Стремление понять, почему происходят те или иные события, заложено в человеческой природе. Мы постоянно ищем причинно-следственные связи, чтобы предсказывать будущее, принимать решения и улучшать свою жизнь. Но как это стремление проявляется в мире IT-мониторинга? 

Меня зовут Дмитрий Литвиненко, я Data Scientist в IT-компании ProofTech IT, и в этой статье мы погрузимся в увлекательный мир причинности, рассматривая параллели между тем, как наш мозг устанавливает связи между событиями, и тем, как современные инструменты помогают в этом специалистам по мониторингу.

В первой части мы обсудим основные концепции, интересные примеры из жизни и IT, а также, как именно люди и системы мониторинга:

  • упрощают этот сложный мир событий;

  • строят причинно-следственные связи;

  • становятся жертвами ложных корреляции.

Вторая часть статьи тут.

События и их абстрагирование

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

В жизни

В жизни мы часто наблюдаем последовательности событий и пытаемся найти между ними связи, но только когда это действительно важно. Да и связи мы ищем не со всем подряд, перебором, а только с тем, что имеет какое-то отношение к нашей проблеме. "Какое-то отношение к нашей проблеме" на самом деле определяется довольно сложно.

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

Мы вводим абстракции. Каждое слово - это, по сути, абстракция. Предложения из многих слов - тоже абстрактны, но всё же лучше сужают поле того, что могут означать. Не нужно запоминать каждый конкретный факт того, что предмет, будучи подвешенным в воздухе, затем отпущенным, упадёт. Достаточно сформулировать правило "Если предмет тяжёлый, висит в воздухе, ничто его не удерживает, и я его отпустил, то он упадёт" - и оно охватит бесчисленное множество случаев. Для простоты повествования пусть будет так: "предмет перестал поддерживаться" -> "предмет падает" -> "предмет упал".

Что это правило позволит нам делать?

  • Группировать.

Примеры групп: физика, перемещение в пространстве, закон тяготения, поведение предметов.

Всё это - теги, которые можно присвоить событиям, и по этим же тегам группировать, определяя факт "Какого-то отношения к нашей проблеме".

  • Прогнозировать.

"Предмет падает", значит скоро "предмет упадёт".

  • Искать первопричину.

"Предмет упал", значит "предмет падал".

  • Фиксировать аномалии.

"Предмет падал" -> ..., но всё ещё почему-то не упал - надо пойти проверить.

В IT-мониторинге

В IT-мониторинге всё тоже непросто. Уникальных событий крайне много, и строить причинно-следственные связи среди них - не только сложно, но ещё и не всегда полезно. Нужно группировать.

А тут что?

  • Группировка (умное слово - кластеризация, объединение объектов в кластеры).

Примеры групп: хост "hosty-1", запущен на сервере "my_serv", использует базу данных "db-17"

  • Прогнозирование.

На сервере "осталось мало памяти", значит вероятно, что скоро "сервер упадёт".

  • Поиск первопричин.

"Сервер упал", значит:

  • либо "оставалось мало памяти";

  • либо из-за кого-то был "вручную выключен сервер";

  • либо "были внесены изменения в код приложения";

  • либо была "необычно высокая плотность запросов".

  • Детекция аномалий.

Количество запросов к серверу "hosty-1" внезапно увеличилось в три раза без видимой на то причины, это может сигнализировать о DDOS-атаке или ошибке в конфигурации клиента, отправляющего запросы.

Зачем искать причинно-следственные связи?

Кажется, вопрос очевидный. Но ответ на него более обширный, чем можно ожидать.

В жизни

Для людей, говоря в общем,  - чтобы построить у себя в голове модель мира, которая бы позволила:

  • Прогнозировать.
    Прогнозирование помогает ощутить будущее как настоящее, принять решение, нравится ли нам это настоящее, и совершить действия по предотвращению нежелательного будущего.

Когда мы думаем о собеседовании, представляя, как не можем ответить на какие-то вопросы, мы испытываем дискомфорт, давая понять всему организму, что нужно что-то делать сейчас для корректирования этого вероятного будущего. (Или на самом деле вовсе не вероятного, а пессимистичного, накрученного страхами.)

  • Находить первопричины.
    Часто, напрямую скорректировать следствие невозможно - только повлияв на первопричину можно изменить следствия. Мы сужаем поле потенциальных первопричин только до событий, имеющих отношение к классу проблемы. В примере ниже - ПО, интернет, сотовая связь. Также мы начинаем поиск с недавних событий.

Событие того, что приложение поиска такси начало показывать непредвиденную ошибку и отказываться вызывать машину, заставляет инициировать процесс поиска первопричины. Может быть, само приложение глючит, и нужно его открыть-закрыть? Может, связь не ловит? А, кажется, вспоминаю, что часа 3 назад мне приходило сообщение от мобильного оператора о неуспешной оплате связи, которое я только мельком просмотрел и тут же отбросил, потому что был сконцентрирован на другом. Первопричина проблемы установлена и можно заняться её устранением.

  • Как бонус, замечать аномалии.
    Всё, что не укладывается в рабочую модель мира, составляет неизвестность, а потому - интересно, опасно и таит в себе полезный потенциал.

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

В IT-мониторинге

В IT-мониторинге ситуация аналогична. Есть сложный мир использования акторами масштабной системы из многих девайсов. Мы его упрощаем до схемы, графа или другого объекта (для больших систем главное, что не до набора связей в мозге работника), отражающего работу системы. Всё также, этот объект позволит:

  • Прогнозировать.
    Если в системе повторяется цепочка событий, мы можем рассчитать, сколько времени занимают переходы между ними, насколько они вероятны, и исходя из этого заключить при начале такой цепочки, что последует далее, и как скоро последует.

  • Находить первопричины.
    При наблюдении ошибки в модуле, если он состоит в иногда повторяющейся цепочке (иногда дереве) событий, можно обратить внимание на начало этой цепочки (или листья дерева). Если же повторяющихся цепочек нет, можно хотя бы воспользоваться атрибутами модуля: на каком сервере развёрнут, по какому хосту к нему обращаются и т.п. События с теми же атрибутами будут первыми для анализа.

  • Детектировать аномалии.
    Многие части IT-системы должны работать определённым образом, и изменения в их поведении нежелательны. Поэтому, если нам не удалось объяснить поведение системы за последние 10 минут нашей моделью, это может означать:

  1. Что-то пошло не так, и возможно, скоро мы узнаем об этом в событии со статусом WARNING, ERROR или CRITICAL

  2. Топология системы была изменена, и теперь корректная модель системы выглядит иначе

Корреляция и причинность

Мы часто замечаем, что некоторые события происходят одновременно или следуют одно за другим. Это заставляет нас задуматься: связаны ли эти события между собой? Здесь на сцену выходят два понятия — корреляция и причинность.

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

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

Так вот важно не путать корреляцию с причинностью!. Как в жизни, так и в IT-мониторинге. О том, как строить более правдивые причинно-следственные связи, пойдёт речь во второй части, а пока, разберёмся с самими понятиями.

В жизни

В жизни мы наблюдаем события, и если они в какой-то степени близки (их можно абстрактно сгруппировать), возникает два случая:

  1. События встретились рядом первый раз: в этом случае мы можем прибегнуть к существующей у нас в голове модели мира, и посмотреть, можно ли, используя имеющиеся у нас причинно-следственные связи, построить вероятный путь из одного события в другое.

  1. События встретились рядом уже второй-третий-десятый раз, и тот факт, что у нас получилось предсказать B, наконец попадёт в наше внимание, и мы начнём думать, почему же всё-таки A -> B

Летом увеличивается потребление мороженого и одновременно растет количество утоплений. Между этими событиями есть корреляция, но вы можете согласиться с тем, что поедание мороженого вряд ли повышает вероятность утопления. Или всё же повышает...? Возможно, каждое съеденное мороженое охлаждает организм настолько, что желание нырнуть в воду становится непреодолимым. А с растущим количеством съеденных пломбирчиков, у человека пропадает способность адекватно оценивать глубину и температуру воды, что, в свою очередь, приводит к необратимым последствиям.... Ну или общей причиной и того, и другого, является жаркая погода :)

В IT-мониторинге

В IT-мире ситуация аналогична.

  1. Можно посмотреть на карту поведения системы и установить косвенную причинность.

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

Мы можем заметить, что увеличение нагрузки на сервер совпадает с ростом времени отклика приложения. Возникает вопрос: вызывает ли нагрузка замедление приложения, или оба эти события связаны с чем-то третьим? Если мы ошибочно примем корреляцию за причинность, то можем предпринять неправильные действия. Например, начать оптимизировать код приложения, когда на самом деле проблема в сети.

Как различать корреляцию и причинность?

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

  • Способность прогнозировать
    Если знание об A позволяет уверенно предсказывать B, это плюс к причинности.

  • Эксперимент
    Если возможно напрямую вызывать событие A и наблюдать за возникновением события B, то это плюс к причинности.

  • Распределение во времени
    Если событие B происходит через подозрительно нормально распределённые промежутки времени после события A - это явное указание хотя бы на косвенную причинность: либо A -> B, либо C -> A и C -> B.

  • Анализ контекста
    Если у коррелирующих феноменов достаточно разный контекст, то это минус к прямой причинности. Однако, косвенная (транзитивная) причинность всё равно возможна, просто мы пока не поняли, как они связаны.

Ложные корреляции

Потребление голубого сыра коррелирует с числом запросов "средства от головной боли". r = 93,2%.

Число запросов в гугл о появлении НЛО коррелирует с объёмом керосина, используемого в Южной Корее. r = 91,7%.

Количество поисковых запросов по игре "call of duty" в гугл коррелирует с числом нападений пиратов в мире. r = 95.8%.

Очевидно, что между этими событиями нет причинно-следственной связи. Нет даже общей причины! Просто если данных много, среди них всегда найдутся невероятные совпадения - настолько невероятные, что два несвязанных временных ряда будут иметь крайне высокую корреляцию.

Этот эффект возникает при рассмотрении множества разных параметров в выборке. Чем меньше выборка и чем больше измеряемых параметров - тем больше удивительных "открытий" можно совершить! В науке с этим активно борются, и качество научных публикаций в том числе определяется осторожностью обращения со статистикой.

Как там говорят? “Есть три вида лжи: ложь, наглая ложь и статистика”. 

Что мы узнали?

Узнали основу нашей, на удивление эффективной, ориентации в мире событий! 

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

При решении проблемы с интернетом, стоит рассмотреть события с ярлыками: "электричество", "провайдер", "роутер" за последнее время.

  1. Важно группировать события по смыслу, чтобы упрощать мир и выводить абстракции.

Событие "предмет упал" вмещает в себя ну очень много всего.

  1.  Важно строить причинно-следственные связи между абстракциями, чтобы:

  • Прогнозировать этот мир: "Предмет упал" -> "бабах!";

  • Искать первопричину: "Бабах!" - возможно, какой-то "предмет упал"

  • Находить аномалии: “Сижу себе один дома, ... -> "дверь захлопнулась" - ой! страшно! что захлопнуло дверь?”.

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

Статья хоть и про базу, но всё же, может быть, вам вспомнились релевантные случаи из жизни, забавные ошибки или просто интересные инсайты?

А вот и вторая часть статьи!

Комментарии (3)


  1. qid00000000
    16.11.2024 08:55

    Эм, если бы все было так просто. В мониторинге не в вакууме, у вас есть очень много факторов, которые влияют на анализ. А ещё ограниченный бюджет (тратить на систему мониторинга больше, чем стоимость системы не каждый заказчик готов).

    Например (из реального опыта), есть веб приложение, на каком нибудь lamp, с bare metal и балансировщиком (между несколькими экземплярами), вынесенными бд и прочим. И замечаете, что приложение падает с 504 или с 500 каждое первое воскресение или понедельник месяца (причем в случайный промежуток времени, а ещё может и не упасть).

    Пара бессонных ночей, куча анализов логов веб приложений и метрик сервера приводит к тому, что с приложением все в порядке (количество запросов стабильно), но все равно повышается ожидание от дисков (wa), которые по smart в идеальном состоянии. И это все происходит до тех пор, пока вы не замечаете процесс ребилда софтварного рейда (который в iotop не отображается), а также не находите systemd таймер (с речеком рейда), заботливо добавленный мейнтейнерами пакета. А чтобы вы не расслаблялись, они добавят запуск каждое первое воскресение, со случайным смешением в 24 часа.

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

    Ещё, какашек, может накидать производитель дисков и разработки (точнее эффективные менеджеры, которые хотят повысить эффективность каждого вложенного цента/рубля), где экспериментально можно узнать, что со снижением места, скорость чтения/записи падает причём только на некоторых моделях диска, что приводит к повышенному wait access, при низких обращениях к диску, когда cdn инстанс забивается под завязку неизменяемыми данными (ради экономии места).

    Конкретно то, что вы описали в статье можно применить при хороших бюджетах на мониторинг, а также в типовых ситуациях (сканы ботов, ддосы на l7). Но корреляцию, без абсолютно полной информации о состоянии системы, вы увидеть не сможете. А с учётом того, что могут вносить новые показатели без вашего уведомления, только и остаётся фиксировать аномалии по базовым показателям и реагировать на них.


    1. ProoftechIT Автор
      16.11.2024 08:55

      Спасибо за ваш комментарий, очень интересная информация!

      Со всем этим страхом и пытаемся разобраться. Но полномочия действительно могут быть "всё", если логируется малая часть айсберга или мониторинг слабый. А в случае скрытых причин можем только сузить область поиска.

      Вот вопрос, а насколько успешно гуглятся подобные неожиданные случаи? Может быть уже после выяснения причины. В отсутствие точных наблюдений остаётся либо гадать, либо ожидать того, что происходило у других.

      И какие графики / диаграмки / развитие ситуации во времени или прочие объекты наблюдений истории, могли бы упростить вам задачу? Или просто больший охват логирования решил бы большую часть проблем?


      1. qid00000000
        16.11.2024 08:55

        Вот вопрос, а насколько успешно гуглятся подобные неожиданные случаи? Может быть уже после выяснения причины.

        Не очень хорошо всё гуглится (на каких-то начальным стадиях поиск работал, но чем более специфичней проблема, тем меньше по ней репортов и решений), с теми же дисками первым ответом в гуле - обновить прошивку (что не особо помогло). Как потом выяснилось - проблема в SLC Cache (причем для дисков одной линейки, значения разные оказались...).

        В отсутствие точных наблюдений остаётся либо гадать, либо ожидать того, что происходило у других.

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

        И какие графики / диаграмки / развитие ситуации во времени или прочие объекты наблюдений истории, могли бы упростить вам задачу?

        Не совсем понятно что вы хотите / имеете в виду. Есть экспортеры метрик, по которым можно построить огромное количество графиков и диаграмм, но они не показатель проблемы или показатель, но не полный. Например, есть показатель wa - на сервере с SSD / NVME дисками, значение больше 3 - 5 может сигнализировать о проблеме, а может сигнализировать о том, что какой-то менеджер запустил выгрузку для рассылки. А на бэкапном сервере, wa 40 хотя и кажется запредельным, но может являться нормальной ситуацией при наличии HDD дисков.

        Вобще, мониторинг делается таким образом (по моему опыту, возможно есть куда более лучшие варианты и буду открыт к их изучению :) ):

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

        2. С заказчиком определяем, что нужно и за какие деньги (бэкапы, сбор метрик и прочее)

        3. Формируем стенд (приобретаем ВМ / сервера) и все разворачиваем

        4. Даем тестовые нагрузки (просто руками потыкать, нагрузочные тесты и прочее), некоторые не могут подготовить тесты и сразу в прод (с мотивацией, что если будет не хватать - расширятся)

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

        6. Живем до первого срабатывания превышения, смотрим что не так, решаем проблему и TODO 5 по необходимости.

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

        Но могу точно сказать, что встреченное количество разных проблем, однозначно облегчает их решение :)