От терабайт до инсайтов: раскрытие возможностей реальной архитектуры наблюдаемости ИИ
Работа и масштабирование платформы электронной коммерции, которая обрабатывает миллионы транзакций в минуту, генерирует огромные объемы телеметрических данных. Сюда входят метрики, журналы и трассировки, поступающие из многочисленных микросервисов. Когда происходит критический инцидент, инженеры, находящиеся на дежурстве, должны проанализировать этот океан данных, чтобы найти важные сигналы и выводы, что часто сравнивают с поиском иголки в стоге сена.
В такой ситуации наблюдаемость часто становится источником разочарования, а не ясности. Чтобы решить эту основную проблему, я начал исследовать решение с использованием протокола Model Context Protocol (MCP) для добавления значимого контекста и вывода заключений из журналов и распределенных трассировок. В этой статье подробно описан мой путь по созданию платформы наблюдаемости на базе искусственного интеллекта, объяснена базовая архитектура системы и поделены практические уроки.
Основные проблемы современной наблюдаемости
В современных программных системах наблюдаемость — это не роскошь, а фундаментальное требование. Способность измерять и понимать поведение системы необходима для обеспечения надежности, оптимизации производительности и поддержания доверия пользователей. Как гласит пословица, «то, что измеряется, можно управлять».
Однако достичь эффективной наблюдаемости в облачных архитектурах на основе микрослужб чрезвычайно сложно. Один запрос пользователя может проходить через десятки микрослужб, каждая из которых генерирует журналы, метрики и трассировки. Это приводит к огромному объему телеметрических данных:
- Тербайты журналов, генерируемых ежедневно
- Десятки миллионов точек метрических данных и агрегатов
- Миллионы распределенных трассировок
- Тысячи корреляционных идентификаторов, создаваемых каждую минуту
Проблема заключается не только в объеме, но и в фрагментации этих данных. Отчеты показывают, что значительная часть организаций сталкивается с проблемой разрозненной телеметрии, и лишь немногие из них достигают действительно единого представления метрик, журналов и трассировок.
Журналы раскрывают один аспект ситуации, метрики — другой, а трассировки — еще один. Без единой нити контекста инженеры вынуждены вручную устанавливать корреляции, полагаясь на интуицию, институциональные знания и кропотливую детективную работу во время сбоев.
Столкнувшись с этой сложностью, я начал исследовать ключевой вопрос: как искусственный интеллект может помочь нам преодолеть фрагментированность данных и получить комплексную и полезную информацию? Более конкретно, можем ли мы использовать структурированный протокол, такой как MCP, чтобы сделать телеметрические данные более значимыми и доступными как для людей, так и для машин? Этот центральный вопрос лежал в основе проекта.
Понимание MCP с точки зрения конвейера данных
MCP, или Model Context Protocol (протокол контекста модели), определяется как открытый стандарт, который позволяет разработчикам устанавливать безопасное двунаправленное соединение между источниками данных и приложениями искусственного интеллекта. Этот структурированный конвейер данных включает в себя несколько ключевых функций:
- Контекстуальный ETL для ИИ: стандартизация извлечения контекста из различных источников данных.
- Структурированный интерфейс запросов: предоставление системам искусственного интеллекта прозрачного и понятного уровня для доступа к данным.
- Семантическое обогащение данных: встраивание значимого контекста непосредственно в телеметрические сигналы.
Эта структура может изменить наблюдаемость с реактивной деятельности по решению проблем на более проактивную практику, основанную на аналитических данных.
Обзор архитектуры системы и потока данных
Прежде чем углубляться в детали реализации, давайте обрисуем общую архитектуру системы.

