Прежде чем мы углубимся в технические детали реализации, полезно сделать шаг назад и рассмотреть проблему на более высоком уровне.
А именно, есть ли более широкий контекст, в который вписывается весь этот бизнес по обнаружению аномалий? Например, предположим, что мы тратим на это часы, и это действительно работает, и что? Почему кого-то должно волновать?
Всем хороших вопросов!
На мой взгляд, более широкая картина здесь - это Платформа оперативной аналитики для общего журналирования, обработки ошибок и обнаружения аномалий, более известная под своим популярным названием CLEHADOIP ...
… Ладно, это не так.
Однако современная организация, занимающаяся разработкой программного обеспечения, абсолютно должна позаботиться о демократизации доступа к оперативным данным!
Это особенно верно, если вы имеете дело с современным технологическим стеком, который может легко охватывать несколько контейнеров, лямбда-функции, веб-серверы, балансировщики нагрузки, серверы баз данных, серверы приложений, механизмы оркестровки микросервисов и т. Д.
Кроме того, как может подтвердить любой, кто действительно пробовал сделать это в реальной жизни, получение, агрегирование и анализ этих объемных, разрозненных наборов данных - нелегкая задача. А превратить весь этот поток данных в реальную, действенную оперативную разведку еще сложнее!
Фактически, в таких высокопроизводительных компаниях, как Netflix, есть целые команды, посвященные этим усилиям. Например, посмотрите на это описание вакансии, которое недавно появилось в моей ленте LinkedIn:
Netflix Operational Insight Team - это группа, отвечающая за создание общей инфраструктуры для сбора, транспортировки, агрегирования, обработки и визуализации операционных показателей. Мы создаем мощные системы, позволяющие каждому в Netflix видеть состояние нашей среды как на макро-, так и на микроуровне.
Для меня это невероятно увлекательно. Одна из самых прогрессивных и дальновидных компаний на планете решила создать целую команду, призванную позволить каждому «видеть состояние нашей окружающей среды».
Почему?
Я думаю, ответ может быть тонким, но все же довольно очевидным. Они делают это, чтобы всем было легче!
И я действительно имею в виду всех. Поскольку после того, как ваши рабочие данные будут унифицированы и предоставлен свободный доступ для всех, кто в них нуждается, ваши SRE больше не будут зависеть от tail -f / var / log / messages на общем ресурсе NFS или сервер rsyslogd.
А ваши инженеры-программисты сразу видят написанный ими код и могут выявлять поведенческие аномалии на широком спектре серверов или микросервисов. Или ... кто знает ... для этого они могут обратиться к машинному обучению. :)
И ваши команды DevOps могут легко создавать конвейеры CI / CD, которые выполняют канареечные развертывания, наблюдая в реальном времени за метриками, возвращаемыми из развернутого программного обеспечения, чтобы соответствующим образом скорректировать процентное соотношение трафика.
Наконец, ваш ИТ-директор и генеральный директор теперь будут иметь возможность в режиме реального времени видеть общее состояние бизнеса: либо с технической точки зрения, либо с бизнес-метрик, либо с того и другого.
Короче говоря, централизация журналов и показателей - это невероятно мощная конструкция, которая может легко превратиться в настоящее конкурентное преимущество для вашей организации!
Для меня это общая картина, которая может выглядеть примерно так:
Фактически, если вы знакомы с Лямбда-архитектурой (не Amazon), вы узнаете это как нечто очень похожее - платформа, предложенная выше, обрабатывает большие объемы данных с использованием подходов как потоковой, так и пакетной обработки.
Теперь давайте разберемся с этим, чтобы мы все знали, что мы предлагаем здесь построить.
- Элементы внизу диаграммы (все, что находится под балансировщиком сетевой нагрузки и полем журнала CloudWatch) являются вашими источниками данных. Они будут варьироваться от нечастого обновления, например журналов системных событий, до перекачки огромных объемов данных, таких как packetbeats.
- Компоненты, выделенные красными штрихами, составляют конвейер обнаружения аномалий, который мы собираемся построить в рамках этой серии. В конвейер будут поступать потоки из нескольких источников. Пунктирная линия от Logstash до Kinesis - это возможность в будущем, я пока не знаю, имеет ли это смысл.
- Зеленые прямоугольники - это ваши долгосрочные архивы. Обратите внимание, что каждое сообщение отправляется в три разных места: a) конвейер потоковой передачи в реальном времени для немедленного обнаружения аномалии (минуты); б) ElasticSearch + Kibana для краткосрочного (дневного) анализа тренда; и c) объектное хранилище S3 для долгосрочного архивирования и аналитики (месяцы).
Подводя итог, можно сказать, что вся загадка и святой Грааль, который мы ищем, - это открытая многофункциональная платформа оперативной аналитики, которая раскрывает новые бизнес-идеи и технические идеи для всей организации!
Ладно, хватит болтовни. Переходим к Части 3, где мы на самом деле создаем эту штуку!
Бесстыдный плагин саморекламы: если вам интересно, как собрать другой кусок этой головоломки (синие черточки), который представляет собой полностью контейнерный стек ELK (ElasticSearch, Logstash, Kibana), работающий в Amazon Web Услуги, смотрите, пожалуйста, другую мою серию.
