Перевод оригинальной статьи Collecting Docker Container Logs with OpenTelemetry.

Когда в Docker-контейнерах что-то выходит из строя, команда docker logs позволяет довольно быстро приблизиться к поиску причины. Однако её ограничения становятся очевидными, когда количество хостов превышает число тех, к которым можно подключиться по SSH, контейнеры уже завершили работу, а поиск по логам разных сервисов требует ручного объединения вывода.

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

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

Как Docker собирает и хранит логи

По умолчанию Docker перехватывает все, что контейнер записывает в stdout и stderr, после чего передаёт эти данные драйверу логирования. Драйвер, используемый по умолчанию — json-file, — записывает эти потоки в файл на хосте.

/var/lib/docker/containers/<container-id>/<container-id>-json.log

Этот файл содержит по одному объекту JSON для каждой строки лога, включая текст сообщения, поток (stdout или stderr) и временную метку.

{
  "log": "Starting cloud controller for cluster desktop",
  "stream": "stderr",
  "time": "2026-04-18T14:28:28.812549652Z"
}

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

Более эффективный подход заключается в запуске OpenTelemetry Collector на каждом хосте и настройке Docker таким образом, чтобы он передавал логи непосредственно в Collector в момент их записи контейнерами, полностью исключая необходимость доступа к файлам. Затем Collector пересылает эти логи в централизованную систему хранения, где можно выполнять поиск и корреляцию данных по всей инфраструктуре. Остальная часть этого руководства посвящена настройке именно такого решения.

Почему чтение файлов логов Docker зачастую является не лучшим выбором

Когда специалисты впервые интегрируют логи Docker в OpenTelemetry, наиболее очевидным решением кажется настройка получателя filelog на каталог /var/lib/docker/containers/ с последующим разбором файлов. Такой подход действительно работает, однако нередко сопровождается дополнительными сложностями.

JSON-оболочка, которую Docker добавляет вокруг каждой строки лога, не полностью соответствует исходному сообщению, записанному приложением. Получателю filelog требуется конвейер операторов, который извлечёт внешний JSON, получит содержимое поля log, затем, если приложение также пишет логи в формате JSON, разберёт внутренний JSON и сформирует корректную запись лога OpenTelemetry.

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

Более простой подход: драйвер логирования Fluentd

Docker поддерживает драйвер логирования fluentd, который отправляет логи непосредственно на совместимую с Fluentd конечную точку сразу после их записи контейнером, вместо того чтобы сначала сохранять их в файлы и затем считывать.

Получатель fluentforward в OpenTelemetry Collector использует тот же протокол, поэтому можно полностью отказаться от использования самого Fluentd и принимать события непосредственно в Collector.

Схема выглядит следующим образом:

Логи передаются через сокет сразу после их создания, поэтому отсутствует необходимость в чтении файлов, а также не требуется настраивать конвейер операторов для удаления JSON-оболочки, добавляемой Docker.

Настройка драйвера логирования Docker

Сначала необходимо настроить Docker на использование драйвера логирования fluentd. Это можно сделать глобально в файле /etc/docker/daemon.json, чтобы настройка применялась ко всем контейнерам данного хоста.

{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224",
    "fluentd-async": "true",
    "fluentd-sub-second-precision": "true",
    "tag": "docker.{{.Name}}"
  }
}

Параметр fluentd-asyncиграет здесь важную роль. Без него Docker блокирует запись логов контейнером до тех пор, пока Collector не подтвердит получение каждого сообщения. Если Collector окажется недоступен, контейнер немедленно прекратит работу.

При использовании асинхронного режима Docker буферизует сообщения локально и повторяет попытки их отправки в фоновом режиме. Однако если Collector так и не станет доступен, Docker сохранит не более fluentd-buffer-limit сообщений (по умолчанию 1 048 576), после чего начнёт молча отбрасывать новые записи.

Без параметра fluentd-sub-second-precision временные метки будут округляться до целых секунд. Это делает ненадёжным порядок логов и их корреляцию в сервисах, которые записывают более нескольких строк в секунду.

После изменения файла daemon.json необходимо перезапустить демон Docker. Следует учитывать, что новые настройки будут применены только к вновь созданным контейнерам, поэтому существующие контейнеры потребуется пересоздать:

sudo systemctl restart docker

Теперь, когда Docker начнёт пересылать логи контейнеров на порт 24224, потребуется экземпляр Collector, прослушивающий этот порт и принимающий поступающие данные.

Конфигурация для каждого сервиса в Docker Compose

Если вы не можете изменить конфигурацию демона Docker напрямую или если для отдельных сервисов требуются разные параметры, драйвер логирования можно настроить отдельно для каждого сервиса в файле Compose:

# docker-compose.yml
services:
  api:
    image: my-api:latest
    logging:
      driver: fluentd
      options:
        fluentd-address: localhost:24224
        fluentd-async: "true"
        fluentd-sub-second-precision: "true"
        tag: docker.{{.Name}}

  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    volumes:
      - ./otelcol.yaml:/etc/otelcol-contrib/config.yaml
    ports:
      - 24224:24224

При использовании Docker Compose необходимо указывать localhost, а не имя сервиса (otel-collector) для разрешения адреса Fluentd, поскольку этот адрес разрешается демоном Docker на хосте, где имена сервисов Compose отсутствуют в DNS.

Чтобы избежать повторения одинаковой конфигурации для нескольких сервисов, можно использовать YAML-якорь:

# docker-compose.yml
x-logging: &default-logging
  driver: fluentd
  options:
    fluentd-address: localhost:24224
    fluentd-async: "true"
    fluentd-sub-second-precision: "true"
    tag: docker.{{.Name}}

services:
  api:
    image: my-api:latest
    logging: *default-logging

  worker:
    image: my-worker:latest
    logging: *default-logging

  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    volumes:
      - ./otelcol.yaml:/etc/otelcol-contrib/config.yaml
    ports:
      - 24224:24224

Обеспечение надежной асинхронной доставки

Асинхронный режим решает проблему обратного давления (back-pressure), однако создаёт другую проблему: если буфер в памяти заполняется быстрее, чем Collector успевает обработать накопленные данные, Docker начинает отбрасывать сообщения логов. По умолчанию буфер рассчитан на 1 048 576 событий, чего достаточно для большинства сервисов, однако при обнаружении потерь логов его размер можно увеличить:

{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-async": "true",
    "fluentd-buffer-limit": "2097152"
  }
}

По умолчанию Docker повторяет попытки доставки неограниченное количество раз, если Collector недоступен. Также можно настроить интервал ожидания между повторными попытками с помощью параметра fluentd-retry-wait, значение которого по умолчанию составляет одну секунду.

{
  "log-opts": {
    "fluentd-async": "true",
    "fluentd-retry-wait": "2s"
  }
}

Если Collector работает на том же хосте, что и Docker, а именно такая схема используется чаще всего, вероятность того, что он окажется настолько медленным, чтобы вызвать переполнение буфера, крайне мала.

Настройка OpenTelemetry Collector

Вам потребуется использовать образ otel/opentelemetry-collector-contrib, поскольку получатель fluent_forward отсутствует в базовой поставке OpenTelemetry Collector.

docker pull otel/opentelemetry-collector-contrib:0.154.0

Вот минимальная конфигурация, настраивающая получатель fluent_forward для приема логов Docker:

# otelcol.yaml
receivers:
  fluent_forward:
    endpoint: 0.0.0.0:24224

processors:
  resourcedetection/system:
    detectors: [system]
    system:
      hostname_sources: [os]

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    logs:
      receivers: [fluent_forward]
      processors: [resourcedetection/system]
      exporters: [debug]

Процессор resourcedetection/system автоматически добавляет имя хоста, что особенно полезно при корреляции логов, поступающих с нескольких хостов.

Добавьте Collector в качестве сервиса в файл Compose:

# docker-compose.yml
services:
  otel-collector:
    image: otel/opentelemetry-collector-contrib:0.154.0
    volumes:
      - ./otelcol.yaml:/etc/otelcol-contrib/config.yaml
    ports:
      - 24224:24224

После перезапуска сервисов можно проверить логи Collector и убедиться, что логи Docker-контейнеров успешно поступают:

docker compose logs otel-collector -f --no-log-prefix

Вы должны увидеть записи логов, поступающие от ваших контейнеров, где поле Body содержит исходную строку лога, а получатель fluent_forward автоматически добавляет такие атрибуты, как container_name, container_id и source:

2026-06-08T07:43:51.763Z        info    ResourceLog #0
Resource SchemaURL: https://opentelemetry.io/schemas/1.40.0
Resource attributes:
     -> host.name: Str(4e940d4722ea)
     -> os.type: Str(linux)
ScopeLogs #0
ScopeLogs SchemaURL:
InstrumentationScope
LogRecord #0
ObservedTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 2026-06-08 07:43:51 +0000 UTC
SeverityText:
SeverityNumber: Unspecified(0)
Body: Str({"timestamp": "2026-06-08T07:43:51+00:00","level": "info","pid": "29","client.address": "172.22.0.1","client.port": "34230","url.path": "/index.html","url.query": "","network.protocol.name": "HTTP/1.1","server.address": "localhost","server.port": "80","user_agent.original": "curl/8.5.0","http.request.method": "GET","http.request.header.referer": "","http.response.status_code": 200,"http.response.body.size": 615,"http.server.request.duration": 0.000,"trace_id": "cdc134217e5afb428b188b4271c3305f","span_id": "930898f94fe03e5b","parent_sampled": 0})
Attributes:
     -> fluent.tag: Str(docker.nginx-server)
     -> source: Str(stdout)
     -> container_id: Str(18d07bfa79470448896c0f2fcbd0aa076dd0082fc8642f1c6339e6174c4b5bc6)
     -> container_name: Str(/nginx-server)
Trace ID:
Span ID:
Flags: 0

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

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

Поле Body также содержит необработанную строку JSON, включающую данные, которые должны располагаться в других элементах модели данных OpenTelemetry: уровень критичности, временную метку, контекст трассировки, а также такие атрибуты, как http.response.status_code и http.request.method. Разбор этого JSON с помощью процессора transform и перенос каждого поля в соответствующее место модели данных OpenTelemetry делает эти данные доступными для поиска и анализа, вместо того чтобы они оставались скрытыми внутри строки.

После того как вы убедитесь, что логи успешно поступают и записи полностью соответствуют модели данных OpenTelemetry, экспортёр debug можно заменить на экспортёр, который будет передавать логи в используемую вами платформу наблюдаемости.

Заключительные мысли

Построенный в этом руководстве конвейер намеренно остается минималистичным. Один получатель, несколько процессоров и один экспортёр. Этого достаточно, чтобы передавать логи с хоста в систему хранения, однако возможности дальнейшего развития значительно шире: можно разбирать JSON в поле Body, переносить поля в соответствующие атрибуты OpenTelemetry, отфильтровывать лишние данные до их записи в хранилище или направлять логи различных сервисов в разные наборы данных.

Руководство по OpenTelemetry Collector — хороший следующий шаг, если вы хотите научиться строить более сложные конвейеры, а руководство по Fluent Forward Receiver более подробно описывает работу получателя.

Перевод оригинальной статьи Three Weeks in the Trenches: Hunting a 4GB Native Memory Leak That .NET Couldn’t See.

Кратко (TL;DR):Наши поды ASP.NET Core в Kubernetes завершались по OOM-kill каждые несколько часов во время предпускового пилотного запуска. Heap был практически пустой — 95% памяти занимала нативная память, невидимая для любых средств диагностики .NET. Причиной стали нестабильные мобильные соединения, создававшие тысячи «зомби»-подключений SignalR. Каждое такое подключение содержало собственные накладные расходы в нативной памяти среды выполнения — состояние подключения, структуры нативного взаимодействия (native interop) и многочисленные небольшие выделения памяти через malloc(), которые среда выполнения выполняет для каждого подключения. Поскольку размеры этих выделений были меньше порога 128 КБ для mmap() в glibc, они попадали во внутренний heap аллокатора, вызывая фрагментацию heap в десятках потоках. Освобождённая память никогда не возвращалась операционной системе. Дополнительный невидимый слой памяти составляли буферы отправки TCP ядра для уже несуществующих сокетов. Для устранения проблемы потребовалось внести четыре изменения на четырёх уровнях: сократить тайм-ауты SignalR (с 5 минут до 10 секунд); уменьшить тайм-аут бездействия ALB; устранить дублирование потоков данных; заменить стандартный аллокатор glibc на jemalloc с помощью LD_PRELOAD. После этого использование памяти подами стабилизировалось на уровне менее 1 ГБ. С тех пор не произошло ни одного OOM-kill.

День 0

Всё началось с уведомления поздним утром. Один из наших production-подов был завершён из-за нехватки памяти (OOM). Ничего необычного для системы под нагрузкой — за исключением того, что это продолжало происходить снова и снова. В рабочее время — примерно с 9:00 до 21:00, когда наши пользователи были активны, — поды разрастались до 4 ГБ и завершались. Kubernetes перезапускал их, наши мобильные клиенты автоматически переподключались через три секунды, и цикл начинался снова.

Я являюсь основателем и техническим директором BasicHomeLoan. Система, о которой идёт речь, обрабатывает запросы на управление лидами в режиме реального времени — каждое взаимодействие с клиентом, журнал звонков, сообщение WhatsApp и обновление статуса заявки на ипотечный кредит передаются в режиме реального времени назначенному сотруднику отдела обработки заявок и его руководству через SignalR. Цель заключается в том, чтобы к моменту звонка клиента все сотрудники команды сопровождения, которым необходимо об этом знать, уже владели этой информацией. Возможность видеть происходящее в режиме реального времени во всей организации позволяет быстрее реагировать на обращения клиентов и повышает их удовлетворённость. Это был предпусковой пилотный запуск. Около 200 подключённых устройств, наша команда сопровождения тестировала систему перед полномасштабным внедрением. Поскольку это был контролируемый пилотный запуск, мы могли сопоставить IP-адреса клиентов и сетевые обращения с конкретными устройствами. Именно так мы обнаружили любопытную деталь: примерно половина нестабильных подключений поступала вовсе не из какого-то удалённого сельского района — они поступали из подвала и с первого этажа нашего собственного офиса, где мобильная связь была очень плохой. После того как мы выявили эту закономерность, мы специально разместили тестировщиков и разработчиков в подвале с их телефонами, чтобы намеренно воспроизводить обрывы соединения, одновременно наблюдая за серверными метриками в режиме реального времени.

Архитектура была следующей: когда изменялась заявка на ипотеку — поступало новое сообщение WhatsApp, обновлялся статус или добавлялась запись о звонке, — мы считывали полную сущность заявки и связанные с ней таблицы, а затем отправляли её всем клиентам, которым необходимо было видеть эти данные. Поскольку приложение работало в нескольких подах Kubernetes, SignalR использовал Redis backplane — каждое широковещательное сообщение проходило через Redis, чтобы все поды могли доставить его своим подключённым клиентам независимо от того, какой под обработал исходный запрос. Позже станет понятно, почему это оказалось важным.

Использование памяти пода говорило само за себя: в рабочее время что-то потребляло 4 ГБ памяти. Чтобы выяснить, что именно, понадобилось три недели — и до тех пор, пока проблема не была устранена, мы не могли запустить систему.

Неделя 1: Очевидный подозреваемый

Первое, что приходит в голову любому .NET-разработчику, столкнувшемуся с проблемой нехватки памяти, — это проверить управляемый heap. Я снял полный дамп памяти с пода, который потреблял 3,7 ГБ, и открыл его с помощью dotnet-dump.

# The managed heap breakdown
eeheap -gc

# Result:
GC Heap Size:    ~207 MB

207 МБ из 3,7 ГБ. Управляемый heap использовал пять процентов от общего объема памяти.

Тем не менее я выполнил dumpheap -stat и действительно обнаружил проблему: наш интерцептор кэша второго уровня EF Core был настроен так, чтобы по умолчанию кэшировать все запросы, включая запросы потоковой передачи, которые выполнялись каждые две секунды. 172 000 объектов EFTableRow. 31 миллион строк. Я добавил .NotCached() ко всем запросам в нашем уведомителе потоковой передачи, повторно развернул приложение и начал наблюдать за метриками.

Объём управляемого heap уменьшился. RSS практически не изменился.

Это стало причиной того, что расследование стало таким изнурительным. Мы работали всю ночь, развёртывая исправления и проводя нагрузочные тесты — бессонная ночь за бессонной ночью. И каждый раз ночные тесты проходили успешно. Использование памяти оставалось стабильным, поды работали без сбоев. Мы наконец ложились спать, уверенные, что решили проблему. Но наступало 9 утра, 200 реальных пользователей из нашей команды сопровождения подключались со своих телефонов через нестабильную мобильную сеть, и уже через несколько часов поды снова начинали завершаться. Проблема проявлялась только при реальном мобильном трафике с реальных устройств, работавших в нестабильных сетях, — то, что невозможно было воспроизвести ни одним синтетическим ночным тестом.

Я принудительно запустил полную сборку мусора. Ничего. Вызвал GC.Collect(2, GCCollectionMode.Aggressive, true, true). Ничего. Память по-прежнему оставалась занятой, продолжая неуклонно расти, совершенно не реагируя на сборщик мусора.

Осознание
Наша точка проверки работоспособности это подтвердила. Объем нативной памяти составлял 2577 МБ при бюджете в 656 МБ — почти в 4 раза больше, чем должно было быть. Объем управляемого heap составлял 145 МБ. Сборщику мусора было нечего освобождать, потому что 95% памяти вообще не относились к управляемой памяти.

Небольшое отступление: что такое «нативная» память?