Схема архитектуры системы наблюдаемости ИИ на основе MCP Первый уровень включает в себя генерацию контекстных телеметрических данных путем встраивания стандартизированных метаданных, таких как идентификаторы пользователей, идентификаторы запросов и названия служб, во все телеметрические сигналы, включая распределенные трассировки, журналы и метрики. На втором уровне эти обогащенные данные принимаются сервером MCP, который индексирует и структурирует их, предоставляя клиентам доступ через специальные API. Наконец, аналитический движок на базе ИИ использует эти структурированные, богатые контекстом данные для выполнения таких задач, как обнаружение аномалий, корреляционный анализ и определение первопричин проблем приложений.
Такая многоуровневая архитектура гарантирует, что как системы искусственного интеллекта, так и инженерные команды получают контекстные, применимые на практике аналитические данные непосредственно из телеметрических данных.
Подробное описание реализации: трехслойная система
Давайте рассмотрим практическую реализацию нашей платформы наблюдаемости на базе MCP, уделяя особое внимание преобразованию данных на каждом этапе.
Уровень 1: генерация данных, обогащенных контекстом
Начальный этап гарантирует, что наши телеметрические данные содержат достаточный контекст для значимого анализа. Основная идея заключается в том, что корреляция данных должна устанавливаться в момент их создания, а не во время последующего анализа.
def process_checkout(user_id, cart_items, payment_method):
«««Моделируйте процесс оформления заказа с помощью телеметрии, обогащенной контекстом».
# Генерировать идентификатор корреляции
order_id = f”order-{uuid.uuid4().hex[:8]}”
request_id = f”req-{uuid.uuid4().hex[:8]}”
# Инициализация словаря контекста, который будет применяться
context = {
“user_id”: user_id,
“order_id”: order_id,
«request_id»: request_id,
«cart_item_count»: len(cart_items),
«payment_method»: способ_оплаты,
«service_name»: «checkout»,
«service_version»: «v1.0.0»
}
# Запустить трассировку OTel с тем же контекстом
с помощью tracer.start_as_current_span(
«process_checkout»,
attributes={k: str(v) for k, v in context.items()}
) as checkout_span:
# Ведение журнала с использованием того же контекста
logger.info(f”Начало процесса оформления заказа”, extra={“context”: json.dumps(context)})
# Распространение контекста
с tracer.start_as_current_span(«process_payment»):
# Логика обработки платежа…
logger.info(«Оплата обработана», extra={«context»:
json.dumps(context)})
Код 1. Обогащение контекста для журналов и трассировок
Эта методология гарантирует, что каждый телеметрический сигнал — будь то запись в журнале, метрика или трассировка — несет в себе одну и ту же основную контекстную информацию, эффективно решая проблему корреляции у ее источника.
Уровень 2: облегчение доступа к данным через сервер MCP
Следующий уровень включает создание сервера MCP, который преобразует необработанные телеметрические данные в API, доступный для запросов. Основные операции с данными включают:
- Индексирование: создание эффективных поисковых систем по всем контекстным полям.
- Фильтрация: выбор соответствующих поднаборов телеметрических данных на основе критериев.
- Агрегирование: вычисление статистических показателей за определенные временные интервалы.
@app.post(“/mcp/logs”, response_model=List[Log])
def query_logs(query: LogQuery):
«»»Запрос журналов с определенными фильтрами»»»
results = LOG_DB.copy()
# Применить контекстные фильтры
if query.request_id:
results = [log for log in results if log[“context”].get(“request_id”) == query.request_id]
if query.user_id:
results = [log for log in results if log[“context”].get(“user_id”) == query.user_id]
# Применить фильтры по времени
if query.time_range:
start_time = datetime.fromisoformat(query.time_range[«start»])
end_time = datetime.fromisoformat(query.time_range[«end»])
results = [log for log in results
if start_time
# Сортировкарезультатов по временной метке
results = sorted(results, key=lambda x: x[«timestamp»], reverse=True)
return results[:query.limit] if query.limit else results
Код 2. Преобразование данных с помощью сервера MCP
Этот уровень эффективно преобразует нашу телеметрию из неструктурированного хранилища данных в структурированный интерфейс, оптимизированный для запросов, который системы искусственного интеллекта могут эффективно использовать.
Уровень 3: Аналитический движок на базе искусственного интеллекта
Последним компонентом является движок искусственного интеллекта, который использует данные через интерфейс MCP для выполнения расширенного анализа, в том числе:
- Многомерный анализ: корреляция сигналов в журналах, метриках и трассировках.
- Обнаружение аномалий: выявление статистических отклонений от установленных базовых показателей.
- Анализ первопричин: использование контекстуальных подсказок для точного определения вероятного источника проблем.
def analyze_incident(self, request_id=None, user_id=None, timeframe_minutes=30):
«Анализ телеметрических данных для определения первопричины и рекомендаций».
# Определение временного окна анализа
end_time = datetime.now()
start_time = end_time – timedelta(minutes=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”, “unknown”) for log in logs)
# Получить метрики для этих сервисов
metrics_by_service = {}
for service in services:
for metric_name in [«latency», «error_rate», «throughput»]:
metric_data = self.fetch_metrics(service, metric_name, time_range)
# Рассчитать статистические свойства
values = [point[“value”] for point in metric_data[“data_points”]]
metrics_by_service[f”{service}.{metric_name}”] = {
«mean»: statistics.mean(values) if values else 0,
«median»: statistics.median(values) if values else 0,
«stdev»: statistics.stdev(values) if len(values) > 1 else 0,
«min»: min(значения) если значения иначе 0,
«max»: max(values) if values else 0
}
# Выявление аномалий с помощью z-показателя
аномалии = []
для metric_name, stats в metrics_by_service.items():
if stats[“stdev”] > 0: # Избегайте деления на ноль
z_score = (stats[«max»] – stats[«mean»]) / stats[«stdev»]
if z_score > 2: # Более 2 стандартных отклонений
anomalies.append({
«metric»: metric_name,
«z_score»: z_score,
«severity»: «high», если z_score > 3, иначе «medium»
})
return {
«summary»: ai_summary,
«аномалии»: аномалии,
«затронутые_услуги»: список(услуги),
«recommendation»: ai_recommendation
}
Код 3. Анализ инцидентов, обнаружение аномалий и метод вывода
Влияние MCP на улучшение наблюдаемости
Интеграция MCP с платформами наблюдаемости открывает значительные возможности для улучшения управления и понимания сложных телеметрических данных. Ключевые преимущества включают:
- Ускоренное обнаружение аномалий, что приводит к сокращению среднего времени обнаружения (MTTD) и среднего времени устранения (MTTR).
- Упрощенная идентификация первопричин проблем.
- Сокращение количества ложных тревог и тревог, не требующих действий, что снижает утомляемость от тревог и повышает производительность разработчиков.
- Меньшее количество прерываний и переключений контекста во время устранения инцидентов, что повышает общую эффективность инженерной команды.
Полезные выводы и рекомендации
Вот несколько ключевых выводов из этого проекта, которые могут помочь командам в совершенствовании своей стратегии наблюдаемости:
- Внедряйте контекстные метаданные на ранних этапах процесса генерации телеметрии, чтобы обеспечить беспрепятственную корреляцию на последующих этапах.
- Внедрите структурированные интерфейсы данных для создания API-слоев с возможностью запросов, что сделает телеметрию более доступной.
- Сосредоточьте анализ ИИ на данных, богатых контекстом, чтобы повысить точность и релевантность аналитических данных.
- Постоянно совершенствуйте методы обогащения контекста и модели искусственного интеллекта на основе оперативной обратной связи и реального использования.
Заключение
Сближение структурированных конвейеров данных и искусственного интеллекта открывает огромные перспективы для будущего наблюдаемости. Используя протоколы, такие как MCP, и анализ на основе искусственного интеллекта, мы можем преобразовать огромные объемы телеметрических данных в практические, проактивные выводы. Три основные составляющие наблюдаемости — журналы, метрики и трассировки — имеют важное значение, но их истинная сила раскрывается только при интеграции. Без нее инженеры по-прежнему вынуждены вручную сопоставлять разрозненные источники данных, что замедляет реагирование на критические инциденты.
В конечном итоге, для извлечения значимых выводов требуются не только передовые аналитические методы, но и фундаментальные изменения в том, как мы с самого начала генерируем и структурируем телеметрию.
Проной Госвами — специалист по облачным технологиям, инфраструктуре искусственного интеллекта и распределенным системам.
Связанная статья
DeepL, известная своими услугами по переводу текстов, теперь занимается переводом речи
DeepL, компания-переводчик, наиболее известная своими инструментами для перевода текстов, сегодня представила набор решений для перевода «голос-голос», предназначенный для таких сценариев, как встречи
Заметки Талата по искусственному интеллекту хранятся прямо на вашем устройстве, а не в облаке
Granola — приложение для ведения заметок на базе искусственного интеллекта, оцениваемое в 250 миллионов долларов, — завоевало популярность среди основателей технологических компаний и венчурных инвест
Новый Roewe i6 поступил в продажу по цене 659 000 юаней; в его основе лежат процессор Snapdragon 8155 и большая модель Doubao
Сегодня компания SAIC Roewe представила новый Roewe i6 — компактный седан, полностью воплотивший в себе стилистику модели Roewe D7. Характерная большая вертикальная решетка радиатора и горизонтальная
Рекомендации по связанным специальным темам
Комментарии (1)
Moi qui pensais qu'un dashboard Kibana basique suffisait... Quand ils parlent de 'scale' pour des milliers de transactions par seconde, ça donne le vertige. Comment font-ils réellement pour repérer une anomalie spécifique dans tout ce bruit de données en temps réel ? 🤔 L'observabilité m'a toujours semblé plus simple en théorie qu'en pratique, surtout pour des systèmes distributés complexes. On se rend compte que les beaux diagrammes d'architecture sont une chose, mais la gestion en production en est une autre !
Работа и масштабирование платформы электронной коммерции, которая обрабатывает миллионы транзакций в минуту, генерирует огромные объемы телеметрических данных. Сюда входят метрики, журналы и трассировки, поступающие из многочисленных микросервисов. Когда происходит критический инцидент, инженеры, находящиеся на дежурстве, должны проанализировать этот океан данных, чтобы найти важные сигналы и выводы, что часто сравнивают с поиском иголки в стоге сена.
В такой ситуации наблюдаемость часто становится источником разочарования, а не ясности. Чтобы решить эту основную проблему, я начал исследовать решение с использованием протокола Model Context Protocol (MCP) для добавления значимого контекста и вывода заключений из журналов и распределенных трассировок. В этой статье подробно описан мой путь по созданию платформы наблюдаемости на базе искусственного интеллекта, объяснена базовая архитектура системы и поделены практические уроки.
Основные проблемы современной наблюдаемости
В современных программных системах наблюдаемость — это не роскошь, а фундаментальное требование. Способность измерять и понимать поведение системы необходима для обеспечения надежности, оптимизации производительности и поддержания доверия пользователей. Как гласит пословица, «то, что измеряется, можно управлять».
Однако достичь эффективной наблюдаемости в облачных архитектурах на основе микрослужб чрезвычайно сложно. Один запрос пользователя может проходить через десятки микрослужб, каждая из которых генерирует журналы, метрики и трассировки. Это приводит к огромному объему телеметрических данных:
- Тербайты журналов, генерируемых ежедневно
- Десятки миллионов точек метрических данных и агрегатов
- Миллионы распределенных трассировок
- Тысячи корреляционных идентификаторов, создаваемых каждую минуту
Проблема заключается не только в объеме, но и в фрагментации этих данных. Отчеты показывают, что значительная часть организаций сталкивается с проблемой разрозненной телеметрии, и лишь немногие из них достигают действительно единого представления метрик, журналов и трассировок.
Журналы раскрывают один аспект ситуации, метрики — другой, а трассировки — еще один. Без единой нити контекста инженеры вынуждены вручную устанавливать корреляции, полагаясь на интуицию, институциональные знания и кропотливую детективную работу во время сбоев.
Столкнувшись с этой сложностью, я начал исследовать ключевой вопрос: как искусственный интеллект может помочь нам преодолеть фрагментированность данных и получить комплексную и полезную информацию? Более конкретно, можем ли мы использовать структурированный протокол, такой как MCP, чтобы сделать телеметрические данные более значимыми и доступными как для людей, так и для машин? Этот центральный вопрос лежал в основе проекта.
Понимание MCP с точки зрения конвейера данных
MCP, или Model Context Protocol (протокол контекста модели), определяется как открытый стандарт, который позволяет разработчикам устанавливать безопасное двунаправленное соединение между источниками данных и приложениями искусственного интеллекта. Этот структурированный конвейер данных включает в себя несколько ключевых функций:
- Контекстуальный ETL для ИИ: стандартизация извлечения контекста из различных источников данных.
- Структурированный интерфейс запросов: предоставление системам искусственного интеллекта прозрачного и понятного уровня для доступа к данным.
- Семантическое обогащение данных: встраивание значимого контекста непосредственно в телеметрические сигналы.
Эта структура может изменить наблюдаемость с реактивной деятельности по решению проблем на более проактивную практику, основанную на аналитических данных.
Обзор архитектуры системы и потока данных
Прежде чем углубляться в детали реализации, давайте обрисуем общую архитектуру системы.

