От терабайт до понимания: реальная архитектура общенациональности ИИ

Рассмотрим поддержание и разработку платформы электронной коммерции, которая каждую минуту обрабатывает миллионы транзакций, генерируя большие объемы данных телеметрии, включая метрики, журналы и следы по нескольким микросервисам. Когда возникают критические инциденты, инженеры по вызову сталкиваются с сложной задачей просеивания океана данных, чтобы раскрыть соответствующие сигналы и идеи. Это эквивалентно поиску иглы в стоге сена.

Это делает наблюдение источником разочарования, а не понимания. Чтобы облегчить эту серьезную болезнь, я начал исследовать решение для использования протокола контекста модели (MCP) для добавления контекста и извлечения выводов из журналов и распределенных следов. В этой статье я намечу свой опыт создания платформы наблюдаемости с AI, объясню системную архитектуру и поделюсь действенными идеями, изученными на этом пути.

Почему наблюдение сложна?

В современных программных системах наблюдаемость не является роскошью; Это основная необходимость. Способность измерить и понимать поведение системы является основополагающим для надежности, производительности и доверия пользователей. Как говорится, «Что вы не можете измерить, вы не можете улучшить».

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

• Десятки терабайт бревен в день
• Десятки миллионов точек данных метрических данных и преагрегатов
• Миллионы распределенных следов
• Тысячи идентификаторов корреляции, генерируемые каждую минуту

Задача — не только объем данных, но и фрагментация данных. Согласно отчету о прогнозе наблюдаемости New Relic на 2023 год, 50% организаций сообщают о данных телеметрии, при этом только 33% достигают единого представления между метриками, журналами и следами.

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

Из -за этой сложности я начал задаваться вопросом: как ИИ может помочь нам получить фрагментированные данные и предложить всеобъемлющие, полезные знания? В частности, можем ли мы сделать телеметрические данные, по сути, более значимыми и доступными как для людей, так и для машин, используя структурированный протокол, такой как MCP? Фонд этого проекта был сформирован этим центральным вопросом.

Понимание MCP: перспектива конвейера данных

Anpropic определяет MCP как открытый стандарт, который позволяет разработчикам создавать безопасное двустороннее соединение между источниками данных и инструментами искусственного интеллекта. Этот структурированный конвейер данных включает в себя:

• Контекстуальный ETL для AI: Стандартизация извлечения контекста из нескольких источников данных.
• Структурированный интерфейс запроса: Позволяет AI -запросам получить доступ к уровням данных, которые являются прозрачными и легко понятными.
• Семантическое обогащение данных: Встраивает значимый контекст непосредственно в телеметрические сигналы.

Это может отключить наблюдаемость платформы от реактивного решения проблем и к упреждающему пониманию.

Архитектура системы и поток данных

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

На первом уровне мы разрабатываем контекстные данные телеметрии, внедряя стандартизированные метаданные в телеметрические сигналы, такие как распределенные следы, журналы и метрики. Затем во втором уровне обогащенные данные подаются на сервер MCP для индекса, добавить структуру и предоставлять клиентский доступ к обогащенным контекстам данных с использованием API. Наконец, механизм анализа AI использует структурированные и обогащенные данные телеметрии для обнаружения аномалий, корреляции и анализа корневых причин для устранения проблем применения.

Этот слоистый дизайн гарантирует, что ИИ и инженерные группы получают контекстные, действующие, действенные идеи от данных телеметрии.

Внедрение глубокого погружения: трехслойная система

Давайте рассмотрим фактическую реализацию нашей платформы наблюдаемости с MCP, сосредоточившись на потоках данных и преобразовании на каждом этапе.

Уровень 1: Обогащенное контекст генерация данных

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

def process_checkout (user_id, cart_items, платеж_метод): «» Имитируйте процесс оформления заказа с контекстом, обогащенной телеметрией ». # Генерировать идентификатор корреляции order_id = f ”order- {uuid.uuid4 (). hex (: 8)}» request_id = f ”req- {uuid.uuid4 (). hex (: 8)}» # Инициализировать контекстный словарь, который будет применен контекст = { «User_id»: user_id, «Order_id»: order_id, «Request_id»: request_id, «CART_ITEM_COUNT»: LEN (CART_ITEMS), «Платеж_метод»: платеж_метод, «Service_Name»: «Проверка», «Service_version»: «v1.0.0» } # Запустить Otel Trace с тем же контекстом с tracer.start_as_current_span ( «Process_checkout», attributes = {k: str (v) для k, v в context.items ()} ) как Checkout_span: # Журналирование с использованием того же контекста logger.info (f ”Partlection Checkout Process», Extra = {«контекст»: json.dumps (context)}) # Распространение контекста с tracer.start_as_current_span («process_payment»): # Процесс платежной логики… logger.info («обработка платежа», Extra = {«контекст»: json.dumps (контекст)})

Код 1. Обогащение контекста для журналов и трассов

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

Уровень 2: Доступ к данным через сервер MCP

Затем я создал сервер MCP, который превращает необработанную телеметрию в запрос API. Основные операции данных здесь включают следующее:

1. Индексация: Создание эффективных поисков по контекстуальным областям
2. Фильтрация: Выбор соответствующих подмножества телеметрии
3. Агрегация: Вычисление статистических мер во временных окнах