Если вы всю свою карьеру писали на C#, возможно, вам никогда не приходилось об этом задумываться. В .NET ваши объекты находятся в управляемом heap — области памяти, которой управляет сборщик мусора (GC). Когда вы создаёте объект, GC выделяет для него память. Когда на объект больше никто не ссылается, GC освобождает эту память. Именно с этим работают dumpheap, gcroot и GC.Collect().

Но приложение .NET не существует само по себе. Оно работает поверх среды выполнения, а та, в свою очередь, работает поверх операционной системы. И операционная система, среда выполнения и многие библиотеки, от которых зависит ваше приложение, выделяют память за пределами управляемого heap. Это и есть нативная память — память, выделяемая непосредственно у операционной системы с помощью функций уровня C, таких как malloc() и free(). Сборщик мусора .NET не может её видеть, отслеживать или освобождать. К ней относятся, например, буферы подключений к базе данных (MySQL считывает данные из сети в нативные буферы), внутренние структуры среды выполнения (состояние JIT-компилятора, стеки потоков) и — что было особенно важно в нашем случае — накладные расходы среды выполнения на каждое подключение. Каждое WebSocket-подключение приводит к выделению нативной памяти, пока среда выполнения .NET управляет его жизненным циклом: создаются структуры взаимодействия с нативным кодом, данные отслеживания подключения и множество небольших внутренних выделений памяти через malloc(), которые накапливаются при сотнях одновременных подключений. По отдельности они невелики, но в совокупности становятся значительными — и ни одно из этих выделений не видно сборщику мусора.

В Linux существует параметр RSS — Resident Set Size.Это общий объём физической памяти, который процесс фактически использует, согласно данным операционной системы. Он включает управляемую кучу, все нативные выделения памяти, стеки потоков и файлы, отображённые в память. Но Kubernetes ориентируется не только на RSS — он использует учёт памяти cgroup, который включает RSS и память ядра, потребляемую от имени процесса, например буферы TCP-сокетов. Когда Kubernetes принимает решение завершить под из-за нехватки памяти (OOM), он ориентируется именно на этот совокупный показатель, а не на размер управляемой кучи. Когда на панели мониторинга вы видите, что под потребляет 4 ГБ памяти, это и есть память cgroup.

Разница между управляемой кучей и RSS — это объём вашей нативной памяти. В нормально работающем приложении .NET нативная память может составлять 200–400 МБ — накладные расходы среды выполнения, пулы соединений, состояние JIT-компилятора. В нашем случае она составляла 3,5 ГБ.

Именно здесь отладка .NET разделяется на два мира. Всё, что я делал до этого момента — dumpheap, gcroot, принудительный запуск GC, — работает только с управляемой кучей. Память, которая поглощала наши поды, была нативной памятью и находилась ниже уровня среды выполнения .NET — в том слое, о котором большинству C#-разработчиков никогда не приходится задумываться.

Я переключился на LLDB — единственный отладчик, который способен видеть и управляемую, и нативную память в дампе Linux. И начал изучать, как на самом деле работает память в Linux. В частности, то, что называется glibc.

Неделя 2: Проблема зомби

Анализ дампа ни к чему определённому не привёл. Ни одно отдельное выделение нативной памяти не было достаточно большим, чтобы объяснить 3,5 ГБ. Это была не классическая утечка памяти — не забытый вызов malloc() без соответствующего free(). Каждому выделению памяти соответствовало её освобождение. Память освобождалась, но не возвращалась.

Чтобы понять причину, мне нужно было разобраться, что на самом деле происходит по сети. Вот наша архитектура:

Каждое изменение заявки приводило к полному чтению данных из базы и широковещательной отправке всем подключённым клиентам. Клиенты использовали SignalR только для получения данных — все изменения выполнялись через REST API. И именно здесь скрывалась проблема: в нашей конфигурации SignalR параметр ClientTimeoutInterval был установлен на пять минут.

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

Представьте, что происходит, когда мобильное устройство въезжает в тоннель, переключается с Wi-Fi на мобильную сеть или просто попадает в зону отсутствия сигнала. Сетевое соединение молча разрывается — без корректного завершения, без уведомления сервера, вообще без каких-либо сигналов. Сервер не знает, что клиент исчез. Он продолжает считать соединение активным и продолжает отправлять обновления сущностей в пустоту ещё в течение пяти минут, пока не срабатывает тайм-аут KeepAlive и не завершает это «зомби»-подключение.

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

Математика зомби

# With 100 unstable clients:
KeepAlive timeout:    300 seconds (5 minutes)
Client retry:         3 seconds (linear)
Silent drop rate:     ~20-30% of disconnects

# Worst case per unstable client:
300s timeout / 3s retry = up to 100 zombies stacking up
                          before the first one even times out
# Conservative estimate across fleet:
100 clients × ~20-30 zombies at peak = 2,000-3,000 zombie connections

Каждое зомби-подключение удерживало нативную память, недоступную сборщику мусора: структуры среды выполнения, связанные с каждым подключением (состояние взаимодействия с нативным кодом, метаданные отслеживания подключения), а также буферы отправки TCP ядра, которые постепенно заполнялись обновлениями сущностей и никогда не получали подтверждения доставки. Объём нативной памяти на одно подключение был небольшим, но каждое «зомби» существовало до пяти минут, и в течение этого времени его выделения памяти действовали как своеобразные «якоря» во внутренней куче аллокатора, не позволяя возвращать окружающую их память операционной системе. Буферы транспорта на стороне управляемой памяти (System.IO.Pipelines в Kestrel) использовали пул и могли повторно использоваться, а вот нативные накладные расходы на каждое подключение — нет. Всё это было невидимо для dotnet-dump.

Множитель Redis backplane

Именно здесь работа в Kubernetes добавила ещё один нюанс. Поскольку мы использовали несколько подов, SignalR применял Redis backplane для синхронизации сообщений между ними. Когда один под выполнял широковещательную отправку обновления сущности, он публиковал сообщение в Redis, после чего каждый под получал его и доставлял своим локально подключённым клиентам — включая свои «зомби»-подключения.

Это означало, что одно изменение сущности затрагивало не только «зомби» на одном поде. Оно проходило через Redis и достигало «зомби» на каждом поде. Каждый под поддерживал собственный набор «зомби»-подключений, каждое из которых имело собственные накладные расходы на нативную память. Кроме того, сам Redis backplane создавал дополнительную нагрузку. StackExchange.Redis использует управляемые буферы для операций чтения и записи, однако увеличение объёма публикаций и подписок (pub/sub), вызванное рассылкой сообщений «зомби»-подключениям, приводило к ещё более интенсивным выделениям памяти через нативный аллокатор при обработке каждого сообщения средой выполнения.

При работе трёх подов мы имели дело уже не с одной армией «зомби», а с тремя, и все они получали одни и те же сообщения из потока Redis.

Усугубляющий фактор
Каждое изменение сущности отправляло новые данные в буферы отправки TCP ядра каждого зомби-подключения и продолжало удерживать его нативное состояние подключения во внутренней куче аллокатора. «Зомби», существовавший пять минут, за это время накапливал в своём буфере отправки ядра все широковещательные сообщения. Поскольку сущности изменялись каждые несколько секунд, объём памяти ядра, приходившийся на каждое «зомби», непрерывно рос. И чем дольше существовало «зомби», тем сильнее обычные выделения памяти перемешивались вокруг удерживаемых им нативных структур.

Ловушка фрагментации

Обнаружение «зомби» объяснило, куда уходила память. Но это не объяснило, почему она никогда не возвращалась, даже после периодов затишья, когда все «зомби» были удалены. Чтобы разобраться, мне пришлось спуститься ещё на один уровень — ниже .NET, ниже Kestrel, к самому аллокатору памяти Linux.

Что такое glibc и почему разработчику на C# это должно быть интересно?

Когда ваше .NET-приложение работает под Linux, оно не взаимодействует с операционной системой напрямую. Между средой выполнения .NET и ядром Linux находится базовая библиотека под названием glibc (библиотека GNU C). Вы, вероятно, никогда об этом не задумывались, но она присутствует в каждом стандартном образе контейнера Docker для .NET, незаметно обрабатывая низкоуровневые процессы: файловый ввод-вывод, многопоточность, работу с сетью и — что наиболее важно в данном случае — выделение памяти.

Каждый раз, когда чему-либо внутри процесса требуется память, не управляемая сборщиком мусора .NET, в конечном итоге вызывается malloc(), обработкой которого занимается glibc. Когда эта память больше не нужна, free() возвращает её glibc. Драйвер базы данных, внутренние структуры среды выполнения .NET, слой взаимодействия Kestrel с нативным кодом — все они используют glibc для работы с нативной памятью. Можно представить glibc как арендодателя памяти для всего, что не находится в управляемой куче.

Специализированный аллокатор памяти внутри glibc называется ptmalloc2. Он был разработан в начале 2000-х годов как универсальный аллокатор и основывается на определённых предположениях о том, как приложения используют память. Эти предположения вполне разумны для короткоживущих программ, но перестают работать в случае современного сервера ASP.NET Core, который обслуживает сотни WebSocket-подключений внутри контейнера, никогда не перезапускающегося.

Порог, который нас погубил

Каждое выделение нативной памяти в процессе — взаимодействие среды выполнения с нативным кодом, временные объекты сериализации JSON, операции драйвера базы данных, управление жизненным циклом подключений — проходит через malloc(). Все эти выделения невелики — каждое значительно меньше 128 КБ. И именно в этом заключается проблема.

У функции ptmalloc2 есть внутренний порог — по умолчанию 128 КБ — который определяет способ выделения памяти. Это самая важная деталь во всей этой истории:

Выделения памяти свыше 128 КБ получают от операционной системы собственный выделенный блок памяти (с помощью механизма mmap()). Представьте, что вы арендуете отдельное хранилище. Когда оно больше не нужно, вы возвращаете ключи, и операционная система сразу освобождает эту память. Всё просто и без остатка.

Выделенные объемы памяти менее 128 КБ аллокатора — в растущие области памяти, которыми аллокатор управляет самостоятельно (основная область расширяется через brk(), а дополнительные области потоков выделяют собственные области с помощью mmap()). Представьте себе место на общем хранилище. Когда вы вызываете free(), аллокатор лишь помечает этот участок памяти как доступный для повторного использования. Но здесь есть критически важный момент: ОС не получает эту память обратно. С точки зрения операционной системы процесс по-прежнему её использует. Она продолжает учитываться в RSS. Kubernetes тоже продолжает её учитывать.

Вот ключевая мысль: сами выделения памяти, связанные с «зомби»-подключениями, были недостаточно велики, чтобы заполнить 3,5 ГБ. Несколько килобайт нативных накладных расходов на подключение, умноженные на 3 000 «зомби», — это всего около 10–20 МБ реально используемых данных. Но эти выделения существовали по пять минут каждое и были разбросаны по всей куче. За это время все остальные выделения нативной памяти в процессе — сериализация JSON, чтение из базы данных, создание и завершение подключений исправных клиентов — попадали в те же самые области, чередуясь с памятью «зомби». Когда «зомби» наконец завершался, освободившиеся участки оставляли после себя «дыры», фрагментировавшие кучу. Содержимым этих 3,5 ГБ были вовсе не «зомби». Они были теми самыми «якорями», которые не позволяли куче когда-либо снова уменьшиться.

Несколько слов о том, что мы могли и чего не могли наблюдать: во время первоначального инцидента у нас не было включено трассирование malloc() — в условиях реальной производственной среды невозможно инструментировать внутренние механизмы libc. Точный профиль распределения нативных ресурсов был восстановлен на основе того, что мы смогли измерить (RSS, размер управляемой кучи, количество подключений, память cgroup) и что мы смогли проверить (jemalloc устранил удержание памяти, тем самым доказав, что причиной была фрагментация в ptmalloc2). Конкретное взаимодействие между внутренними вызовами malloc() среды выполнения и жизненным циклом «зомби»-подключений — это наша наиболее вероятная модель того, почему всё происходило именно так. Она была построена на основе наблюдавшихся симптомов, внесённых исправлений и тех частей стека, которые были нам доступны. Когда вы отлаживаете проблему, проходящую через уровни, которыми не управляете, — среду выполнения .NET, Kestrel, glibc, ядро Linux, — именно так и выглядит реальность системной разработки.

Арены: почему потоки ухудшают ситуацию

В ptmalloc2 есть ещё одно архитектурное решение, которое усугубило нашу проблему. Чтобы уменьшить конкуренцию, когда нескольким потокам одновременно требуется память, он выделяет каждому потоку свой собственный отдельный пул памяти — так называемую арену. В системе с 8 ядрами ЦП он может создать до 64 арен. Идея вполне разумна: потоки не блокируют друг друга при выделении памяти.

Проблема заключается в том, что арены не могут совместно использовать свободную память. Представьте их как отдельные склады. Если на складе A есть свободные полки, а склад B переполнен, склад B не может воспользоваться свободным местом склада A — ему приходится расширяться. Kestrel использует пул потоков, а подключения в течение своего жизненного цикла могут обслуживаться разными потоками. «Зомби»-подключение могло получить свои нативные структуры в арене 1, затем обслуживаться потоком, использующим арену 3, а после завершения оставить «дыры» сразу в обеих аренах, которыми ни одна из них не могла поделиться с другой.

Схема выделения памяти выглядела следующим образом:

# Thread pool thread 1 → arena 1
Handles connection A, native allocations: interop + state + metadata
Handles connection B, native allocations: interop + state + metadata

# Connection A goes zombie — lives for minutes, pinning its allocations
# Meanwhile, normal churn (serialization, DB, HTTP) fills around it
Arena 1:  [churn] [A: pinned] [churn] [B: alive] [churn]
# Connection A finally times out and is freed
Arena 1:  [churn] [hole] [churn] [B] [churn]
# Repeat thousands of times across dozens of arenas
# → Heap only grows. RSS never returns.

Жизненный цикл «зомби-подключений» был наихудшим из возможных вариантов для этого аллокатора. Долгое существование «зомби» (до пяти минут) приводило к тому, что их память глубоко перемешивалась с памятью исправных подключений. Когда «зомби» наконец умирал, освобожденная память представляла собой швейцарский сыр — разбросанные дыры по множеству областей, которые можно было повторно использовать для запросов того же или меньшего размера, но которые никогда нельзя было вернуть в операционную систему.

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

Именно поэтому всё выглядело как утечка памяти, хотя с технической точки зрения каждому вызову malloc() соответствовал вызов free(). С точки зрения приложения память была освобождена. Но операционная система так её обратно и не получила.

Ещё одним уровнем ниже

Фрагментация аллокатора объясняла, почему освобождённая память не возвращалась операционной системе. Но существовал ещё один уровень накопления нативной памяти, который был ещё менее заметен: буферы отправки TCP, управляемые ядром Linux.

Когда приложение отправляет данные через сетевой сокет, они не попадают сразу в сеть. По пути они проходят через несколько буферов. В нашем случае сериализованные данные сущности проходили из .NET в буферы канала ввода-вывода Kestrel, а затем попадали в буфер, которым для каждого TCP-сокета управляет ядро Linux. Именно ядро отвечает за фактическую передачу байтов по сети, повторную отправку потерянных пакетов и ожидание подтверждений от другой стороны.

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

Эти буферы находятся в пространстве ядра — памяти, которой управляет сама операционная система и которая полностью находится за пределами адресного пространства процесса. Ни один инструмент диагностики на уровне приложения не может их увидеть. Их не видит dotnet-dump. Их не видит LLDB. Их не видит pmap — их вообще нет в виртуальном адресном пространстве процесса. Но они учитываются системой учёта памяти cgroup ядра. Их видит Kubernetes. Их видит OOM-killer.

При пятиминутном тайм-ауте KeepAlive ядро удерживало буфер отправки каждого «зомби»-подключения на протяжении всего этого времени. Размер таких буферов обычно составляет от 64 КБ до 4 МБ на сокет — в зависимости от объёма данных в очереди и настроек системы.

# Estimated kernel memory from zombies:
2,000 zombie connections × ~1MB TCP send buffer = ~2GB in kernel space
# Completely invisible to any application-level diagnostic

Почему Kubernetes усугубил ситуацию

В Kubernetes каждый под работает внутри изолированной среды (cgroup), которую ядро Linux использует для учёта и ограничения потребления ресурсов контейнером. Метрика памяти, за которой следит Kubernetes, включает всё: управляемую кучу, фрагментированную нативную кучу, удерживаемую аллокатором, и все буферы TCP ядра, принадлежащие «зомби»-сокетам. Она не различает «память, которую код действительно использует» и «память, которую аллокатор удерживает, но не использует».

Мы используем Horizontal Pod Autoscaler (HPA) — механизм Kubernetes, который автоматически увеличивает или уменьшает количество реплик подов на основании метрик использования ресурсов. Когда поды начинали потреблять слишком много памяти, HPA масштабировал систему: больше подов, больше вычислительных ресурсов, выше стоимость. Но здесь возникла проблема: каждый новый под, присоединившийся к кластеру, сразу начинал получать широковещательные сообщения через Redis backplane и принимать повторные подключения мобильных клиентов. Уже через несколько минут у нового пода появлялась собственная армия «зомби». HPA масштабировал систему, пытаясь решить проблему памяти, но каждый новый под только усугублял эту проблему.

Но когда нагрузка снижалась, RSS подов так и не уменьшался. Управляемая куча сокращалась — сборщик мусора выполнял свою работу. Буферы TCP ядра освобождались после закрытия «зомби»-сокетов. Но фрагментированная нативная куча, которую продолжал удерживать аллокатор, сохраняла высокий RSS. Память, которая действительно использовалась во время пиковых нагрузок, оставляла после себя множество пустых участков, которые операционная система уже не могла вернуть себе. HPA видел, что поды по-прежнему потребляют значительно больше памяти, чем необходимые им 600 МБ, и больше не уменьшал количество реплик.