Первый уровень включает в себя генерацию контекстных телеметрических данных путем встраивания стандартизированных метаданных, таких как идентификаторы пользователей, идентификаторы запросов и названия служб, во все телеметрические сигналы, включая распределенные трассировки, журналы и метрики. На втором уровне эти обогащенные данные принимаются сервером MCP, который индексирует и структурирует их, предоставляя клиентам доступ через специальные API. Наконец, аналитический движок на базе ИИ использует эти структурированные, богатые контекстом данные для выполнения таких задач, как обнаружение аномалий, корреляционный анализ и определение первопричин проблем приложений.
Такая многоуровневая архитектура гарантирует, что как системы искусственного интеллекта, так и инженерные команды получают контекстные, применимые на практике аналитические данные непосредственно из телеметрических данных.
Подробное описание реализации: трехслойная система
Давайте рассмотрим практическую реализацию нашей платформы наблюдаемости на базе MCP, уделяя особое внимание преобразованию данных на каждом этапе.
Уровень 1: генерация данных, обогащенных контекстом
Начальный этап гарантирует, что наши телеметрические данные содержат достаточный контекст для значимого анализа. Основная идея заключается в том, что корреляция данных должна устанавливаться в момент их создания, а не во время последующего анализа.
| def process_checkout(user_id, cart_items, payment_method): «««Моделируйте процесс оформления заказа с помощью телеметрии, обогащенной контекстом». # Генерировать идентификатор корреляции order_id = f”order-{uuid.uuid4().hex[:8]}” request_id = f”req-{uuid.uuid4().hex[:8]}” # Инициализация словаря контекста, который будет применяться context = { “user_id”: user_id, “order_id”: order_id, «request_id»: request_id, «cart_item_count»: len(cart_items), «payment_method»: способ_оплаты, «service_name»: «checkout», «service_version»: «v1.0.0» } # Запустить трассировку OTel с тем же контекстом с помощью tracer.start_as_current_span( «process_checkout», attributes={k: str(v) for k, v in context.items()} ) as checkout_span: # Ведение журнала с использованием того же контекста logger.info(f”Начало процесса оформления заказа”, extra={“context”: json.dumps(context)}) # Распространение контекста с tracer.start_as_current_span(«process_payment»): # Логика обработки платежа… logger.info(«Оплата обработана», extra={«context»: json.dumps(context)}) |
Код 1. Обогащение контекста для журналов и трассировок
Эта методология гарантирует, что каждый телеметрический сигнал — будь то запись в журнале, метрика или трассировка — несет в себе одну и ту же основную контекстную информацию, эффективно решая проблему корреляции у ее источника.
Уровень 2: облегчение доступа к данным через сервер MCP
Следующий уровень включает создание сервера MCP, который преобразует необработанные телеметрические данные в API, доступный для запросов. Основные операции с данными включают:
- Индексирование: создание эффективных поисковых систем по всем контекстным полям.
- Фильтрация: выбор соответствующих поднаборов телеметрических данных на основе критериев.
- Агрегирование: вычисление статистических показателей за определенные временные интервалы.
| @app.post(“/mcp/logs”, response_model=List[Log]) def query_logs(query: LogQuery): «»»Запрос журналов с определенными фильтрами»»» results = LOG_DB.copy() # Применить контекстные фильтры if query.request_id: results = [log for log in results if log[“context”].get(“request_id”) == query.request_id] if query.user_id: results = [log for log in results if log[“context”].get(“user_id”) == query.user_id] # Применить фильтры по времени if query.time_range: start_time = datetime.fromisoformat(query.time_range[«start»]) end_time = datetime.fromisoformat(query.time_range[«end»]) results = [log for log in results if start_time # Сортировкарезультатов по временной метке results = sorted(results, key=lambda x: x[«timestamp»], reverse=True) return results[:query.limit] if query.limit else results |
Код 2. Преобразование данных с помощью сервера MCP
Этот уровень эффективно преобразует нашу телеметрию из неструктурированного хранилища данных в структурированный интерфейс, оптимизированный для запросов, который системы искусственного интеллекта могут эффективно использовать.
Уровень 3: Аналитический движок на базе искусственного интеллекта
Последним компонентом является движок искусственного интеллекта, который использует данные через интерфейс MCP для выполнения расширенного анализа, в том числе:
- Многомерный анализ: корреляция сигналов в журналах, метриках и трассировках.
- Обнаружение аномалий: выявление статистических отклонений от установленных базовых показателей.
- Анализ первопричин: использование контекстуальных подсказок для точного определения вероятного источника проблем.
| def analyze_incident(self, request_id=None, user_id=None, timeframe_minutes=30): «Анализ телеметрических данных для определения первопричины и рекомендаций». # Определение временного окна анализа end_time = datetime.now() start_time = end_time – timedelta(minutes=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”, “unknown”) for log in logs) # Получить метрики для этих сервисов metrics_by_service = {} for service in services: for metric_name in [«latency», «error_rate», «throughput»]: metric_data = self.fetch_metrics(service, metric_name, time_range) # Рассчитать статистические свойства values = [point[“value”] for point in metric_data[“data_points”]] metrics_by_service[f”{service}.{metric_name}”] = { «mean»: statistics.mean(values) if values else 0, «median»: statistics.median(values) if values else 0, «stdev»: statistics.stdev(values) if len(values) > 1 else 0, «min»: min(значения) если значения иначе 0, «max»: max(values) if values else 0 } # Выявление аномалий с помощью z-показателя аномалии = [] для metric_name, stats в metrics_by_service.items(): if stats[“stdev”] > 0: # Избегайте деления на ноль z_score = (stats[«max»] – stats[«mean»]) / stats[«stdev»] if z_score > 2: # Более 2 стандартных отклонений anomalies.append({ «metric»: metric_name, «z_score»: z_score, «severity»: «high», если z_score > 3, иначе «medium» }) return { «summary»: ai_summary, «аномалии»: аномалии, «затронутые_услуги»: список(услуги), «recommendation»: ai_recommendation } |
Код 3. Анализ инцидентов, обнаружение аномалий и метод вывода
Влияние MCP на улучшение наблюдаемости
Интеграция MCP с платформами наблюдаемости открывает значительные возможности для улучшения управления и понимания сложных телеметрических данных. Ключевые преимущества включают:
- Ускоренное обнаружение аномалий, что приводит к сокращению среднего времени обнаружения (MTTD) и среднего времени устранения (MTTR).
- Упрощенная идентификация первопричин проблем.
- Сокращение количества ложных тревог и тревог, не требующих действий, что снижает утомляемость от тревог и повышает производительность разработчиков.
- Меньшее количество прерываний и переключений контекста во время устранения инцидентов, что повышает общую эффективность инженерной команды.
Полезные выводы и рекомендации
Вот несколько ключевых выводов из этого проекта, которые могут помочь командам в совершенствовании своей стратегии наблюдаемости:
- Внедряйте контекстные метаданные на ранних этапах процесса генерации телеметрии, чтобы обеспечить беспрепятственную корреляцию на последующих этапах.
- Внедрите структурированные интерфейсы данных для создания API-слоев с возможностью запросов, что сделает телеметрию более доступной.
- Сосредоточьте анализ ИИ на данных, богатых контекстом, чтобы повысить точность и релевантность аналитических данных.
- Постоянно совершенствуйте методы обогащения контекста и модели искусственного интеллекта на основе оперативной обратной связи и реального использования.
Заключение
Сближение структурированных конвейеров данных и искусственного интеллекта открывает огромные перспективы для будущего наблюдаемости. Используя протоколы, такие как MCP, и анализ на основе искусственного интеллекта, мы можем преобразовать огромные объемы телеметрических данных в практические, проактивные выводы. Три основные составляющие наблюдаемости — журналы, метрики и трассировки — имеют важное значение, но их истинная сила раскрывается только при интеграции. Без нее инженеры по-прежнему вынуждены вручную сопоставлять разрозненные источники данных, что замедляет реагирование на критические инциденты.
В конечном итоге, для извлечения значимых выводов требуются не только передовые аналитические методы, но и фундаментальные изменения в том, как мы с самого начала генерируем и структурируем телеметрию.
Проной Госвами — специалист по облачным технологиям, инфраструктуре искусственного интеллекта и распределенным системам.
DeepL, известная своими услугами по переводу текстов, теперь занимается переводом речи
DeepL, компания-переводчик, наиболее известная своими инструментами для перевода текстов, сегодня представила набор решений для перевода «голос-голос», предназначенный для таких сценариев, как встречи
Заметки Талата по искусственному интеллекту хранятся прямо на вашем устройстве, а не в облаке
Granola — приложение для ведения заметок на базе искусственного интеллекта, оцениваемое в 250 миллионов долларов, — завоевало популярность среди основателей технологических компаний и венчурных инвест
Новый Roewe i6 поступил в продажу по цене 659 000 юаней; в его основе лежат процессор Snapdragon 8155 и большая модель Doubao
Сегодня компания SAIC Roewe представила новый Roewe i6 — компактный седан, полностью воплотивший в себе стилистику модели Roewe D7. Характерная большая вертикальная решетка радиатора и горизонтальная
Moi qui pensais qu'un dashboard Kibana basique suffisait... Quand ils parlent de 'scale' pour des milliers de transactions par seconde, ça donne le vertige. Comment font-ils réellement pour repérer une anomalie spécifique dans tout ce bruit de données en temps réel ? 🤔 L'observabilité m'a toujours semblé plus simple en théorie qu'en pratique, surtout pour des systèmes distributés complexes. On se rend compte que les beaux diagrammes d'architecture sont une chose, mais la gestion en production en est une autre !





Дом