@app.post («/mcp/logs», response_model = list (log)) def Query_logs (Query: logquery): «” »Журналы запросов с конкретными фильтрами» »» Результаты = log_db.copy () # Применить контекстные фильтры Если Query.request_id: Результаты = (журнал для журнала внедрения результатов, если log («контекст»). get («request_id») == Query.request_id) Если Query.user_id: Результаты = (журнал для журнала внедрения результатов, если log («контекст»). get («user_id») == Query.user_id) # Применить фильтры на основе времени Если Query.time_range: start_time = datetime.fromisoformat (Query.time_range («start»))) end_time = datetime.fromisoformat (Query.time_range («end»))) Результаты = (журнал для результатов журнала if start_time <= datetime.fromisoformat (log («timestamp»)) <= end_time) # Сортировка к временная метка Результаты = отсортированы (результаты, key = lambda x: x («timeStamp»), reverse = true) Возврат результаты (: Query.limit), если запрос.

Код 2. Преобразование данных с использованием сервера MCP

Этот слой превращает нашу телеметрию из неструктурированного озера данных в структурированный, оптимизированный запрос интерфейс, который система ИИ может эффективно ориентироваться.

Слой 3: Двигатель анализа, управляемый ИИ, управляемый

Последний уровень — это компонент ИИ, который потребляет данные через интерфейс MCP, выполняя:

1. Многомерный анализ: Соотношение сигналов между журналами, метриками и следами.
2. Обнаружение аномалии: Определение статистических отклонений от нормальных закономерностей.
3. Определение основной причины: Использование контекстуальных подсказок для изоляции вероятных источников проблем.

def analyze_incident (self, request_id = none, user_id = none, timeframe_minutes = 30): «” »Проанализируйте данные телеметрии для определения основной причины и рекомендаций». # Определить окно времени анализа end_time = datetime.now () start_time = end_time — timedelta (минуты = timeframe_minutes) time_range = {«start»: start_time.isoformat (), «end»: end_time.isoformat ()} # Извлекать соответствующую телеметрию на основе контекста logs = self.fetch_logs (request_id = request_id, user_id = user_id, time_range = time_range) # Указанные услуги упомянуты в журналы для Целевой метрический анализ Services = set (log.get («service», «Неизвестно») для журналов журнала) # Получите метрики для Эти услуги metrics_by_service = {} Для обслуживания в услугах: Для metric_name in («Задержка», «error_rate», «Пропускная пропускная способность»): metric_data = self.fetch_metrics (служба, metric_name, time_range) # Рассчитайте статистические свойства значения = (точка («значение») для точки в metric_data («data_points»))))) metrics_by_service (f ”{service}. {metric_name}») = { «Среднее»: Statistics.Mean (значения), если значения еще 0, «Медиана»: статистика.median (значения), если значения еще 0, «Stdev»: statistics.stdev (значения), если Len (значения)> 1 else 0, «Мин»: мин (значения), если значения еще 0, «Макс»: Макс (значения), если значения еще 0 } # Определите аномалии с использованием z-score аномалии = () Для metric_name, статистика в metrics_by_service.items (): Если статистика («stdev»)> 0: # Избегайте деления на ноль z_score = (stats («max») — stats («среднее»)) / stats («stdev») Если Z_SCORE> 2: # более 2 стандартных отклонений anomalies.append ({ «Метрика»: metric_name, «Z_SCORE»: Z_SCORE, «Серьезность»: «Высокий», если Z_SCORE> 3 еще «Средний» }) возвращаться { «Сводка»: AI_Summary, «Аномалии»: аномалии, «Empact_services»: список (службы), «Рекомендация»: AI_Recommendation }

Код 3. Анализ инцидентов, метод обнаружения аномалии и вывода

Влияние наблюдаемой наблюдаемости MCP

Интеграция MCP с платформами наблюдения может улучшить управление и понимание сложных данных телеметрии. Потенциальные преимущества включают:

• Более быстрое обнаружение аномалий, что приводит к сокращению минимального времени для обнаружения (MTTD) и минимальному времени для разрешения (MTTR).
• У проще идентификация основных причин для проблем.
• Меньше шума и меньше несуществующих оповещений, тем самым снижая усталость оповещения и повышая производительность разработчиков.
• Меньшее количество перерывов и контекстов во время разрешения инцидентов, что приводит к повышению эффективности эксплуатации для инженерной группы.

Действующие идеи

Вот некоторые ключевые идеи этого проекта, которые помогут группам со стратегией наблюдения.

• Контекстуальные метаданные должны быть встроены в начале процесса генерации телеметрии, чтобы облегчить корреляцию вниз по течению.
• Структурированные интерфейсы данных Создайте API-управляемые структурированные слои запросов, чтобы сделать телеметрию более доступными.
• Контекст-ai ai Фокусирует анализ данных, богатых контекстом, для повышения точности и актуальности.
• Методы обогащения контекста и ИИ должны быть уточняются на регулярной основе с использованием практической оперативной обратной связи.

Заключение

Соединение структурированных конвейеров данных и ИИ имеет огромное обещание для наблюдения. Мы можем преобразовать обширные данные телеметрии в действенную информацию, используя структурированные протоколы, такие как MCP и AI-анализ, что приводит к проактивным, а не реактивным системам. Lumigo идентифицирует три столпа наблюдения — журналыВ метрикии следы — которые необходимы. Без интеграции инженеры вынуждены вручную коррелировать разрозненные источники данных, замедляя реакцию инцидента.

То, как мы генерируем телеметрию, требуется структурные изменения, а также аналитические методы для извлечения значения.

Pronnoy Goswami — это облачная, специалист по инфраструктуре ИИ и распределенных систем.