Мы платили за призрачную память — пустые фрагменты арен, которые операционная система не могла освободить, сборщик мусора не мог затронуть, а Kubernetes не мог отличить от реально используемой памяти. Поды, которым было достаточно 600 МБ, оставались раздутыми из-за фрагментированной нативной кучи, а HPA исправно продолжал поддерживать их работу.

Полный каскад
Нестабильные мобильные соединения (в нашем собственном офисном подвале) → «зомби»-подключения SignalR, существующие несколько минут → Redis backplane рассылает обновления заявок «зомби»-подключениям на каждом поде → нативные выделения памяти для каждого подключения попадают в общую кучу вместо выделения отдельных областей памяти → фрагментация аллокатора между потоками пула → буферы отправки TCP ядра для «мёртвых» сокетов → объём памяти cgroup вырастает до 4 ГБ → завершение пода из-за нехватки памяти (OOM) → перезапуск пода → клиенты автоматически переподключаются через три секунды → HPA масштабирует систему → новые поды получают ту же самую армию «зомби» → цикл повторяется.

Неделя 3: Исправление каждого слоя

Единого решения не существовало. Проблема существовала на каждом уровне, и для каждого уровня требовалось своё собственное решение.

Уровень 1: Быстрее избавляться от «зомби»

Наиболее значимым изменением стало сокращение тайм-аута SignalR с пяти минут до десяти секунд. Только это изменение уменьшило максимально возможное время существования «зомби»-подключения на 97%.

var hubConfig = services.AddSignalR(options =>
{
    options.ClientTimeoutInterval = TimeSpan.FromSeconds(10);
    options.KeepAliveInterval = TimeSpan.FromSeconds(7);
    options.MaximumReceiveMessageSize = 32 * 1024;
    options.HandshakeTimeout = TimeSpan.FromSeconds(15);
    options.StreamBufferCapacity = 10;
    options.MaximumParallelInvocationsPerClient = 1;
    options.StatefulReconnectBufferSize = 0;
});

Наши прежние значения не были случайными. Мы установили ClientTimeoutInterval равным пяти минутам, чтобы быть более терпимыми к мобильным клиентам, работающим через нестабильные сотовые сети. В документации Microsoft рекомендуется оставлять достаточный запас времени для получения ping-пакетов в сетях с высокой задержкой, и мы решили выбрать более безопасный вариант. Параметр MaximumReceiveMessageSize был увеличен до 128 КБ, чтобы иметь запас для команд, отправляемых клиентом в Hub (JoinGroup, GetData и аналогичных запросов на получение данных), хотя их размер редко превышал несколько сотен байт. На первый взгляд оба решения выглядели вполне разумными. Однако в нестабильных мобильных сетях с «тихими» разрывами соединения такой тайм-аут оказался катастрофическим, а увеличенный буфер приёма означал, что входной канал каждого «зомби»-подключения резервировал значительно больше памяти, чем ему когда-либо требовалось.

Параметр StatefulReconnectBufferSize тоже заслуживает отдельного пояснения. Эта возможность появилась в .NET 8 и хранит буфер для каждого подключения, чтобы клиент мог восстановить соединение после кратковременного разрыва, не потеряв сообщения. Звучит идеально для нестабильных соединений. Но 60% наших отключений происходили из-за переключения между сетями, при котором создаётся совершенно новое TCP-соединение. В таких случаях этот буфер никак не помогал. Мы расходовали примерно 10–17 МБ памяти на функцию, которая не приносила никакой пользы в нашей рабочей нагрузке.

Уровень 2: Уменьшить масштаб последствий

В нашем ALB (Application Load Balancer) тайм-аут бездействия составлял 3 600 секунд — один час. Он был увеличен по сравнению со стандартным значением AWS, равным 60 секундам, чтобы балансировщик нагрузки не закрывал долгоживущие WebSocket-подключения. Неактивные HTTP-соединения оставались открытыми в течение часа, удерживая нативную память. Мы вернули тайм-аут к 60 секундам и установили для Kestrel значение KeepAliveTimeout, равное 70 секундам (всегда немного больше тайм-аута ALB, чтобы избежать ошибок 502 Bad Gateway).

# Kestrel (defaults: KeepAliveTimeout=130s, MaxConcurrentConnections=unlimited,
#          MaxConcurrentUpgradedConnections=unlimited)
options.Limits.KeepAliveTimeout = TimeSpan.FromSeconds(70);
options.Limits.MaxConcurrentConnections = 550;
options.Limits.MaxConcurrentUpgradedConnections = 350;

# ALB (default idle timeout is 60s; ours was set to 3600s for WebSocket longevity)
Connection idle timeout: 60
HTTP client keepalive:   65

Уровень 3: Исправить конвейер потоковой передачи

Наш SystemWaStreamNotifier обрабатывал изменения сущностей каждые две секунды с помощью очереди, управляемой таймером. Но без устранения дубликатов одна и та же сущность могла неоднократно попадать в очередь и обрабатываться повторно при быстром поступлении изменений. Больше обработки означало больше чтений из базы данных, больше сериализации и больше данных, отправляемых в буферы «зомби»-подключений.

Мы добавили глобальное устранение дубликатов с помощью ConcurrentDictionary. Если сущность App123 уже ожидала обработки, последующие обновления лишь обновляли отметку времени — новый элемент в очередь не добавлялся. Во время пиковых нагрузок количество операций обработки сократилось на 60–80%.

Уровень 4: Заменить аллокатор

Все перечисленные выше изменения уменьшили скорость накопления нативной памяти. Но фрагментация аллокатора glibc является следствием самой архитектуры — она заложена в принципах работы ptmalloc2. Даже при сокращении времени жизни «зомби»-подключений куча всё равно продолжала бы фрагментироваться с течением дней и недель. Просто медленнее.

Окончательным решением проблемы фрагментации стала полная замена стандартного аллокатора glibc. Для этого потребовалась всего одна строка в нашем Dockerfile:

FROM mcr.microsoft.com/dotnet/aspnet:8.0

RUN apt-get update && \
    apt-get install -y libjemalloc2 && \
    rm -rf /var/lib/apt/lists/*
ENV LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2

LD_PRELOAD — это переменная окружения Linux, которая указывает системе загрузить разделяемую библиотеку раньше всех остальных. Если указать в ней библиотеку jemalloc, каждый вызов malloc() и free() во всём процессе — от среды выполнения .NET до драйвера MySQL и любых других нативных библиотек — будет выполняться через jemalloc вместо стандартного аллокатора glibc. Никаких изменений в коде. Никакой повторной компиляции. Само приложение даже не знает, что использует другой аллокатор.

jemalloc был создан именно для такого типа нагрузки — долгоживущих серверов с большим количеством одновременных выделений памяти разного размера, выполняемых из множества потоков. Именно его используют Redis, Meta и Firefox в продакшене. Вместо отдельных арен для каждого потока с фрагментированными списками свободных блоков jemalloc организует память по классам размеров (size-class bins), которые можно представить как заранее отсортированные полки для объектов разных размеров, и активно сообщает операционной системе о возможности освободить неиспользуемые страницы памяти. Для этого используется системный вызов madvise, который фактически говорит ядру: «Эта страница памяти мне больше не нужна — можешь забрать её обратно, но оставь резервирование адресного пространства на случай, если она снова понадобится». В результате освобождённая память действительно приводит к уменьшению RSS.

Несколько слов о компромиссах при использовании jemalloc
jemalloc — не волшебная палочка. Его агрессивная очистка страниц памяти требует немного больше процессорного времени, чем аллокатор glibc, — ядру приходится выполнять больше работы по освобождению и повторному отображению страниц памяти. Некоторые средства мониторинга могут показывать непривычную картину использования памяти, поскольку внутренний механизм учёта jemalloc отличается от того, чего ожидают эти инструменты. Кроме того, это ещё одна зависимость: её необходимо установить в Docker-образ и своевременно обновлять. Следует также отметить, что темпы развития jemalloc в последние годы снизились после того, как Meta сократила объём инвестиций в проект. Тем не менее стабильные ветки продолжают получать исправления, а jemalloc по-прежнему остаётся аллокатором по умолчанию в FreeBSD. Для нашей рабочей нагрузки компромисс был очевиден — мы расходовали гигабайты оперативной памяти ради экономии нескольких процессорных циклов на управлении страницами памяти. Но прежде чем принимать такое решение, всегда следует проводить тестирование на собственной рабочей нагрузке.

Почему не другой аллокатор?

jemalloc был не единственным вариантом. Мы рассматривали две альтернативы, но в итоге отказались от них.

gperftools tcmalloc (Google) — оптимизирован для быстрого выделения небольших объектов за счёт использования кэшей потоков. Хорошо показывает себя при умеренном количестве потоков, однако его центральные списки свободных блоков и общий пул страниц не разделены между потоками, что может стать узким местом при интенсивном выделении памяти из разных потоков. Это не соответствовало профилю нашей системы — сервера ASP.NET Core с активным использованием пула потоков и высокой интенсивностью создания и завершения подключений.

mimalloc (Microsoft Research) — компактный высокопроизводительный аллокатор с превосходными результатами в тестах производительности. Однако в архитектуре версии 2 используются отдельные пулы памяти для каждого потока, и память намеренно не передаётся между потоками — память, освобождённая одним потоком, остаётся зарезервированной именно за ним. Для пула потоков с постоянно меняющейся нагрузкой это хорошо известный путь к накоплению памяти. Отличный выбор, если важна максимальная скорость выделения памяти, но неподходящий вариант для наших контейнеров с жёсткими ограничениями по памяти.

jemalloc оказался лучшим выбором благодаря своей зрелости и соответствию нашей задаче. Он появился в 2005 году как аллокатор libc для FreeBSD, что делает его самым старым из рассматриваемых альтернатив, проверенных в реальных условиях эксплуатации. С тех пор он прошёл испытание экстремальными нагрузками в Redis, Meta и Firefox. Окончательно выбор определили особенности его архитектуры: множество арен с возможностью совместного использования памяти между потоками, классы размеров, минимизирующие фрагментацию, и активный возврат неиспользуемых страниц операционной системе с помощью madvise. Для долгоживущего сервера с высокой интенсивностью создания и завершения подключений, сообщениями переменного размера и жёсткими ограничениями памяти контейнеров именно такое сочетание возможностей оказалось тем, что нам было нужно.

После

Использование памяти подами стабилизировалось на уровне менее 1 ГБ. Завершения из-за нехватки памяти (OOM) прекратились. HPA впервые начал уменьшать количество реплик. Перезапуски в середине рабочего дня прекратились.

Напомню — это был предпусковой пилотный запуск. 200 устройств, половина из которых принадлежала нашим собственным специалистам по сопровождению, пытавшимся работать при плохом сигнале в подвале офиса. Три недели мы не могли выйти в production, потому что эта проблема приводила к завершению каждого пода, который мы запускали. Через неделю после внедрения исправлений мы выполнили полноценный запуск системы. Система, которая не могла выдержать нагрузку от 200 пользователей во время пилотного запуска, теперь работает в промышленной эксплуатации без единого завершения из-за нехватки памяти (OOM).

Три недели мы каждую ночь развёртывали исправления, а днём наблюдали, как они не дают результата, — и всё из-за ошибки, которую не мог обнаружить ни один инструмент диагностики .NET. Но за эти три недели я узнал о том, как программное обеспечение на самом деле работает в Linux, больше, чем за несколько предыдущих лет разработки на C#.

Почему production ни разу не остановился

Три недели поды завершались из-за нехватки памяти каждые несколько часов, и при этом не произошло ни одного сбоя, заметного пользователям. Это было не везение, а результат трёх уровней защиты, которые мы реализовали ещё до того, как поняли первопричину проблемы: readiness probe, исключавшей под из балансировщика нагрузки при достижении 80% использования памяти (при этом существующие подключения продолжали обслуживаться), liveness probe, принудительно перезапускавшей под, если использование памяти слишком долго оставалось выше 93%, и SmartMemoryTrimService, который агрессивно запускал GC.Collect() с уплотнением Large Object Heap (LOH), чтобы удерживать управляемую кучу под контролем. Ключевой вывод заключался в следующем: к тому моменту, когда под приближался к завершению из-за нехватки памяти (OOM), он уже был исключён из production-трафика и обслуживал только «зомби»-подключения. Поэтому даже если происходило завершение из-за OOM, пользователи этого не замечали.

Побочным эффектом стали затраты. Поды, которые были работоспособны, но не готовы к работе, поддерживали максимальное количество реплик HPA. Мы платили за стабильность инфраструктурными затратами — именно тот компромисс, который необходим, пока вы ищете первопричину проблемы.

Чему меня научили три недели без сна

Большинству .NET-разработчиков никогда не приходится задумываться о нативной памяти. Управляемая куча, сборщик мусора, IDisposable — все эти абстракции настолько хорошо работают, что можно построить целую карьеру, так и не узнав, как операционная система выделяет память под средой выполнения. До тех пор, пока ваше приложение не начинает работать в контейнерах Linux с WebSocket-подключениями от мобильных устройств, находящихся в нестабильных сетях, — и тогда оказывается, что эта абстракция имеет свои пределы.

dotnet-dump видит только половину картины. Если в Linux растёт RSS, а размер управляемой кучи остаётся неизменным, значит проблема находится в нативной памяти, и dotnet-dump её не увидит. Для анализа дампов потребуется LLDB, а для просмотра областей памяти работающего процесса — pmap. Быстрый способ диагностики — запустить dotnet-counters и следить за двумя показателями: GC Heap Size и Working Set. Если Working Set продолжает расти, а GC Heap Size остаётся стабильным, значит проблема находится в нативной памяти. Инструменты .NET будут утверждать, что всё в порядке, в то время как Kubernetes уже готовится завершить ваш под из-за нехватки памяти.

Стандартный аллокатор памяти Linux не рассчитан на подобную рабочую нагрузку. ptmalloc2 из glibc — это универсальный аллокатор, разработанный в эпоху, когда ещё не существовало контейнеров, WebSocket и пулов потоков, обслуживающих сотни одновременных подключений в долгоживущих процессах. Он исходит из того, что большинство приложений работают недолго, характер использования памяти достаточно предсказуем, а куча может свободно расти благодаря практически неограниченной виртуальной памяти. В контейнере с лимитом памяти 4 ГБ, внутри которого работает сервер, никогда не перезапускающийся, все эти предположения перестают быть верными. Если вы запускаете долгоживущий сервис ASP.NET Core в Linux, добавление LD_PRELOAD=libjemalloc.so в Dockerfile должно стать такой же привычной практикой, как установка DOTNET_gcServer=1. И это касается не только .NET — Rust, Node.js, Python и любой другой язык, использующий malloc(), в той или иной степени может столкнуться с той же проблемой в glibc.

Значения тайм-аутов SignalR по умолчанию рассчитаны на стабильные сети, а их увеличение ради лучшей поддержки мобильных клиентов только усугубляет ситуацию. Мы установили ClientTimeoutInterval равным пяти минутам, полагая, что это поможет клиентам с нестабильным соединением. Вместо этого мы создали целую армию «зомби». Если ваши клиенты работают через мобильные сети, уменьшайте это значение, а не увеличивайте. Устанавливайте ClientTimeoutInterval максимально агрессивно. Ваши клиенты уже умеют автоматически переподключаться.

Граница в 128 КБ имеет значение. В Linux стандартный аллокатор совершенно по-разному обрабатывает выделения памяти меньше и больше 128 КБ. В долгоживущем сервере все нативные выделения памяти — взаимодействие среды выполнения с нативным кодом, сериализация, управление подключениями — оказываются ниже этого порога и попадают в общую кучу, которая никогда не уменьшается. Долгоживущие подключения становятся источниками фрагментации, не позволяющими уменьшить размер кучи даже после закрытия этих подключений.

Искусственный интеллект — это инструмент, многократно повышающий эффективность работы, а не замена инженерному мышлению. Я активно использовал Claude — как помощника для исследований, а не как непререкаемый источник истины. Он помог мне разобраться в механизме арен ptmalloc2, оценить объём памяти, занимаемой «зомби»-подключениями, проанализировать компромиссы при выборе настроек буферов и обратить внимание на альтернативные аллокаторы, о которых я раньше не задумывался. Но он ошибался не реже, чем был прав. Я тратил столько же времени на проверку его гипотез, сколько и на их использование: уточнял оценки памяти, опровергал предположения о работе буферов и заставлял его согласовывать выводы с тем, что показывали реальные метрики production. Направление задавало понимание системы. Скорость обеспечивал помощник, который в рамках одной беседы мог переключаться от внутреннего устройства ядра Linux к особенностям работы SignalR.

«Самые сложные ошибки находятся не в вашем коде. Они скрываются в предположениях, которые платформа делает о том, как этот код должен работать.»

Хронология

Если вы используете ASP.NET Core в контейнерах Linux с подключениями в режиме реального времени, проверьте объём нативной памяти. Запустите dotnet-counters и сравните GC Heap Size с Working Set. Если Working Set продолжает расти, а GC Heap Size остаётся стабильным, проблема находится в нативной памяти — за пределами области, которую контролирует сборщик мусора. Путь к её устранению начинается с понимания того, где на самом деле находится память вашего приложения.

Перевод оригинальной статьи OpenTelemetry Filelog Receiver: A Guide to Ingesting Log Files.

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

Получатель filelog в OpenTelemetry Collector позволяет интегрировать эти логи в современный конвейер наблюдаемости. Он непрерывно отслеживает файлы, анализирует их содержимое и преобразует необработанный текст в структурированные записи журналов OpenTelemetry.

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

Прежде чем углубляться: если вы контролируете приложения, записывающие эти логи, наилучшим решением будет настроить их на вывод структурированных JSON-логов, размещённых в одной строке. Чтобы получатель filelog в этом случае стал простым и удобным уровнем приема данных.

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

Начнём!

Как работает получатель filelog

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

1. Обнаружение (Discover): получатель через заданные интервалы времени сканирует файловую систему, используя настроенные шаблоны include and exclude, чтобы определить, какие файлы логов необходимо отслеживать.
2. Чтение (Read): после обнаружения файла получатель открывает его и начинает отслеживать появление новых строк. Параметр start_at определяет, следует ли начинать чтение с beginning или отслеживать только новые данные, начиная с end.
3. Разбор (Parse): каждая строка (или блок строк, если используется разбор многострочных записей) проходит через последовательность операторов Stanza(если они настроены). Эти операторы разбирают необработанный текст, извлекают ключевые атрибуты, назначают временные метки и уровни критичности, а затем формируют структурированные данные логов.
4. Передача (Emit) в завершение структурированные записи логов передаются в конвейер OpenTelemetry Collector, где они могут быть отфильтрованы, дополнительно преобразованы или экспортированы в серверную часть.

Цикл Discover -> Read -> Parse -> Emit лежит в основе всего сбора данных.

Быстрый старт: отслеживание файла логов

Одним из наиболее распространённых сценариев является ситуация, когда приложение уже записывает логи в формате JSON в файл. Например, представим сервис, который записывает JSON-логи в файл /var/log/myapp/app.log:

json

{"time":"2025-09-28 20:15:12","level":"INFO","message":"User logged in successfully","user_id":"u-123","source_ip":"192.168.1.100"}
{"time":"2025-09-28 20:15:45","level":"WARN","message":"Password nearing expiration","user_id":"u-123"}

Ниже приведён минимальный пример настройки получателяfilelog, который считывает такие логи и передаёт их в конвейер OpenTelemetry.

# otelcol.yaml
receivers:
  filelog:
    # 1. DISCOVER all .log files in /var/log/myapp/
    include: [/var/log/myapp/*.log]
    # 2. READ from the beginning of new files
    start_at: beginning
    # 3. PARSE using the json_parser operator
    operators:
      - type: json_parser
        # Tell the parser where to find the timestamp and how it's formatted
        timestamp:
          parse_from: attributes.time
          layout: "%Y-%m-%d %H:%M:%S"
        # Tell the parser which field contains the severity
        severity:
          parse_from: attributes.level

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    logs:
      receivers: [filelog]
      exporters: [debug]

Ниже приведено объяснение приведённой выше конфигурации.

• include: указывает получателю все файлы .log в каталоге /var/log/myapp/.
• start_at: beginning: гарантирует, что при первом обнаружении файла получатель обработает его полностью. По умолчанию используется значение end, при котором будут считываться только новые строки, записанные после запуска Collector.
• operators: в данном случае он всего один: json_parser. Его задача заключается в том, чтобы интерпретировать каждую строку лога как JSON, а затем перенести выбранные поля в основную метаинформацию записи лога.
• timestamp и severity: внутри json_parser из JSON извлекаются поля time и level и преобразуются в поля верхнего уровня OpenTelemetry Timestamp и Severity для каждой записи лога.

При использовании экспортёра debug вы увидите разобранный и структурированный результат. Вместо простого необработанного JSON каждое поле теперь будет корректно представлено внутри записи лога:

LogRecord #0
ObservedTimestamp: 2025-09-28 20:48:36.728437503 +0000 UTC
Timestamp: 2025-09-28 20:15:12 +0000 UTC
SeverityText: INFO
SeverityNumber: Info(9)
Body: Str({"time":"2025-09-28 20:15:12","level":"INFO","message":"User logged in successfully","user_id":"u-123","source_ip":"192.168.1.100"})
Attributes:
     -> user_id: Str(u-123)
     -> source_ip: Str(192.168.1.100)
     -> log.file.name: Str(myapp.log)
     -> time: Str(2025-09-28 20:15:12)
     -> level: Str(INFO)
     -> message: Str(User logged in successfully)
Trace ID:
Span ID:
Flags: 0

Теперь необработанные JSON-логи преобразованы в унифицированный формат данных логов OpenTelemetry, что обеспечивает единообразную основу для наблюдаемости в различных системах.

Атрибут log.file.name по умолчанию автоматически добавляется получателем. Кроме того, можно включить параметр include_file_path, чтобы также сохранять полный путь к файлу.

# otelcol.yaml
receivers:
  filelog:
    include: [/var/log/myapp/*.log]
    include_file_path: true

Это позволяет легко фильтровать или выполнять поиск логов по их точному пути.

Attributes:
     -> log.file.path: Str(/var/log/myapp/app.log)
     -> log.file.name: Str(app.log)

Дополнительные возможности обогащения данных описаны в официальной документации OpenTelemetry Filelog Receiver.

Фильтрация и управление файлами логов

Наиболее важным шагом в настройке настройке получателя filelog является указание того, какие файлы необходимо отслеживать. Это настраивается с помощью шаблонов include и exclude.

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

Пример:

# otelcol.yaml
receivers:
  filelog:
    include: [/var/log/apps/**/*.log]
    exclude:
      - /var/log/apps/**/debug.log
      - /var/log/apps/**/*.tmp

