Log Service объединяет сбор, индексирование и доставку логов для масштабируемых распределённых приложений

Log Service — управляемая платформа для централизованного сбора, индексирования и доставки логов в масштабируемых распределённых приложениях; она объединяет агенты, SDK и REST‑API, обеспечивает региональные границы хранения и масштабируемое шардирование, что позволяет выдерживать высокую пропускную способность и обеспечивать быстрые запросы. Для инженеров платформенных и DevOps‑команд это сокращает потребность в дополнительных сервисах предобработки и ускоряет интеграцию логов с downstream‑аналитикой и системами алертинга.

Платформа принимает данные тремя путями инжеста. Во-первых, Logtail — управляемый агент для виртуальных машин, хостов контейнеров и узлов Kubernetes — парсит логи локально и отправляет записи по HTTPS на региональную точку приёма (порт 443). Агент распознаёт однострочные тексты, регулярные выражения с именованными группами, JSON, CSV/TSV, syslog и распространённые форматы access‑логов; правила парсинга и определения конфигураций централизованно распространяются из консоли.

Во-вторых, для событий внутри приложения, которые не записываются на диск, доступны SDK для Java, Python, Go,.NET и Node.js, использующие PutLogs HTTP API: клиенты локально батчат данные, выполняют ретраи с экспоненциальным бэкоффом и отправляют записи асинхронно, чтобы не блокировать поток приложения. В качестве лёгкого варианта интеграции возможен прямой вызов REST API: запросы подписываются HMAC‑SHA256 с учётными данными AccessKey.

Хранение организовано трёхуровнево: Project — контейнер, привязанный к региону и выступающий границей RAM‑прав; Logstore — гибкая схема внутри проекта, обычно соответствующая одному сервису или семейству логов; Shard — минимальная единица пропускной способности. Каждая шард поддерживает пропускную способность до 5 MiB/s на запись и 10 MiB/s на чтение. Маршрутизация по шарду выполняется по MD5 от partition key; высокая кардинальность и равномерное распределение ключей (например, идентификаторы инстансов, trace‑id, tenant‑id) помогают избежать «hot‑shard».

Шарды можно динамически делить и сливать по мере изменения нагрузки: операция split разделяет хэш‑диапазон на два поддиапазона, при этом существующие данные остаются в родительском шарде, который переходит в режим только для чтения, а новые записи направляются в дочерние шарды; операция неблокирующая и обычно завершается за секунды. Для поиска Log Service предлагает два типа индексов: full‑text — с токенизацией тела логов, и field‑index — для типизированных полей (text, long, double, JSON); конфигурация индексов может изменяться после их создания.