В данном случае получатель будет собирать все файлы .log в каталоге /var/log/apps/, включая все вложенные каталоги, но пропустит любой файл с именем debug.log, а также любой файл с расширением .tmp.

Исключение файлов по времени последнего изменения

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

# otelcol.yaml
receivers:
  filelog:
    include: [/var/log/myapp/*.log]
    exclude_older_than: 24h
    start_at: beginning

В этом примере, даже если файл app-2025-07-15.log соответствует шаблону, он будет пропущен, если не изменялся в течение последних 24 часов.

Разбор неструктурированного текста с помощью регулярных выражений

Большинство инфраструктурных логов не записываются в аккуратном формате JSON. Гораздо чаще они представляют собой обычный текст, соответствующий некоторому шаблону, например логи доступа веб-сервера, логи запросов к базе данных или сообщения операционной системы. Такие логи легко читаются человеком, но их сложно анализировать автоматически, пока им не будет придана структура.

Для решения этой задачи Collector предоставляет оператор regex_parser. Используя регулярные выражения с именованными группами захвата, вы можете разбить исходную строку лога на осмысленные поля и преобразовать их в структурированные атрибуты.

Например, рассмотрим лог доступа NGINX в в формате Common Log Format.

127.0.0.1 - - [28/Sep/2025:20:30:00 +0000] "GET /api/v1/users HTTP/1.1" 200 512
127.0.0.1 - - [28/Sep/2025:20:30:05 +0000] "POST /api/v1/login HTTP/1.1" 401 128

Для преобразования таких записей в структурированные атрибуты можно настроить regex_parser следующим образом.

# otelcol.yaml
receivers:
  filelog:
    include: [/var/log/nginx/access.log]
    start_at: beginning
    operators:
      - type: regex_parser
        # Use named capture groups to extract data
        regex:
          '^(?P<client_ip>[^ ]+) - - \[(?P<timestamp>[^\]]+)\]
          "(?P<http_method>[A-Z]+) (?P<http_path>[^ "]+)[^"]*"
          (?P<status_code>\d{3}) (?P<response_size>\d+)$'
        # Parse the extracted timestamp
        timestamp:
          parse_from: attributes.timestamp
          layout: "%d/%b/%Y:%H:%M:%S %z"
        # Map status codes to severities
        severity:
          parse_from: attributes.status_code
          mapping:
            info:
              - min: 200
                max: 399
            warn: 4xx
            error: 5xx

В основе данной конфигурации лежит регулярное выражение regex с именованными группами захвата. Каждая группа выделяет определённую часть строки, чтобы анализатор мог преобразовать её в атрибут. Группа client_ip извлекает IP-адрес клиента, timestamp — временную метку в квадратных скобках, http_method и http_path — HTTP-метод и путь запроса, status_code — трёхзначный код ответа, а response_size — размер ответа в байтах.

После создания этих атрибутов параметр timestamp преобразует строковое значение timestamp в корректное значение даты и времени, а блок severity преобразует коды состояния в соответствующие уровни критичности с помощью явного сопоставления (mapping): ответы 2xx и 3xx становятся уровнем INFO, ответы 4xx — уровнем WARN, а ответы 5xx — уровнем ERROR.

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

LogRecord #0
ObservedTimestamp: 2025-09-28 21:17:42.31729069 +0000 UTC
Timestamp: 2025-09-28 20:30:00 +0000 UTC
SeverityText: 200
SeverityNumber: Info(9)
Body: Str(127.0.0.1 - - [28/Sep/2025:20:30:00 +0000] "GET /api/v1/users HTTP/1.1" 200 512)
Attributes:
     -> status_code: Str(200)
     -> response_size: Str(512)
     -> log.file.name: Str(myapp.log)
     -> client_ip: Str(127.0.0.1)
     -> timestamp: Str(28/Sep/2025:20:30:00 +0000)
     -> http_method: Str(GET)
     -> http_path: Str(/api/v1/users)
Trace ID:
Span ID:
Flags: 0

Используя одно регулярное выражение и несколько этапов разбора, обычный лог доступа NGINX преобразуется в структурированные данные OpenTelemetry. Следующим логичным шагом является приведение полученных атрибутов в соответствие с семантическими соглашениями HTTP с помощью процессоров attributes или transform.

Обработка нескольких форматов логов

Файлы логов редко имеют единый формат. Например, может потребоваться одновременно принимать логи NGINX, логи PostgreSQL и приложения, каждый из которых использует собственный формат.

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

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

# otelcol.yaml
receivers:
  # NGINX access logs
  filelog/nginx_access:
    include: [/var/log/nginx/access.log]
    operators:
      - type: regex_parser
        # ... NGINX access log parsing rules

  # NGINX error logs
  filelog/nginx_error:
    include: [/var/log/nginx/error.log]
    operators:
      - type: regex_parser
        # ... NGINX error log parsing rules

Однако иногда различия встречаются внутри одного и того же файла.

Например, большинство строк могут содержать только простые сообщения, тогда как некоторые дополнительно содержат поле trace_id.

INFO: Application started successfully.
DEBUG: Processing request for trace_id=12345

Вместо создания одного большого регулярного выражения, охватывающего все возможные варианты, можно использовать условные операторы с параметром if.

# otelcol.yaml
receivers:
  filelog:
    include: [/var/log/app.log]
    operators:
      # Parse the basic structure of every line
      - type: regex_parser
        id: base_parser # a unique ID is required when multiple operators of the same type is being used
        regex: '^(?P<severity>\w+): (?P<message>.*)$'

      # Only run this parser when "trace_id" appears
      - type: regex_parser
        id: trace_parser
        if: 'attributes["message"] matches "trace_id"'
        parse_from: attributes.message
        regex: '.*trace_id=(?P<trace_id>\w+).*'

Вот что происходит:

• Первый анализатор выполняется для каждой строки лога и извлекает поля severity и message.
• Второй анализатор выполняется только в том случае, если сообщение содержит trace_id, дополняя запись лога этим дополнительным полем.

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

Обработка стек-трейсов и многострочных логов

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

2025-09-28 21:05:42 [ERROR] Unhandled exception: Cannot read property 'foo' of undefined
TypeError: Cannot read property 'foo' of undefined
    at Object.<anonymous> (/usr/src/app/index.js:15:18)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Module._load (node:internal/modules/cjs/loader:958:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47

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

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

{
  "time": "2025-09-28 21:05:42",
  "level": "ERROR",
  "message": "Unhandled exception: Cannot read property 'foo' of undefined",
  "exception.stacktrace": "TypeError: Cannot read property 'foo' of undefined\n    at Object.<anonymous> (/usr/src/app/index.js:15:18)\n    at Module._compile (node:internal/modules/cjs/loader:1254:14)\n    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)\n    at Module.load (node:internal/modules/cjs/loader:1117:32)\n    at Module._load (node:internal/modules/cjs/loader:958:12)\n    at Function.executeUserEntryPoint [as runMain] (node:internal/main/run_main:81:12)\n    at node:internal/main/run_main_module:17:47"
}

Но если изменить формат логов невозможно, можно использовать приведённую ниже конфигурацию multiline, которая указывает получателю, как объединять несколько строк в одну запись LogRecord.

# otelcol.yaml
receivers:
  filelog:
    include: [/var/log/myapp/*.log]
    start_at: beginning

    multiline:
      # New entry starts when a line begins with "YYYY-MM-DD HH:MM:SS"
      line_start_pattern: ^\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2}

    operators:
      - type: regex_parser
        regex: (?P<timestamp>\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})\s+\[(?P<severity>[A-Za-z]+)\]\s+(?P<message>.+)

        timestamp:
          parse_from: attributes.timestamp
          layout: "%Y-%m-%d %H:%M:%S"

        severity:
          parse_from: attributes.severity

В данном случае параметр line_start_pattern служит точкой привязки. Новая запись лога начинается только тогда, когда строка начинается с даты в формате YYYY-MM-DD HH:MM:SS, а любая строка, не соответствующая этому шаблону, присоединяется к предыдущей записи.

В результате вся трассировка стека — от сообщения об ошибке до каждой строки at ... — будет сохранена как одна структурированная запись лога. Это сохраняет полный контекст события и значительно упрощает анализ и диагностику ошибок.

LogRecord #0
ObservedTimestamp: 2025-10-07 12:04:26.963143642 +0000 UTC
Timestamp: 2025-09-28 21:05:42 +0000 UTC
SeverityText: ERROR
SeverityNumber: Error(17)
Body: Str(2025-09-28 21:05:42 [ERROR] Unhandled exception: Cannot read property 'foo' of undefined
TypeError: Cannot read property 'foo' of undefined
    at Object.<anonymous> (/usr/src/app/index.js:15:18)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Module._load (node:internal/modules/cjs/loader:958:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47)
Attributes:
     -> log.file.name: Str(/var/log/myapp/app.log)
     -> message: Str(Unhandled exception: Cannot read property 'foo' of undefined)
     -> timestamp: Str(2025-09-28 21:05:42)
     -> severity: Str(ERROR)
Trace ID:
Span ID:
Flags: 0

Разбор метаданных из заголовков файлов

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

Такой подход часто используется в пакетных заданиях и процессах экспорта. Например, при ночном запуске процесса выставления счетов может создаваться отдельный файл логов для каждого выполнения. В начале такого файла можно увидеть примерно следующее.

# Job-ID: job-d8e8fca2
# Job-Type: nightly-billing-run
# Executed-By: scheduler-prod-1
# Records-To-Process: 1500
2025-10-08T08:20:00Z INFO: Starting billing run.
2025-10-08T08:21:15Z INFO: Processed account #1.
2025-10-08T08:21:16Z WARN: Account #2 has a negative balance.
. . .

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

Для этого определяется небольшой отдельный конвейер, который выполняется только для начального блока строк файла. Необходимо указать регулярное выражение, определяющее, какие строки относятся к заголовку. Затем metadata_operators разбирают эти строки и преобразуют их в атрибуты, которые автоматически добавляются к каждой последующей записи лога.

Для использования этой функции необходимо выполнить три действия:

1. Включить feature gate filelog.allowHeaderMetadataParsing:

# docker-compose.yml
services:
  otelcol:
    command:
      [
        --config=/etc/otelcol-contrib/config.yaml,
        --feature-gates=filelog.allowHeaderMetadataParsing,
      ]

1. Установить параметр start_at: beginning, поскольку заголовок должен считываться с начала файла.
2. Настроить как правила header, так и основной конвейер operators.

Ниже приведена конфигурация для разбора заголовков из приведённого выше примера файла логов.

# otelcol.yaml
receivers:
  filelog:
    include: [/var/log/jobs/*.log]
    start_at: beginning # required
    header:
      pattern: ^#
      metadata_operators:
        - type: key_value_parser
          delimiter: ": "
          pair_delimiter: "# "

В данной конфигурации происходит следующее.

• Параметр pattern: ^#: указывает, что любая строка, начинающаяся с символа #, относится к заголовку. Затем эти строки передаются в конвейер metadata_operators.
• Оператор key_value_parser разделяет каждую строку заголовка на ключ и значение, используя символ : в качестве разделителя, а # обозначает начало новой пары «ключ-значение».

В результате каждая последующая запись лога получает следующие атрибуты:

Attributes:
     -> Job-ID: Str(job-d8e8fca2)
     -> Job-Type: Str(nightly-billing-run)
     -> Executed-By: Str(scheduler-prod-1)
     -> Records-To-Process: Str(1500)

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

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

Как избежать потери или дублирования логов

При перезапуске Collector процесс приема логов может легко нарушиться, если не сохраняется его состояние. В этом случае существует риск либо повторного приема уже обработанных данных, либо пропуска новых логов. Если используется параметр start_at: beginning, получатель повторно прочитает все файлы логов, что приведёт к массовому дублированию данных. При использовании start_at: end могут быть пропущены записи, появившиеся во время недоступности Collector.

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

Наиболее распространённым способом является использование расширения расширения file_storage.

# otelcol.yaml
extensions:
  file_storage:
    directory: /var/otelcol/storage

receivers:
  filelog:
    include: [/var/log/myapp/*.log]
    start_at: beginning
    # Link the receiver to the storage extension
    storage: file_storage

# ... processors, exporters

service:
  # The extension must be enabled in the service section
  extensions: [file_storage]
  pipelines:
    logs:
      receivers: [filelog]
      # ...

После включения расширения storage получатель будет выполнять следующие действия.

1. При запуске проверять каталог /var/otelcol/storage на наличие сохранённых смещений.
2. Продолжать чтение каждого отслеживаемого файла с ранее сохранённого смещения, гарантируя отсутствие потери и дублирования данных.
3. Периодически обновлять информацию о своём текущем положении в хранилище.

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

Корректная обработка ошибок доставки логов

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

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

Чтобы избежать этого, получатель имеет встроенный механизм повторной отправки неудачно переданных пакетов. Если включить параметр retry_on_failure, получатель приостанавливает работу, ожидает заданный интервал времени и повторяет попытку отправить тот же самый пакет логов. Этот процесс повторяется с использованием экспоненциального увеличения интервала ожидания (exponential backoff) до тех пор, пока пакет не будет успешно отправлен либо пока не будет достигнуто значение max_elapsed_time.

# otelcol.yaml
receivers:
  filelog:
    retry_on_failure:
      enabled: true
      # Wait 5 seconds after the first failure before the first retry.
      initial_interval: 5s
      # The longest the receiver will wait between retries is 30 seconds.
      max_interval: 30s
      # Give up trying to send a batch after 10 minutes.
      max_elapsed_time: 10m

Сочетая механизм контрольных точек с надёжной политикой повторных попыток, можно построить отказоустойчивый конвейер приема логов из файлов, способный пережить как перезапуски Collector, так и временные сбои или ограничения производительности последующих компонентов.

Удаление файлов логов после обработки

Некоторые сценарии предполагают однократную обработку файла с последующим его удалением для экономии дискового пространства и предотвращения повторной обработки. Для этого можно использовать параметр delete_after_read, который требует установки start_at: beginning.

# otelcol.yaml
receivers:
  filelog:
    include: [/var/log/archives/*.gz]
    start_at: beginning
    delete_after_read: true

Чтобы эта возможность работала, необходимо также включить feature gate filelog.allowFileDeletion.

# docker-compose.yml
services:
  otelcol:
    command:
      [
        --config=/etc/otelcol-contrib/config.yaml,
        --feature-gates=filelog.allowFileDeletion,
      ]

Наконец, убедитесь, что файлы могут быть удалены и что служба Collector обладает достаточными правами для их удаления. Если прав недостаточно, в логах появится запись"could not delete":

2025-10-08T06:42:03.973Z        error   reader/reader.go:278    could not delete        {"resource": {"service.instance.id": "7c0daf0e-e625-4da8-9577-072606dce057", "service.name": "otelcol-contrib", "service.version": "0.136.0"}, "otelcol.component.id": "filelog", "otelcol.component.kind": "receiver", "otelcol.signal": "logs", "component": "fileconsumer", "path": "/var/log/myapp/app.log", "filename": "/var/log/myapp/app.log"}

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

Корректная обработка ротации логов

Файлы логов не растут бесконечно. Рано или поздно выполняется их ротация (по крайней мере, так должно быть). Получатель filelog способен автоматически обрабатывать распространённые схемы ротации, например переименование app.log в app.log.1, без потери данных.

Вместо того чтобы полагаться исключительно на имя файла, получатель отслеживает каждый файл с помощью уникального отпечатка (fingerprint), вычисленного на основе первых нескольких килобайт его содержимого. Когда происходит ротация, получатель определяет, что исходный файл был переименован, завершает его чтение, после чего начинает работу с новым файлом app.log с самого начала.

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

Чтение сжатых файлов

Многие инструменты ротации логов сжимают старые файлы для экономии дискового пространства, создавая файлы вида access.log.1.gz. Получатель filelog способен работать с такими файлами, автоматически распаковывая их в процессе чтения.

Для этого используется параметр compression. Он сообщает получателю, что некоторые или все обнаруженные файлы могут быть сжаты и перед разбором должны быть распакованы.

Для параметра compression доступны два основных значения:

• gzip: считать все найденные файлы сжатыми в формате gzip.
• auto: автоматически определять наличие сжатия по расширению файла (в настоящее время поддерживается расширение .gz). Этот вариант является наиболее предпочтительным, если каталог содержит одновременно активные несжатые логи и старые сжатые файлы.

Например, если каталог содержит файлы app.log (активный) и app.log.1.gz (ротированный и сжатый), получатель можно настроить следующим образом.

# otelcol.yaml
receivers:
  filelog:
    include: [/var/log/myapp/*]
    start_at: beginning
    # Automatically detect and decompress .gz files
    compression: auto
    operators:
      - type: regex_parser
        # ... your parsing rules

При работе со сжатыми логами следует помнить о двух основных вещах.

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

Во-вторых, необходимо учитывать особенности формирования хэш-сумм файлов. По умолчанию получатель идентифицирует файлы по их сжатому содержимому. В большинстве случаев этого достаточно, однако при переименовании или перемещении файлов это может привести к неоднозначности. Для повышения надёжности идентификации можно включить feature gate filelog.decompressFingerprint. В этом случае отпечаток будет вычисляться по уже распакованному содержимому файла:

# docker-compose.yml
services:
  otelcol:
    command:
      [
        --config=/etc/otelcol-contrib/config.yaml,
        --feature-gates=filelog.decompressFingerprint,
      ]

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

Настройка производительности для сред с высокой нагрузкой

Настройки получателя filelog в OTel Collector по умолчанию оптимизированы для общего использования, однако в производственных средах с сотнями файлов логов или очень высокой интенсивностью поступления данных, скорее всего, потребуется дополнительная настройка производительности.

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

Параметр max_concurrent_files ограничивает количество файлов, читаемых одновременно. По умолчанию его значение равно 1024, однако уменьшение этого значения позволяет предотвратить чрезмерную нагрузку на систему.

Другим важным параметром является poll_interval, который определяет, как часто получатель проверяет наличие новых файлов и новых строк логов. По умолчанию используется значение 200ms, благодаря чему новые логи появляются практически мгновенно, однако при этом возрастает нагрузка на процессор, поскольку файловая система сканируется чаще.

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

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

# otelcol.yaml
receivers:
  filelog/k8s_pods:
    include: [/var/log/pods/*/*/*.log]
    max_concurrent_files: 200
    poll_interval: 1s
    max_log_size: 2MiB

Обеспечение порядка обработки файлов логов

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

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

Например, имеется следующий набор файлов логов:

batch-run-001.log
batch-run-002.log
batch-run-003.log

# otelcol.yaml
receivers:
  filelog/batch_logs:
    include: [/var/log/batch-runs/batch-run-*.log]
    start_at: beginning
    ordering_criteria:
      top_n: 1
      # Extract the sequence number from the filename
      regex: batch-run-(?P<seq_num>\d+)\.log
      # Sort files by the sequence number as a number, not a string
      sort_by:
        - regex_key: seq_num
          sort_type: numeric
          ascending: true

При такой конфигурации получатель обнаружит все файлы, соответствующие шаблону batch-run-*.log, извлечёт номер последовательности из имени каждого файла и отсортирует файлы по возрастанию этого номера.

Параметр top_n определяет, сколько файлов будет отслеживаться после применения правил сортировки. При значении top_n: 1 будет отслеживаться и приниматься только первый файл (batch-run-001.log).

Советы и рекомендации по использованию Filelog Receiver

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

Файлы логов не отслеживаются

Когда Collector начинает отслеживать файл логов, в его логах появляется запись следующего вида:

2025-10-09T08:47:05.574Z        info    fileconsumer/file.go:261        Started watching file   {...}

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

2025-10-09T09:25:20.280Z        warn    fileconsumer/file.go:49 finding files   {..., "error": "no files match the configured criteria"}

В первую очередь необходимо проверить параметры include, excludeи exclude_older_than, чтобы убедиться, что заданные шаблоны действительно соответствуют ожидаемым файлам.

Затем следует убедиться, что процесс Collector обладает правами доступа как к самим файлам, так и к каталогам, в которых они расположены. Отсутствие прав доступа к каталогам является одной из наиболее распространённых причин, по которым файлы не обнаруживаются и не начинают отслеживаться.

Файлы отслеживаются, но строки логов не считываются

Если сообщения "Started watching file" присутствуют, но логи не поступают, наиболее вероятной причиной является параметр start_at. По умолчанию используется значение end, которое указывает получателю начинать чтение только с новых строк, добавленных после запуска Collector.

Если во время тестирования используется уже существующий файл, в который больше ничего не записывается, никаких логов принято не будет. Чтобы прочитать файл полностью с самого начала, необходимо установить параметр start_at в значение beginning.

# otelcol.yaml
receivers:
  filelog:
    start_at: beginning

Это гарантирует, что при первом обнаружении файла получатель обработает всё его существующее содержимое.

Регулярное выражение не соответствует строкам лога

Если логи не разбираются должным образом, чаще всего проблема связана с регулярным выражением. В этом случае Collector обычно записывает следующую ошибку:

2025-10-09T09:32:14.949Z        error   helper/transformer.go:154       Failed to process entry {"resource": {"service.instance.id": "f8ec2efd-16e9-44ad-9ed2-9f406e46719f", "service.name": "otelcol-contrib", "service.version": "0.136.0"}, "otelcol.component.id": "filelog", "otelcol.component.kind": "receiver", "otelcol.signal": "logs", "operator_id": "regex_parser", "operator_type": "regex_parser", "error": "regex pattern does not match", "action": "send", "entry.timestamp": "0001-01-01T00:00:00.000Z", "log.file.name": "batch-run-001.log"}

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

Если данная ошибка не появляется, но регулярное выражение по-прежнему не работает, следует проверить, не установлен ли параметр on_error в один из режимов _quiet. Эти значения подавляют сообщения об ошибках операторов, если уровень логирования Collector не установлен в значение DEBUG.

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

После перезапуска появляются дублирующиеся логи

Если после перезапуска Collector появляются дублирующиеся записи логов, это обычно означает, что получатель не запоминает место, на котором остановился. Для устранения этой проблемы необходимо включить расширение storage, чтобы получатель filelog мог сохранять контрольные точки своего положения в каждом файле.

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

Заключительные мысли

Получатель filelog в OpenTelemetry является важным связующим звеном между традиционным ведением логов в файлы (зачастую содержащие неструктурированные данные) и современным миром структурированной наблюдаемости.

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

После преобразования необработанных текстовых логов в хорошо структурированные данные OpenTelemetry становятся доступны все возможности экосистемы наблюдаемости. Вы сможете обогащать, фильтровать и маршрутизировать их в любую систему, поддерживающую протокол OTLP.

Это перевод оригинальной статьи From vendors to vanguard: Airbnb’s hard-won lessons in observability ownership.

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

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

Как и многие другие компании, Airbnb изначально передала свои потребности в наблюдаемости внешним вендорам. Но по мере развития компании наши потребности стали отличаться от типичных стимулов вендоров. Вендоры взимают плату за объем обрабатываемых данных, поэтому затраты Airbnb росли, но большее количество данных не приводит автоматически к более быстрому получению аналитических данных или сокращению среднего времени обнаружения (MTTD) или устранения (MTTR). Кроме того, из-за отсутствия обратной связи в процессе использования данных наблюдаемости, наша способность улучшать рабочие процессы мониторинга наших клиентов или оптимизировать затраты на наблюдаемость была существенно ограничена.

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

Этот переход позволил нам получить полный контроль над сбором, хранением и запросами метрик. В рамках этого проекта мы успешно использовали наши инструменты автоматизации для миграции огромного объема данных через 1 000 сервисов: 300 миллионов временных рядов, 3 100 дашбордов и более 300 000 алертов. Хотя проект такого масштаба не реализуется без серьезных оснований, ограничения на то, что мы могли делать с нашими собственными данными, практически не оставили нам альтернативы.

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

Миграция v1

Восхождение на Эверест в первый день

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

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

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

Тот же багаж, но воздух разреженный.

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

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

Документация объясняет все — для тех, кто готов ее изучать

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

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

Миграция v2

Начинайте с достижимой цели.

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

Это позволит вашей команде:

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

Успешная миграция такого менее сложного сервиса достигает двух целей: демонстрирует техническую и операционную реализуемость проекта и помогает подтвердить целесообразность стратегии миграции для всей компании.

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

Мигрируйте смысл запроса

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

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

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

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

Для решения этой проблемы мы встроили механизм метаданных непосредственно в слой перевода. Он периодически сканирует все известные метрики и использует внутреннюю метку ( otel_metric_type ) для построения и поддержания надежного сопоставления метрики с типом.

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

Освоение нового языка запросов может быть непростой задачей.

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

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

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

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

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

Сейчас самое время исправить устаревшие паттерны

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

Хотя поначалу мы опасались внедрения новых концепций, по мере того, как наши первые пользователи начали использовать новую систему, нам стало ясно, что существующая система оповещений нуждается в замене. Мы решили продолжить работу команды, Reliability Experience, над улучшением системы создания алертов и продвигать их разработку как предпочтительный инструмент для создания оповещений.

Новый подход заменил устаревшую систему на новый интерфейс создания оповещений, который рассматривает каждое оповещение как этап разработки, а не как слабо документированный конфигурационный файл. Оповещения создаются как код, с автозаполнением и подсказками в стиле конструктора для написания запросов, встроенным тестированием для понимания того, когда оповещение сработало бы в прошлом, и сравнением изменений для наглядной оценки их влияния — и всё это до развертывания.

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

Заключение

В конечном итоге эта миграция стала чем-то гораздо большим, чем просто смена системы хранения. То, что начиналось как попытка «просто перенести систему», переросло в переосмысление нашего подхода к наблюдаемости, управлению и удобству работы разработчиков.

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

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

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

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

Даже для команд, которые не стоят перед необходимостью срочной миграции, уже сейчас есть шаги, позволяющие снизить будущие сложности. Наиболее важный из них — это контроль над слоем взаимодействия: frontend, инструменты разработки и workflow, которые инженеры используют для исследования и применения данных наблюдаемости. В ходе нашей миграции нам пришлось не только сменить бэкенд-систему, но и перевести все команды на новый инструмент визуализации и новый фреймворк алертов, что существенно увеличило стоимость перехода. Если бы эти точки взаимодействия уже находились под нашим контролем, переход бэкенд был бы значительно проще и более постепенным.

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

Это перевод оригинальной статьи You’re Not Ready for Kubernetes Observability Until You Understand These Concepts.

Реальная история обеспечения наблюдаемости в Kubernetes (которая действительно работает в продакшене)

Большинство людей начинают работать с Prometheus и Grafana, не понимая, какие задачи они решают. Вот что вам нужно знать в первую очередь.

Данная реализация взята из моего недавнего курса по DevOps, где мы создали реальную систему мониторинга для микросервисов, работающих на EKS.

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

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

Две разные проблемы, два разных решения

Когда вы начинаете работать с мониторингом Kubernetes, первое, что вам нужно понять, это то, что вы решаете две совершенно разные задачи.

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

Метрики показывают, насколько хорошо всё работает. Ваша задержка составляет 200 миллисекунд. Загрузка CPU — 75%. За последнюю минуту было обработано 1000 запросов. Эти показатели отражают состояние и производительность системы.

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

Как на самом деле работает сбор логов

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

Существует два основных сценария, зависящих от типа выполняемой рабочей нагрузки.

Простая модель для управляемых вычислительных ресурсов

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

Вы устанавливаете аддон в кластер. Это может быть CloudWatch Observability add-on. Может быть OpenTelemetry или Fluentd. Эти аддоны разворачивают коллекторы, которые автоматически обнаруживают ваши pod’ы и начинают забирать логи.

Ключевое слово — «pull» (запрос). Сборщики подключаются к логам вашего пода и передают их в пункт назначения. Обычно первым делом используется CloudWatch.

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

Паттерн-sidecar для сложных приложений

Для рабочих нагрузок, которым требуется постоянное хранилище или есть специфические требования к логированию, используется так называемый sidecar-паттерн.

В вашем поде работают два контейнера вместо одного: основной контейнер приложения и контейнер для ведения логов. Оба контейнера монтируют один и тот же том.

Вот как это происходит

• Ваше приложение записывает логи в файл на общем томе.
• В контейнере-сайдкаре работает что-то вроде Fluentd, которое постоянно считывает этот лог-файл и пересылает его содержимое в пункт назначения.

Мы делаем это таким образом, чтобы обеспечить разделение ответственности. Код вашего приложения остаётся простым. Он просто записывает данные в файл. Вся сложность форматирования, батчинга, повторных попыток при неудачной отправке и маршрутизации в разные назначения находится в sidecar’е.

Если вам нужно изменить место хранения логов или их формат, вы изменяете конфигурацию sidecar-контейнера. Код вашего приложения при этом остаётся неизменным.

Почему одного CloudWatch недостаточно при масштабировании

Большинство начинают с отправки всех данных в CloudWatch. Он интегрирован с AWS. Он надежен. Он хорошо подходит для небольших систем.

Однако при генерации значительного объема логов у CloudWatch есть ограничения.

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

Именно поэтому в production-конфигурациях добавляют дополнительные слои.

Паттерн корпоративного пайплайна логов

В нашей bootcamp-конфигурации логи проходят через несколько этапов. Каждый этап выполняет свою конкретную задачу.

CloudWatch по-прежнему является точкой входа. Он надежен, и именно через него ваши сервисы AWS ожидают отправлять данные. Но это только первый этап.

Из CloudWatch логи передаются в функцию Lambda. Это необязательный, но полезный механизм. Lambda стандартизирует форматы логов, добавляет метаданные и приводит в порядок временные метки. Разные сервисы логируют по-разному. Этот этап делает всё единообразным.

Далее следует Kinesis Firehose. Это ваш стриминговый буфер. Вместо записи тысяч отдельных лог-записей в конечное хранилище, Kinesis объединяет их в батчи.

Мы настроили буфер на 20 минут. Он собирает логи, а затем сбрасывает всё одним эффективным батчем.

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

Конечная цель — OpenSearch. Именно здесь по-настоящему проявляется возможность мониторинга в масштабах.

Что отличает OpenSearch

OpenSearch создан для одной цели: быстрого полнотекстового поиска по огромным массивам данных.

Когда у вас петабайты логов и вам нужно найти каждое вхождение конкретной ошибки в сотнях сервисов, OpenSearch справится с этим за секунды. Когда нужно агрегировать частоту ошибок по сервисам и времени. Когда нужно выполнять сложные запросы, которые в CloudWatch просто завершились бы по таймауту. С этим справляется OpenSearch.

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

В нашей системе мы храним данные за 7 дней в OpenSearch. Это актуальные данные для активного расследования и мониторинга.

Все данные также резервно копируются в S3 через Kinesis Firehose. S3 — это недорогое хранилище для долговременного хранения. Мы храним там логи за несколько лет в целях соблюдения нормативных требований. Мы нечасто обращаемся к S3, но если нам нужны исторические данные для расследования, они там есть.

Таким образом, стратегия хранения данных такова: 7 дней в OpenSearch для быстрых запросов, 30 дней в CloudWatch в качестве промежуточного варианта, и годы в S3 для соответствия требованиям.

Каждый этап имеет разные характеристики стоимости и производительности. Вы выбираете, исходя из своих потребностей.

Чем отличается сбор метрик

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

Принципиальное различие заключается в структуре данных. Логи — это неструктурированный текст. Метрики — это числа с подписями. Логи рассказывают истории. Метрики измеряют показатели.

Prometheus — это стандарт для метрик Kubernetes. Он использует pull-модель, что выглядит непривычно для большинства людей.

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

Почему используется модель «pull» вместо «push»? Это обеспечивает контроль и надежность. Prometheus контролирует расписание сбора данных. Если ваше приложение аварийно завершает работу, Prometheus узнает об этом немедленно, поскольку сбор данных завершается неудачей. При использовании модели «push» аварийно завершившееся приложение просто перестает отправлять данные, и вы можете этого не заметить.

Что на самом деле делает Prometheus

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

Prometheus хранит метрики в оперативной памяти с использованием дискового кэширования. Вы можете настроить срок хранения, обычно 15 дней. После этого данные устаревают. Если вам требуется более длительный срок хранения, вы можете использовать расширения, такие как Thanos, которые архивируют данные в объектное хранилище.

Prometheus также ничего не визуализирует. Это не его задача. Он собирает, хранит и позволяет запрашивать метрики. Визуализация — это задача Grafana.

Как приложения предоставляют доступ к метрикам

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

Для каждого основного языка программирования существуют клиентские библиотеки Prometheus. В Python есть prometheus_client. В Go есть официальный client_golang. В Java есть несколько вариантов.

Схема всегда одна и та же. Импортируйте библиотеку. Определите свои метрики в виде счетчиков, индикаторов или гистограмм. Увеличивайте или устанавливайте значения в своем коде. Запускайте HTTP-сервер, который отдаёт эти метрики.

В результате у приложения появляется эндпоинт вроде /metrics, который возвращает текущие значения в формате Prometheus. Prometheus опрашивает этот эндпоинт и сохраняет данные.

Ключевая идея заключается в том, что разработчики используют инструменты мониторинга для своего кода. Они сами решают, что стоит измерять. Количество запросов. Частота ошибок. Время ответа. Длина очереди. Размеры пулов подключений к базе данных. Всё, что важно для понимания работы приложения.

ServiceMonitor сообщает Prometheus, что нужно опрашивать

Prometheus должен знать, какие эндпоинты опрашивать и как часто. В Kubernetes это описывается с помощью ресурсов ServiceMonitor.

В ServiceMonitor указано: «Найти все поды с этими метками, собирать их метрики с порта каждые 30 секунд по этому пути».

Для каждого приложения создается отдельный ServiceMonitor. Prometheus отслеживает эти ресурсы и автоматически настраивает сбор данных на их основе.

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

30 секунд — это стандартный интервал сбора данных. Более частый интервал обеспечивает лучшее разрешение, но потребляет больше ресурсов. Менее частый интервал снижает нагрузку, но вы можете пропустить кратковременные всплески метрик.

Что на самом деле делает Grafana

Grafana — это всего лишь инструмент визуализации. Он ничего не собирает и ничего не хранит. Он подключается к источникам данных и создает красивые графики.

При установке kube-prometheus-stack с помощью Helm, Grafana поставляется в комплекте и предварительно настроена с Prometheus в качестве источника данных. Но вы можете добавить и другие источники данных: CloudWatch для метрик AWS, OpenSearch для визуализации на основе логов, а также любую базу данных, поддерживаемую Grafana.

Главное преимущество Grafana заключается в возможности объединять данные из разных источников в одном дашборде. Вы можете показать метрики приложения из Prometheus, производительность базы данных из CloudWatch и тренды ошибок из логов OpenSearch — всё на одном экране.

Использование готовых дашбордов вместо создания с нуля

Вот что значительно сэкономит время. На сайте grafana.com/grafana/dashboards доступны тысячи готовых панелей мониторинга.

Нужен мониторинг кластера Kubernetes? Найдите подходящий дашборд. Скопируйте его ID. Импортируйте в Grafana. Готово. У вас профессиональный мониторинг без написания ни одного запроса.

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

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

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

Создание кастомных дашбордов по мере необходимости

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

В Grafana есть конструктор запросов, но понимание базового языка запросов сильно помогает. Для источников данных Prometheus это PromQL.

Простой PromQL-запрос http_requests_total может отображать общее количество запросов. Вы можете фильтровать запросы по меткам, например, http_requests_total{service=”catalog”} только для сервиса catalog. Вы можете рассчитать скорость запросов с помощью rate(http_requests_total[5m]), чтобы показать количество запросов в секунду за 5 минут.

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

Концепция соглашений об уровне обслуживания (SLA) и почему они важны

Именно здесь наблюдаемость соприкасается с реальностью бизнеса.

Соглашение об уровне обслуживания (SLA) — это обещание вашим клиентам относительно качества предоставляемых услуг. Возможно, вы обещаете 99,1% времени безотказной работы. Возможно, вы обещаете время ответа менее 500 миллисекунд для 95% запросов.

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

Позвольте мне показать вам, что на самом деле означает 99,1% времени безотказной работы. В одном месяце примерно 2,5 миллиона секунд. 99,1% времени безотказной работы означает, что допустимое время простоя составляет 0,9%. Это примерно 64 часа в месяц.

Это ваш бюджет простоя. Ваша система мониторинга отслеживает, укладываетесь ли вы в бюджет. Если вы расходуете его слишком быстро, вам нужно исправить ситуацию до того, как нарушится соглашение об уровне обслуживания (SLA).

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

Подводя итог

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

Логи передаются из подов к коллекторам, а затем в CloudWatch, опционально проходят через Lambda для форматирования, затем через Kinesis для буферизации, попадают в OpenSearch для анализа и в S3 для резервного хранения.

Метрики собираются Prometheus с конечных точек приложений, определенных ServiceMonitors. Prometheus сохраняет актуальные данные. Grafana визуализирует их вместе с данными из других источников.

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

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

Перевод оригинальной статьи A Step-by-Step Guide to Securing Observability Pipelines Using Vector by Datadog.

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

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

Почему Vector?

Начнём с нашего сценария использования. В DV мы часто упаковываем и поставляем приложения нашим партнёрам, которые затем устанавливают их в своей инфраструктуре. Чтобы обеспечить надёжность, нам необходимо собирать данные о производительности этих приложений.

Поскольку инфраструктура наших партнеров часто остается для нас "черным ящиком", мы пришли к выводу, что нам необходим инструмент, отвечающий следующим требованиям:

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

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

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

В этой статье я покажу, как собирать метрики Prometheus из приложения, работающего в кластере Kubernetes, и передавать их в экземпляр Prometheus, размещённый на виртуальной машине в другом географическом регионе, используя Prometheus Remote Write.

Предварительные требования

Для понимания этой статьи вам потребуется:

1. Практические навыки работы с Kubernetes и использования Kubectl.
2. Практические навыки установки и настройки Helm-чартов.
3. Запущенный кластер Kubernetes как минимум с одним узлом (в примере используется кластер GKE).
4. Запущенный экземпляр Prometheus с включённой поддержкой Remote Write (в примере Prometheus установлен на виртуальной машине в GCP).
5. Все необходимые сетевые коммуникации между Vector и Prometheus.
6. Сертификаты mTLS, подписанные доверенным центром сертификации (для этой демонстрации используются самоподписанные сертификаты).

Что такое mTLS?

Mutual TLS, или сокращенно mTLS, — это механизм взаимной аутентификации. mTLS гарантирует, что обе стороны сетевого соединения действительно являются теми, за кого себя выдают, проверяя наличие корректного закрытого ключа у каждой из сторон. Дополнительная проверка осуществляется на основе информации, содержащейся в соответствующих TLS-сертификатах.

mTLS часто используется в рамках концепции безопасности «нулевого доверия» для проверки пользователей, устройств и серверов организации.

Архитектурная схема

Далее — самая интересная часть: внедрение!

Шаг 1: Создание самоподписанных mTLS-сертификатов

Сначала мы создаём центр сертификации (ЦС), которому доверяют как клиент, так и сервер.

openssl req \
 -new \
 -x509 \
 -nodes \
 -days 30 \
 -subj '/CN=my-ca.my-domain.com' \
 -keyout ca.key \
 -out ca.crt

Эта команда выводит два файла, ca.key и ca.crt, оба в формате PEM.

Далее мы создаём ключ сервера, а затем сертификат.

openssl genrsa -out server.key 4096

Теперь давайте создадим запрос на подписание сертификата (CSR), который будет подписан нашим центром сертификации:

openssl req \
 -new \
 -key server.key \
 -subj '/CN=prometheus.my-domain.com' \
 -out server.csr

Используя запрос на подписание сертификата (CSR), давайте создадим сертификат сервера:

openssl x509 \
 -req \
 -in server.csr \
 -CA ca.crt \
 -CAkey ca.key \
 -CAcreateserial \
 -days 30 \
 -out server.crt

Обратите внимание на следующий вывод команды, а также на созданный PEM-файл server.crt:

Certificate request self-signature ok
subject=CN=prometheus.my-domain.com

Теперь повторим этот процесс для создания клиентского сертификата и закрытого ключа. Как и ранее, начнём с генерации ключа.

openssl genrsa -out client.key 4096

Теперь создадим запрос на подпись сертификата (CSR), который также будет подписан нашим центром сертификации.

openssl req \
 -new \
 -key client.key \
 -subj '/CN=vector.my-domain.com' \
 -out client.csr

Используя запрос на подписание сертификата (CSR), создайте клиентский сертификат:

openssl x509 \
 -req \
 -in client.csr \
 -CA ca.crt \
 -CAkey ca.key \
 -CAcreateserial \
 -days 30 \
 -out client.crt

Обратите внимание на приведенный ниже вывод, а также на PEM-файл client.crt:

Certificate request self-signature ok
subject=CN=vector.my-domain.com

Теперь в текущей рабочей директории должны находиться следующие файлы:

ca.crt
ca.key
ca.srl
client.crt
client.csr
client.key
server.crt
server.csr
server.key

Мы будем работать с файлами ca.crt, ca.key, client.crt, client.key, server.crt и server.key. Переместите их в такое место, где Vector сможет получить доступ к клиентским сертификатам, а Prometheus — к серверным.

Можете смело удалять файлы ca.srl, client.csr и server.csr — они нам больше не нужны.

Шаг 2: Создание Namespace для Vector и Kubernetes Secret с сертификатами mTLS

Создайте своё пространство имён:

kubectl create namespace vector

Затем создайте Kubernetes Secret с сертификатами:

kubectl create secret generic vector-certs \
--namespace vector \
--from-file=ca.crt=ca.crt \
--from-file=tls.crt=client.crt \
--from-file=tls.key=client.key

Шаг 3: Установка и настройка Vector с помощью Helm

Добавьте репозиторий Helm:

helm repo add vector https://helm.vector.dev
helm repo update

Подготовьте пользовательскую конфигурацию для Vector.

Давайте создадим пользовательский файл и определим в нём наши конвейеры наблюдаемости.

В приведённом ниже примере Vector настроен на получение метрик с конечной точки http://app.my-namespace.svc.cluster.local:8384/metrics в секции source, а затем на передачу данных на конечную точку https://prometheus.my-domain.com:9090/api/v1/write в секции sink (получателя) с использованием TLS.

## my-vector-custom-configs.yaml
data_dir: /var/lib/vector
sources:
  app_scrape:
    type: prometheus_scrape
    endpoints:
    - "http://app.my-namespace.svc.cluster.local:8384/metrics" ## Enpoint that exposes application performance metrics
    scrape_interval_secs: 15
sinks:
  prometheus_remotewrite:
    type: prometheus_remote_write
    inputs:
    - app_scrape
    endpoint: https://prometheus.my-domain.com:9090/api/v1/write ## Endpoint that receives p8s metrics
    healthcheck:
      enabled: true
    tls:
      ca_file: "/run/secrets/tls/ca.crt"
      crt_file: "/run/secrets/tls/client.crt"
      key_file: "/run/secrets/tls/client.key"

Теперь давайте создадим Kubernetes ConfigMap, используя указанный выше файл, и подключим его к поду Vector. Вам также необходимо подключить ранее созданный Secret, чтобы Vector мог использовать TLS-сертификаты при передаче данных на Prometheus Remote Write.

Создайте ConfigMap для Kubernetes:

kubectl create configmap vector-custom-configs \
--namespace vector \
--from-file=vector.yaml=my-vector-custom-configs.yaml

Подготовьте пользовательский файл values, который подключит и ConfigMap, и Secret к поду Vector:

## my-vector-custom-values.yaml
args:
  - --config
  - "/opt/vector/vector.yaml"

extraVolumeMounts:
  - name: secret
    mountPath: /run/secrets/tls/
  - name: custom-configs
    mountPath: /opt/vector
    readOnly: true

extraVolumes:
  - name: secret
    secret:
      secretName: "vector-certs"
  - name: custom-configs
    configMap:
      name: "vector-custom-configs"

Установите Helm Chart Vector.

По умолчанию Vector запускается как StatefulSet в роли Aggregator. В качестве альтернативы он может работать как Deployment в роли Stateless-Aggregator либо как DaemonSet в роли Agent. Эти свойства можно переопределить в файле custom-values.yaml по мере необходимости. Для получения дополнительной информации можно также обратиться к файлу default-values.yaml .

helm upgrade --install my-vector-release vector/vector \
--namespace vector \
-f my-vector-custom-values.yaml

После успешной установки в терминале вы должны увидеть вывод Helm со статусом «STATUS: deployed» и шаблоном запуска Vector.

Если настройка прошла успешно, вы увидите, что поды Vector StatefulSet находятся в состоянии Running без сообщений об ошибках в логах.

Наблюдаемость: ключ к эффективному управлению данными.

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

Vector обладает мощными и адаптируемыми возможностями сбора данных, что делает его незаменимым решением для построения надежных конвейеров мониторинга. Однако, помимо сбора метрик Prometheus, Vector может построить несколько конвейеров для сбора логов и трассировок (traces), которые затем могут быть отправлены в другие системы мониторинга, такие как Loki, Splunk, Datadog или Elastic.

Надеюсь, было полезно. Спасибо за прочтение!

Это перевод оригинальной статьи Stop Running 5 Agents Per Server — Use Grafana Alloy Instead.

Как я заменил Prometheus + Node Exporter + Promtail + MySQL Exporter одним бинарным файлом

Я управлял более чем 10 серверами с классическим стеком мониторинга: Prometheus для сбора метрик, Node Exporter на каждом хосте, Promtail для отправки логов, а также MySQL Exporter, Apache Exporter и другими.

Это означает 4–5 агентов на сервер. Каждому требуется настройка, обновления и устранение неполадок.

Затем я открыл для себя Grafana Alloy.

Один бинарный файл. Один конфигурационный файл. Метрики, логи и трассировки — всё в одном месте.

Так я это настроил.

Что такое Grafana Alloy?

Alloy — это унифицированный сборщик телеметрии Grafana (ранее Grafana Agent). Он заменяет:

• ✅ Prometheus (сбор метрик)
• ✅ Node Exporter
• ✅ MySQL Exporter
• ✅ Apache Exporter
• ✅ Promtail
• ✅ OpenTelemetry Collector

Один агент для управления всем стеком.

Архитектура

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ MySQL Server │    │  Web Server  │    │ Docker Host  │
│    Alloy     │    │    Alloy     │    │    Alloy     │
└──────┬───────┘    └──────┬───────┘    └──────┬───────┘
       │                   │                   │
       └───────────────────┼───────────────────┘
                           ▼
              ┌────────────────────────┐
              │   Monitoring Server    │
              │  Prometheus + Loki +   │
              │       Grafana          │
              └────────────────────────┘

Рассмотрим, как это настроить.

Часть 1: Сервер мониторинга

Я использую Docker Compose. Простой и портативный способ.

Создайте структуру каталогов.

mkdir -p /opt/monitoring/{prometheus,loki,grafana/provisioning/datasources}
cd /opt/monitoring

docker-compose.yml

version: "3.8"

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-remote-write-receiver'
    ports:
      - "9090:9090"
    restart: unless-stopped
  grafana:
    image: grafana/grafana:latest
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme
      - GF_USERS_ALLOW_SIGN_UP=false
    ports:
      - "3000:3000"
    restart: unless-stopped
  loki:
    image: grafana/loki:latest
    volumes:
      - ./loki/loki-config.yml:/etc/loki/local-config.yaml
      - loki_data:/loki
    command: -config.file=/etc/loki/local-config.yaml
    ports:
      - "3100:3100"
    restart: unless-stopped
volumes:
  prometheus_data:
  grafana_data:
  loki_data:

prometheus/prometheus.yml

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

Ключевая настройка: --web.enable-remote-write-receiver позволяет Alloy напрямую передавать метрики в Prometheus.

loki/loki-config.yml

auth_enabled: false

server:
  http_listen_port: 3100
common:
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory
schema_config:
  configs:
    - from: 2020-10-24
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h
limits_config:
  retention_period: 30d
compactor:
  working_directory: /loki/compactor
  retention_enabled: true
  delete_request_store: filesystem

⚠️ Важно: строка delete_request_store: filesystem обязательна, когда включено хранение (retention). Без неё Loki не запустится.

grafana/provisioning/datasources/datasources.yml

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
  - name: Loki
    type: loki
    access: proxy
    url: http://loki:3100

Запускаем

docker compose up -d

Проверка:

• Grafana: http://YOUR_IP:3000 (admin/changeme)
• Prometheus: http://YOUR_IP:9090
• Loki: http://YOUR_IP:3100/ready

Часть 2: Мониторинг сервера MySQL

Теперь давайте установим Alloy на сервер базы данных MySQL.

Установка Alloy

curl -fsSL https://apt.grafana.com/gpg.key | gpg --dearmor -o /usr/share/keyrings/grafana.gpg
echo "deb [signed-by=/usr/share/keyrings/grafana.gpg] https://apt.grafana.com stable main" | tee /etc/apt/sources.list.d/grafana.list
apt update && apt install alloy -y

Создаём пользователя мониторинга MySQL

CREATE USER 'alloy'@'localhost' IDENTIFIED BY 'secure_password';
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'alloy'@'localhost';
FLUSH PRIVILEGES;

Конфигурация Alloy

Создайте /etc/alloy/config.alloy:

// Node metrics (replaces node_exporter)
prometheus.exporter.unix "node" { }

prometheus.scrape "node" {
  targets    = prometheus.exporter.unix.node.targets
  forward_to = [prometheus.relabel.add_labels.receiver]
}
// MySQL metrics (replaces mysqld_exporter)
prometheus.exporter.mysql "db" {
  data_source_name = "alloy:secure_password@(localhost:3306)/"
}
prometheus.scrape "mysql" {
  targets    = prometheus.exporter.mysql.db.targets
  forward_to = [prometheus.relabel.add_labels.receiver]
}
// Add server label to all metrics
prometheus.relabel "add_labels" {
  rule {
    action       = "replace"
    target_label = "server"
    replacement  = "mysql-01"
  }
  forward_to = [prometheus.remote_write.default.receiver]
}
// Ship to Prometheus
prometheus.remote_write "default" {
  endpoint {
    url = "http://192.168.0.23:9090/api/v1/write"
  }
}
// Ship logs to Loki
loki.source.file "logs" {
  targets = [
    {__path__ = "/var/log/mysql/error.log", job = "mysql-error", server = "mysql-01"},
    {__path__ = "/var/log/syslog", job = "syslog", server = "mysql-01"},
  ]
  forward_to = [loki.write.default.receiver]
}
loki.write "default" {
  endpoint {
    url = "http://192.168.0.23:3100/loki/api/v1/push"
  }
}

Исправьте права доступа и запустите.

usermod -aG adm alloy
usermod -aG mysql alloy
systemctl enable alloy
systemctl start alloy

Убедитесь, что всё работает.

curl -s "http://192.168.0.23:9090/api/v1/query?query=mysql_up" | jq .

В результате вы должны увидеть сервер mysql-01 .

Часть 3: Мониторинг веб-сервера Apache

Схема та же — установить Alloy, настроить экспортеры.

Включаем статус Apache

a2enmod status

Создайте /etc/apache2/sites-available/000-localhost-status.conf:

<VirtualHost 127.0.0.1:80>
    ServerName 127.0.0.1
    
    <Location "/server-status">
        SetHandler server-status
        Require local
    </Location>
</VirtualHost>

a2ensite 000-localhost-status
systemctl restart apache2

Полезный совет: если используется Laravel или другой фреймворк, перехватывающий маршруты, создайте отдельный vhost. Префикс 000- гарантирует, что он загрузится первым.

Настройка Alloy

prometheus.exporter.unix "node" { }

prometheus.scrape "node" {
  targets    = prometheus.exporter.unix.node.targets
  forward_to = [prometheus.relabel.add_labels.receiver]
}
prometheus.exporter.apache "web" {
  scrape_uri = "http://127.0.0.1/server-status?auto"
}
prometheus.scrape "apache" {
  targets    = prometheus.exporter.apache.web.targets
  forward_to = [prometheus.relabel.add_labels.receiver]
}
prometheus.relabel "add_labels" {
  rule {
    action       = "replace"
    target_label = "server"
    replacement  = "web-server"
  }
  forward_to = [prometheus.remote_write.default.receiver]
}
prometheus.remote_write "default" {
  endpoint {
    url = "http://192.168.0.23:9090/api/v1/write"
  }
}
loki.source.file "apache_logs" {
  targets = [
    {__path__ = "/var/log/apache2/access.log", job = "apache-access", server = "web-server"},
    {__path__ = "/var/log/apache2/error.log", job = "apache-error", server = "web-server"},
  ]
  forward_to = [loki.write.default.receiver]
}
loki.write "default" {
  endpoint {
    url = "http://192.168.0.23:3100/loki/api/v1/push"
  }
}

Часть 4: Мониторинг контейнеров Docker

Для хостов Docker используйте cAdvisor для сбора метрик контейнеров.

Запустите cAdvisor

docker run -d \
  --name=cadvisor \
  --restart=unless-stopped \
  --privileged \
  -p 8081:8080 \
  -v /:/rootfs:ro \
  -v /var/run:/var/run:ro \
  -v /sys:/sys:ro \
  -v /var/lib/docker/:/var/lib/docker:ro \
  gcr.io/cadvisor/cadvisor:latest

Настройте Alloy для сбора данных с cAdvisor.

prometheus.exporter.unix "node" { }

prometheus.scrape "node" {
  targets    = prometheus.exporter.unix.node.targets
  forward_to = [prometheus.relabel.add_labels.receiver]
}
prometheus.scrape "cadvisor" {
  targets = [
    {"__address__" = "localhost:8081", "job" = "cadvisor"},
  ]
  forward_to = [prometheus.relabel.add_labels.receiver]
}
prometheus.relabel "add_labels" {
  rule {
    action       = "replace"
    target_label = "server"
    replacement  = "docker-host"
  }
  forward_to = [prometheus.remote_write.default.receiver]
}
prometheus.remote_write "default" {
  endpoint {
    url = "http://192.168.0.23:9090/api/v1/write"
  }
}
// Collect container logs directly
discovery.docker "containers" {
  host = "unix:///var/run/docker.sock"
}
loki.source.docker "containers" {
  host       = "unix:///var/run/docker.sock"
  targets    = discovery.docker.containers.targets
  labels     = {server = "docker-host", job = "docker"}
  forward_to = [loki.write.default.receiver]
}
loki.write "default" {
  endpoint {
    url = "http://192.168.0.23:3100/loki/api/v1/push"
  }
}

Не забудьте:

usermod -aG docker alloy
systemctl restart alloy

Советы по дашбордам Grafana

Добавьте выпадающий список серверов

1. Настройки дашборда → Переменные → Создать
2. Имя: server
3. Тип: Запрос
4. Запрос: label_values(up, server)
5. Включите Multi-value и Include All

Теперь используйте {server=~"$server"} в своих запросах:

rate(mysql_global_status_queries{server=~"$server"}[5m])

Ключевые метрики для мониторинга

MySQL:

• mysql_up — доступен ли сервер
• mysql_global_status_threads_connected — количество активных подключений
• rate(mysql_global_status_slow_queries[5m]) — скорость медленных запросов

Apache:

• apache_up — доступен?
• apache_workers{state="busy"} — активные воркеры
• rate(apache_accesses_total[5m]) — количество запросов в секунду

Host:

• 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) — загрузка CPU %
• node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes — используемая оперативная память (RAM)

Распространённые проблемы

«Компонент не существует»

В Alloy нет всех экспортеров. Например, prometheus.exporter.php_fpm просто не существует.

Решение: Запустить автономный экспортер и собирайте метрики с него, или предоставьте доступ к метрикам через HTTP.

Конфигурация не загружается

alloy fmt /etc/alloy/config.alloy  # Check syntax
alloy run /etc/alloy/config.alloy  # See actual error

Нет доступа к логам

usermod -aG adm alloy
usermod -aG www-data alloy  # for Apache logs
systemctl restart alloy

Результат

До: 5 агентов на сервер, 5 конфигураций для поддержки, 5 потенциальных точек отказа.

После: 1 агент, 1 конфигурация, единая ситема наблюдаемости.

Теперь мой стек мониторинга:

• Проще разворачивать (один бинарник)
• Проще настраивать (один конфигурационный файл River)
• Проще диагностировать проблемы (всё в одном месте)

Попробуйте Alloy. В будущем вы скажете себе спасибо.

Ресурсы

• Документация Grafana Alloy
• Язык конфигурации River
• Встроенный список экспортеров

Перевод оригинальной статьи Building a Production-Grade Observability Platform with SigNoz, ClickHouse, and OpenTelemetry — Part 1

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

1. Обзор

Мы поставили перед собой задачу создать собственную платформу на базе SigNoz, ClickHouse и OpenTelemetry (OTEL), способную обрабатывать метрики и трассировки в различных средах в производственных масштабах. Мы постоянно запускаем тысячи экземпляров EC2 и хранилищ данных, генерирующих миллионы метрик и событий трассировки. Кроме того, это помогает нам экономить миллионы долларов на счетах других коммерческих решений, которые мы использовали раньше. 💸

О чем этот блог (и серия)

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

В следующих частях мы подробно рассмотрим:

Единый двоичный пользовательский интерфейс SigNoz и схемы *MergeTree

• Различные компонент пользовательского интерфейса Signoz и их практические последствия при настройке продакшна.
• *Схемы MergeTree для хранения метрик и трассировок в ClickHouse и то, как они используют “fingerprints” для оптимизации хранения.

Внутреннее устройство ClickHouse для телеметрических нагрузок

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

Давайте же приступим!

Высокоуровневая архитектура

Проектирование высокого уровня (HLD)

Вот высокоуровневая архитектура конвейера наблюдаемости, который мы настроили с использованием OpenTelemetry (OTEL), Kafka и SigNoz. Цель была проста: создать масштабируемый, независимый от вендора конвейер телеметрии, который мог бы обрабатывать метрики и трассировки десятков сервисов, не ограничиваясь одним проприетарным решением.

Всё начинается с источника — наших приложений и систем данных, таких как PostgreSQL, Spark и различных микросервисов. Они генерируют телеметрию (метрики и трассировки), которые мы собираем с помощью OTEL-коллекторов и SDK. Коллекторы отвечают за пакетирование, сэмплинг и преобразование данных в единый формат OTEL перед их дальнейшей отправкой.

Для мониторинга метрик собственных сервисов AWS мы передаем метрики CloudWatch через Firehose. На пути потока находится лямбда-функция для обогащения тегами, добавляя полезные метаданные, такие как имена сервисов, окружения или кастомные теги, которые значительно упрощают поиск данных в будущем. Далее обогащенные данные резервируются в S3 и направляются на уровень коллектора OTEL через балансировщик нагрузки.

Совет 🚀В Firehose мы использовали размер буфера 0,2 МБ и интервал между буферами 60 секунд. Это даёт нам около 200 одновременных вызовов лямбда. Увеличение размера буфера может уменьшить количество лямбда вызовов. Однако необходимо учитывать размер сообщения после обогащения тега. Чем больше буфер, тем больше пакет после обогащения, и вы можете столкнуться с ошибками «Message size too large» в логах Firehose. Настройте значение для оптимизации затрат.

Лямбда для обогащения метрик тегами: мы использовали модификацию этой лямбды для OTLPv1.0. Она использует ResourceGroupsTaggingAPI для обогащения метрик тегами в потоке.

Используйте sending_queue и retry_on_failure в конфигурации OTEL collector. При экспорте в Kafka, в случае сбоя, коллектор будет хранить сообщения в памяти в зависимости от установленного лимита и пытаться отправить их повторно. Если очередь переполнена, начнется потеря сообщений. Слишком длинная очередь может привести к исчерпанию памяти экземпляра, вплоть до полной потери ответа. Поэтому лимит очереди критически важен.

Все эти телеметрические данные — как метрики, так и трассировки — поступают в Kafka, которая служит основой нашего конвейера наблюдения. У нас есть отдельные топики Kafka для метрик и трассировок, поддерживаемые шестью брокерами, с фактором репликации 3 и сроком хранения 3 дня. Это обеспечивает надёжный, отказоустойчивый буфер, способный справляться с пиковыми нагрузками без потери данных.

Из Kafka данные получают коллекторы SigNoz и записывают их в ClickHouse, нашу основную базу данных временных рядов. Кластер ClickHouse состоит из 3 шардов и 3 реплик, координируемых ZooKeeper для обеспечения согласованности и отказоустойчивости. Для управления расходами старые данные (более 90 дней) автоматически выгружаются в S3, что обеспечивает долгосрочное хранение без избыточных расходов на локальное хранилище.

Совет 🚀

- Убедитесь, что брокеры размещены в разных зонах доступности для высокой отказоустойчивости. У нас есть 6 брокеров с коэффициентом репликации 3 и сроком хранения 3 дня.

– Нам пришлось обновить max_message_bytes, поскольку батчи OTEL-коллектора превышали стандартный размер в 1 МБ. Настройте это значение в соответствии с вашей пропускной способностью.

- Конфигурация memory_limiter на коллекторе Signoz OTEL оказалась настоящим спасением! Она ограничивает потребление памяти заданным порогом и оказывает обратное давление на приемник Kafka при превышении лимитов памяти экземпляра, защищая экземпляр от выполнения OOM.

- Мы используем 8xlarge-инстанс для каждого узла ClickHouse с SSD-накопителем на 250 ГБ. Мы будем экспериментировать с уменьшением размера экземпляра после бенчмаркинга с использованием трёхмесячных метрик. В настоящее время загрузка ЦП составляет около 8%.

Наконец, все данные выводятся на сервер SigNoz, предоставляющий единую интерфейс-панель для запросов и визуализации как метрик, так и трассировок. Именно здесь команды непосредственно взаимодействуют с данными — устраняют скачки задержек, анализируют тенденции и находят узкие места в производительности.

Короче говоря, эта архитектура обеспечивает чёткое разделение приёма, обработки и хранения данных. Она устойчива к пиковым нагрузкам, достаточно модульна для развития со временем и даёт нам полный контроль над тем, как данные наблюдения проходят через наш стек, — без зависимости от непрозрачного ("чёрного ящика") SaaS-решения.

Масштаб и производительность

• Производственная инфраструктура, находящаяся под наблюдением, включает в себя более 10 тыс. экземпляров EC2 и хранилищ данных, работающих на пике производительности, генерирующих метрики и трассировки.
• Скорость приема данных: ~200 Мбит/с (Cloudwatch + метрики хоста + трассировки)
• ~100 млн уникальных метрик на пике
• ~1 млн строк/сек реплицируется на все 9 узлов ClickHouse
• Время вставки запросов в ClickHouse: 25 мкс.
• 357 ТБ загруженных спанов в месяц.

2. Почему OpenTelemetry (OTEL), а не Prometheus

Prometheus многие годы был стандартным выбором для наблюдаемости, но когда нам понадобилась телеметрия «сквозных сигналов» (метрики + трассировки + логи), его ограничения стали очевидными. Подробнее об этих различиях читайте в этой статье.

Точки принятия решений:

• Модель pull в Prometheus отлично подходит для простых кластеров, но плохо масштабируется для распределенных рабочих нагрузок с высокой мощностью.
• Конструкция OTEL на основе push-уведомлений и настраиваемые процессоры обеспечили нам более точный контроль и отказоустойчивость.
• Использование OTEL означало, что при необходимости мы могли экспортировать данные в несколько бэкэндов (например, ClickHouse + S3 + kafka).

Почему SigNoz

• Тесно интегрируется с OTEL и ClickHouse.
• По умолчанию он предоставляет UI для трассировки, дашборды для метрик и систему алёртинга.
• В отличие от SaaS-инструментов, он имеет открытый исходный код и является расширяемым — вы можете модифицировать экспортёр, менять схему ClickHouse и напрямую анализировать работу запросов.
• У него очень активная поддержка сообщества.

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

3. Наблюдение за стеком наблюдаемости

Наблюдаемость не будет полной, если вы не можете наблюдать за самим стеком наблюдаемости.
Наш конвейер телеметрии оснащен Prometheus и коллекторами OTEL, но с одной особенностью: мы создали устойчивый уровень сбора метрик с буферизацией через Kafka, который устраняет необходимость в статических scrape-таргетов Prometheus и допускает простои сервера Prometheus.

PS: Мы решили не настраивать отдельный конвейер Signoz + CH для этого, поскольку настройка еще одного кластера CH + ансамбля Zookeeper потребовала бы слишком больших затрат на обслуживание ради наблюдаемости самого конвейера наблюдаемости, который работает на фиксированных инстансах.

3.1 Мотивация дизайна

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

Мы хотели:

• Динамическое автообнаружение — не требуется ручное изменение конфигурации при масштабировании экземпляров.
• Отказоустойчивость — метрические данные должны выдерживать кратковременные сбои Prometheus.
• Единый путь приема данных — объединение телеметрии на уровне инфраструктуры и приложения в один поток.

Поэтому вместо того, чтобы позволить Prometheus напрямую опрашивать каждый endpoint, мы перевернули архитектуру: Prometheus получает метрики всего из одного OTEL-коллектора, который читает метрики из Kafka, куда отправляют их все компоненты конвейера.

3.2 Примеры конфигураций коллектора

На каждом хосте (узлы Kafka, ClickHouse, OTEL Collector):

Экспортирует метрики Prometheus в Kafka.

receivers:
  prometheus:
      config:
        global:
          scrape_interval: 30s
        scrape_configs:
          - job_name: otel-collector-binary
            static_configs:
              - targets: ['localhost:8888'] # OTEL internal metrics
  hostmetrics:
      collection_interval: 30s
      scrapers:
        cpu: {}
        load: {}
        memory: {}
        disk: {}
        filesystem: {}
        network: {}
processors:
  resourcedetection/aws:
      detectors: [ec2]
      timeout: 2s
      override: true
      ec2:
        tags:
          - aws:autoscaling:groupName
          - service_name
          - environment_name
          - cluster
          - provisioned-by-user
          - resource_type
exporters:
  kafka:
    brokers: ["observibility-kafka.prod.local:<port>"]
    topic: "pipeline-metrics"

Центральный коллектор (обращённый к Prometheus):

Использует данные из Kafka, повторно выставляет метрики для Prometheus.

receivers:
  kafka:
    brokers: ["kafka-1:9092", "kafka-2:9092"]
    topic: "pipeline-metrics"

exporters:
  prometheus:
    endpoint: "0.0.0.0:9464"

service:
  pipelines:
    metrics:
      receivers: [kafka]
      exporters: [prometheus]

Конфигурация Прометея

Prometheus требуется только один таргет:

scrape_configs:
  - job_name: 'otel-metrics-aggregator'
    static_configs:
      - targets: ['otel-central-collector:9464']

Это делает настройку полностью независимой от топологии — можно масштабировать Kafka, ClickHouse или OTEL-коллекторы вверх/вниз, не меняя YAML-конфигурацию Prometheus.

3.3 Что мы отслеживаем

4. Инструменты для отслеживания

Масштабное отслеживание требует тщательной координации между агентом OTEL и коллекторами, а также использования специальных инструментов для работы с устаревшим кодом. Вот обзор того, как мы справляемся с этим на нашей платформе.

Обзор агента + коллектора

• Агент OTEL: запускается вместе с приложениями (sidecar или in-process), перехватывая входящие и исходящие запросы для создания интервалов. Для HTTP, gRPC и поддерживаемых фреймворков агент автоматически инструментирует запросы.
• Сборщик OTEL: получает данные от агентов, выполняет батчинг, семплинг и обогащение, а также экспортирует их в Kafka для обеспечения устойчивости. Коллектор SigNoz из Kafka записывает данные в ClickHouse для хранения и визуализации.

Такое разделение гарантирует, что агенты остаются легкими, в то время как коллекторы выполняют тяжелую работу, такую ​​как батчинг, backpressure и экспорт в больших масштабах.

Кастомное инструментирование для устаревших систем

Некоторые из наших сервисов используют старые версии фреймворков и библиотек, которые не инструментируются автоматически OTEL:

• Vert.x 3.9: Требуется специальный инструментарий для корректного захвата асинхронных циклов событий.
• Клиенты SQL (старые версии JDBC) и клиенты Redis: мы написали небольшие оболочки OTEL для захвата областей запросов/команд без изменения существующей бизнес-логики.

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

Семплинг

Мы применяем вероятностный семплинг 1% для трейсов:

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

Полезный совет:
если уровень ошибок у вас крайне низок, рассмотрите tail-based sampling (сбор всех трейсов с ошибками) в сочетании с вероятностной выборкой, чтобы не пропустить критические события сбоя.

Метрики охвата

• Все метрики интервала (задержка, количество ошибок, длительность) хранятся в ClickHouse.
• Это позволяет строить дашборды без необходимости повторной обработки необработанных трассировок.

# Sample signoz config for span metrics
signozspanmetrics/delta:
    aggregation_temporality: AGGREGATION_TEMPORALITY_DELTA
    dimensions:
    - default: default
      name: service.namespace
    - default: default
      name: deployment.environment
    - name: signoz.collector.id
    dimensions_cache_size: 100000
    latency_histogram_buckets:
    - 100us
    - 1ms
    - 2ms
    - 6ms
    - 10ms
    - 50ms
    - 100ms
    - 250ms
    - 500ms
    - 1000ms
    - 1400ms
    - 2000ms
    - 5s
    - 10s
    - 20s
    - 40s
    - 60s
    metrics_exporter: signozclickhousemetrics

Вспомогательные библиотеки OTEL

Для поддерживаемых библиотек OTEL предлагает богатый набор инструментов в opentelemetry-contrib. Он включает в себя автоматический инструментарий для баз данных, систем обмена сообщениями, веб-фреймворков и многого другого. Использование этих инструментов снижает потребность в специальных оболочках и обеспечивает совместимость с будущими версиями.

5. Итоги и что дальше

В этой части мы рассмотрели общие принципы проектирования и эксплуатации платформы наблюдения промышленного уровня с использованием SigNoz, ClickHouse и OpenTelemetry. Ключевые выводы:

• Масштабируемая архитектура: разделение приема, обработки и хранения позволяет системе обрабатывать миллионы показателей и трассировок в секунду, оставаясь при этом устойчивой к скачкам нагрузки.
• Практические уроки настройки: такие конфигурации, как ограничения памяти коллектора OTEL, пакетирование Kafka и размеры буфера Lambda, имеют решающее значение для надежности и оптимизации затрат.
• Самонаблюдаемость: Инструментирование самого конвейера наблюдаемости обеспечивает динамический мониторинг метрик Prometheus и обратного давления, без необходимости управлять сотнями статических конфигураций сбора данных.
• Трейс-инструментирование: правильная настройка агента и коллектора, а также специализированный инструментарий для устаревших библиотек обеспечивают полноту распределённых трейсов, в то время как вероятностная выборка позволяет контролировать затраты на хранение и прием данных.

Эта статья посвящена вопросам «почему» и «как» на архитектурном уровне. Мы надеемся, что она даст вам конкретные идеи и практические рекомендации по созданию и настройке собственного телеметрического стека.

Что дальше (часть 2):
В следующей публикации мы подробно рассмотрим сервер SigNoz, настройки коллектора и схемы ClickHouse. Вы получите подробную информацию о:

• Как коллекторы обрабатывают пакетирование, повторные попытки и обратное давление.
• Шаблоны проектирования схемы Signoz *MergeTree для метрик и диапазонов с высокой кардинальностью, а также то, как она использует отпечатки для оптимизации хранения.
• Однобинарный UI-сервер SigNoz с компонентами alert-manager и query-builder.

Оставайтесь с нами, если хотите узнать подробности, выходящие за рамки документации, — то, что делает платформу наблюдения за производством по-настоящему надежной и производительной. 👋

2 часть статьи на момент публикации перевода так и не вышлаю (примечание переводчика).

Это перевод оригинальной статьи Scaling Prometheus Metrics with Grafana Mimir: Step-by-Step Setup and Demo.

Prometheus отлично подходит для мониторинга, но при масштабировании возникают реальные проблемы, такие как высокая кардинальность, долговременное хранение и высокая доступность. Вот тут-то и приходит на помощь Grafana Mimir.

На недавнем митапе Grafana & Friends x Kubernetes я выступил с докладом и живой демонстрацией того, как Grafana Mimir может масштабировать метрики Prometheus.

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

Что мы рассмотрим

Ограничения Prometheus
Введение в Grafana Mimir
Архитектура и компоненты Mimir
Конфигурация remote write из Prometheus → Mimir
Настройка Grafana → Mimir в качестве источника данных
Визуализация метрик + изучение административного интерфейса

Почему именно Grafana Mimir?

Prometheus — мощная система сбора метрик, но у неё есть следующие проблемы:

• Отсутствует встроенная кластеризация или высокая доступность.
• Только локальное хранилище
• Интенсивное использование памяти при работе с данными высокой кардинальности.

Grafana Mimir — это высокомасштабируемый backend для долгосрочного хранения метрик Prometheus, который решает все эти проблемы.

Архитектура Mimir Architecture (краткий обзор)

Mimir подразделяется компоненты:

• Distributor — принимает remote write от Prometheus
• Ingester — временно хранит данные
• Compactor — компактизирует блоки
• Querier — обрабатывает запросы
• Store-gateway — извлекает блоки из объектного хранилища.

Это делает Mimir горизонтально масштабируемым и совместимым с HA.

Пошаговая настройка

Запуск экземпляра EC2 (виртуальной машины)

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

Настройка Prometheus

Скачайте и распакуйте Prometheus:

wget https://github.com/prometheus/prometheus/releases/download/v2.52.0/prometheus-2.52.0.linux-amd64.tar.gz
tar -xvzf prometheus-2.52.0.linux-amd64.tar.gz
cd prometheus-2.52.0.linux-amd64

Отредактируйте файл prometheus.yml, чтобы включить удаленную запись в Grafana Mimir:

Добавьте удаленную запись

remote_write:
- url: http://localhost:9009/api/v1/push

Настройка Grafana Mimir

Скачайте Mimir:

wget https://github.com/grafana/mimir/releases/download/v2.12.0/mimir-linux-amd64.zip
unzip mimir-linux-amd64.zip
chmod +x mimir

Создайте конфигурационный файл demo.yaml (базовая настройка для одного процесса):

# Do not use this configuration in production.
# It is for demonstration purposes only.
multitenancy_enabled: false

blocks_storage:
  backend: filesystem
  bucket_store:
    sync_dir: /tmp/mimir/tsdb-sync
  filesystem:
    dir: /tmp/mimir/data/tsdb
  tsdb:
    dir: /tmp/mimir/tsdb

compactor:
  data_dir: /tmp/mimir/compactor
  sharding_ring:
    kvstore:
      store: memberlist

distributor:
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: memberlist

ingester:
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: memberlist
    replication_factor: 1

ruler_storage:
  backend: filesystem
  filesystem:
    dir: /tmp/mimir/rules

server:
  http_listen_port: 9009
  log_level: error

store_gateway:
  sharding_ring:
    replication_factor: 1

Настройка Grafana

Запуск Grafana:

sudo systemctl start grafana-server

Подключите Mimir к Grafana

• Войдите в Grafana по адресу http://<ip>:3000(по умолчанию: admin/admin)
• Перейдите в Settings → Data Sources → Add Data Source
• Выберите Prometheus

Теперь Grafana подключена к Mimir!

Обзор административного интерфейса Mimir

Эта конфигурация демонстрирует, насколько легко масштабировать Prometheus с помощью Grafana Mimir — без изменения способа сбора метрик.

Это перевод оригинальной статьи What Kubernetes Logs Won’t Tell You During an Incident.

Если вы достаточно долго используете Kubernetes в продакшене, то уже знаете этот ритуал:

1. Срабатывает алерт.
2. Вы открываете логи.
3. Они выглядят нормально.
4. А продакшен всё ещё «горит».

Это не плохая наблюдаемость. Это неоправданное доверие.

Логи Kubernetes отлично показывают, что, по мнению вашего приложения, произошло. Но они совершенно не помогают понять, почему система ведет себя именно так. Именно в этот промежуток времени тратится большая часть времени впустую во время инцидентов.

Вот что обычно не показывают логи — и на что следует обратить внимание вместо них.

1. В логах не отображается информация о нехватке ресурсов (пока не станет слишком поздно).

В ваших логах указано:

«Request processed successfully»

Ваши пользователи говорят:

«Приложение работает ужасно медленно».

Чего вам не расскажут логи:

• Ваши поды ограничены по CPU
• Ваши контейнеры технически "работают".
• Ваши запросы находятся в очереди, а не завершаются с ошибкой.

Ограничение использования CPU не приводит к сбоям в работе подов. Оно незаметно увеличивает задержку. Kubernetes будет спокойно поддерживать работоспособность вашего контейнера, получая при этом 20 мс ресурсов CPU каждые 100 мс.

К тому моменту, когда в логах появляются сообщения о таймаутах, ущерб уже нанесен.

Что действительно помогает

• Метрики CPU контейнера и его ограничение
• Нагрузка CPU на узле
• Процентили задержки запроса (не средние значения)

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

2. Логи не объясняют, почему поды перезапускаются

Вы видите:

«Container terminated with exit code 137»

Отлично. Это ничего полезного вам не скажет.

Логи не скажут:

• Был ли pod убит (OOM-killed) из-за нехватки ресурсов на узле
• Выселил ли его kubelet по собственной инициативе
• Был ли ограничен другим нагрузкой другого процесса

Логи контейнера обрываются внезапно — потому что контейнер так и не успел зафиксировать собственную гибель.

Что действительно помогает

• Последнее состояние pod (OOMKilled или Evicted)
• События, связанные с нехваткой памяти узла
• Какие ещё pod одновременно вызвали всплеск потребления памяти?

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

3. Логи не показывают решения планировщика (scheduler)

Деплой «застрял».

В логах отображается следующее:

«Scaled to 10 replicas»

Но реально работает только 6 подов.

В логах вы не узнаете:

• Почему планировщик не может разместить оставшиеся pod
• Какие ограничения препятствуют планированию?
• Провал упаковки в контейнеры произошел незаметно.

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

Что действительно помогает

• События планирования подов
• Доступные vs запрошенные ресурсы узла
• Конфликты affinity и taint

Суровая правда: большинство «ошибок Kubernetes» во время инцидентов связаны с математическими ошибками планировщика.

4. Логи не фиксируют ухудшение качества сети.

Логи говорят:

«Request sent»

Они не говорят:

• Разрешение DNS-запроса заняло 800 мс.
• Между узлами резко возросла потеря пакетов.
• Правила kube-proxy вышли из строя

С точки зрения приложения, всё работает нормально. С точки зрения пользователя, всё тормозит.

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

Что действительно помогает

• метрики задержки DNS
• Потеря пакетов между узлами
• Частота повторных попыток подключения

Совет от опытного пользователя: если работа нескольких сервисов
тормозит, перестаньте читать логи и начните проверять DNS и сеть.

5. Логи обманывают во время Rolling Updates

Во время rollout’ов логи могут вводить в заблуждение.

Вы увидите:

«Pod started successfully»

Чего вам не расскажут логи:

• Проверки на готовность были пройдены слишком рано.
• Трафик попал в pod до того, как кеши прогрелись.
• Старые pod освобождались слишком медленно (или вообще не освобождались)

Приложение считает, что готово. Система — нет.

Что действительно помогает

• Реальные показатели успешности трафика во время rollout
• Задержка готовности против фактической готовности
• Поведение балансировщика нагрузки при исчерпании ресурсов соединения

Урок усвоен на горьком опыте: зелёное развертывание — это не то же самое, что безопасное внедрение.

6. Логи не показывают проблемы control plane

В логах вашего приложения мало информации.
Ваш кластер работает медленно.

В логах вы не узнаете что:

• API-сервер ограничивает количество запросов.
• Контроллеры отстают
• Watch-события задерживаются

С точки зрения рабочей нагрузки, проблема заключается в Kubernetes — но Kubernetes не сообщает об этом вашему приложению.

Что действительно помогает

• Задержка API-сервера
• Метрики ограничения запросов
• Задержка reconcile контроллеров

Если kubectl работает медленно во время инцидента — это сигнал, а не просто неудобство.

7. Логи не показывают того, чего не произошло

Это самая опасная вещь.

В логах показано, что произошло.
В них не показано:

• Запросы, которые так и не дошли до pod
• Pod, которые так и не получили трафика
• Джобы, которые не запустились

Отсутствие логов редко рассматривают как данные — но во время инцидентов это часто главный сигнал.

Что действительно помогает

• Метрики трафика vs ожидаемый объём
• Коэффициенты отброса запросов upstream
• Пропуски событий control plane

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

Главный вывод: логи — это запаздывающий сигнал

Логи показывают симптомы, а не причины.

К тому моменту, когда логи «кричат»:

• Задержка уже плохая.
• Пользователи уже это заметили
• Инцидент уже идёт

Опытные инженеры не перестают использовать логи — они перестают полагаться только лишь на них.

Что я теперь проверяю до логов?

В каждом инциденте я неукоснительно следую одному и тому же списку правил:

• CPU и память на узлах
• События планирования подов
• Сигналы троттлинга и eviction-сигналы
• DNS и задержка сети
• Состояние API-сервера
• Несоответствие между трафиком и пропускной способностью

Только после этого я читаю логи — чтобы подтвердить, а не чтобы обнаружить.

Финал

Если ваше реагирование на инцидент начинается и заканчивается логами, значит, отладка выполняется слишком поздно.

Инциденты в Kubernetes происходят в пространстве между компонентами — scheduler, узлы, сеть, control plane — и логи никогда не предназначались для того, чтобы рассказывать эту историю.

Логи не лгут. Они просто не рассказывают всей правды.

А в продакшене половина правды — это причина, почему простои длятся дольше, чем должны.