Пишем логи из Container Optimized Image в Yandex Cloud Logging при помощи Fluent Bit

В прошлом посте я рассказал, как доставить логи из systemd. Теперь давайте разберёмся, как доставлять логи контейнеризированного приложения.

Шаг 1. Пишем логи

Ну что ж, опять начнём с того, что набросаем демоприложение на питоне, которое будет для нас генерировать записи логов: logs.py.

import logging import random import sys import time  # Писать логи контейнера будем в STDOUT. Разбивать по severity будем при помощи парсера в Fluent-bit import uuid  logger = logging.getLogger(__name__)  # Зададим форматер чтобы позже по этому же шаблону парсить логи. formatter = logging.Formatter(     '[req_id=%(req_id)s] [%(levelname)s] %(code)d %(message)s' )  handler = logging.StreamHandler(stream=sys.stdout) handler.setFormatter(formatter)  logger.addHandler(handler)  # Опционально можно настроить уровень логирования по умолчанию logger.setLevel(logging.DEBUG)  # Мы могли бы обойтись и простым логированием случайных чисел, но я решил генерировать URL-подобные значения. PATHS = [     '/',     '/admin',     '/hello',     '/docs', ]  PARAMS = [     'foo',     'bar',     'query',     'search',     None ]  def fake_url():     path = random.choice(PATHS)     param = random.choice(PARAMS)     if param:         val = random.randint(0, 100)         param += '=%s' % val     code = random.choices([200, 400, 404, 500], weights=[10, 2, 2, 1])[0]     return '?'.join(filter(None, [path, param])), code  if __name__ == '__main__':     while True:         req_id = uuid.uuid4()         # создаем пару код и значение URL         path, code = fake_url()         extra = {"code": code, "req_id": req_id}         # Если код 200, то пишем в  лог с уровнем Info         if code == 200:             logger.info(                 'Path: %s',                 path,                 extra=extra,             )         # Иначе с уровнем Error         else:             logger.error(                 'Error: %s',                 path,                 extra=extra,             )         # Чтобы можно было погрепать несколько сообщение по одному request id в 30% случаев будем писать вторую запись         # в лог с уровнем Debug.         if random.random() > 0.7:             logger.debug("some additional debug log record %f", random.random(), extra=extra)          # Ждем 1 секунду, чтобы излишне не засорять журнал         time.sleep(1)

В принципе, всё просто и я постарался оставить комментарии, но я пройдусь ещё раз по основным пунктам.

Логи Docker-контейнера — это просто вывод STDOUT и STDERR. В приложении я решил не делить вывод по двум этим потокам, так как далее в парсере Fluent Bit у нас будет возможность распарсить строчку лога и вычленить оттуда уровень, с которым была сделана запись.

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

Шаг 2. Настраиваем развёртывание COI VM

Так как нам нужно развернуть как минимум два контейнера (контейнер с нашим приложением и логер-агент Fluent Bit), воспользуемся возможностью COI работать со спецификацией Docker Compose. Опишем в файле наши контейнеры. Репозиторий с моим образом не публичный — используйте свой. Например, так как в spec.yml.

version: '3.7' services:   logs:     container_name: logs-app     image: cr.yandex/crpk28lsfu91rns28316/dockerlogtest:2021.10.17-6166ecb     restart: always     depends_on:       - fluentbit     logging:       # Fluent-bit понимает логи в этом формате       driver: fluentd       options:         # куда посылать лог-сообщения, необходимо что бы адрес         # совпадал с настройками плагина forward         fluentd-address: localhost:24224         # теги используются для маршрутизации лог-сообщений, тема         # маршрутизации будет рассмотрена ниже         tag: app.logs    fluentbit:     container_name: fluentbit     image: cr.yandex/yc/fluent-bit-plugin-yandex:v1.0.3-fluent-bit-1.8.6     ports:       - 24224:24224       - 24224:24224/udp     restart: always     environment:       YC_GROUP_ID: e23j5q1nhth94apeduuh     volumes:       - /etc/fluentbit/fluentbit.conf:/fluent-bit/etc/fluent-bit.conf       - /etc/fluentbit/parsers.conf:/fluent-bit/etc/parsers.conf

В контейнер Fluent Bit дополнительно передаём переменную окружения YC_GROUP_ID. Она понадобится нам для настройки плагина yc-logging, скажет ему, куда писать наши логи, и содержит id группы логирования.

Далее нам понадобится принести на ВМ конфиги. Сделаем это по инструкции, только сейчас всё проще и KMS нам не понадобится.

Шаг 3. Настраиваем чтение логов из контейнера

#cloud-config write_files:   - content: |       [SERVICE]           Flush         1           Log_File      /var/log/fluentbit.log           Log_Level     error           Daemon        off           Parsers_File  /fluent-bit/etc/parsers.conf        [FILTER]           Name parser           Match app.logs           Key_Name log           Parser app_log_parser           Reserve_Data On        [INPUT]           Name              forward           Listen            0.0.0.0           Port              24224           Buffer_Chunk_Size 1M           Buffer_Max_Size   6M        [OUTPUT]           Name            yc-logging           Match           *           group_id        ${YC_GROUP_ID}           message_key     text           level_key       severity           default_level   WARN           authorization   instance-service-account     path: /etc/fluentbit/fluentbit.conf   - content: |       [PARSER]           Name   app_log_parser           Format regex           Regex  ^\[req_id=(?<req_id>[0-9a-fA-F\-]+)\] \[(?<severity>.*)\] (?<code>\d+) (?<text>.*)$           Types  code:integer     path: /etc/fluentbit/parsers.conf  users:   - name: username     groups: sudo     shell: /bin/bash     sudo: [ 'ALL=(ALL) NOPASSWD:ALL' ]     ssh-authorized-keys:       - ssh-rsa AAAA

Теперь подробнее о том, зачем нам нужна каждая часть конфига user-data.yaml, представленного выше. В секции SERVICE указаны настройки самого приложения Fluent Bit (например, период, с которым оно отправляет логи). Подробнее можно прочитать в документации.

[SERVICE]     Flush         1     Log_File      /var/log/fluentbit.log     Log_Level     error     Daemon        off     Parsers_File  /fluent-bit/etc/parsers.conf

В секции INPUT описано, откуда и как забирать логи.

[INPUT]     Name              forward     Listen            0.0.0.0     Port              24224     Buffer_Chunk_Size 1M     Buffer_Max_Size   6M

Для работы с логами в формате Fluentd и Fluent Bit нужно использовать инпут с типом forward. О других типах инпутов читайте в документации. А также у меня есть инструкция, как работать с systemd  инпутом Fluent Bit.

Тут вроде всё понятно: Fluent Bit слушает логи на порту 24224. Именно туда мы велели Docker Compose отправлять логи нашего приложения в соответствующем конфиге выше.

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

Для этого в файле parsers.conf мы опишем парсер.

[PARSER]     Name   app_log_parser     Format regex     Regex  ^\[req_id=(?<req_id>[0-9a-fA-F\-]+)\] \[(?<severity>.*)\] (?<code>\d+) (?<text>.*)$     Types  code:integer

Мы воспользуемся парсером regex. Для его конфигурирования зададим регулярное выражение, при помощи которого разберём строчки лога. Из каждой строки мы извлечём поля: req_id, в которое клали уникальный id запроса, severity — уровень логирования, code — HTTP-код ответа, text — весь остальной текст.

Теперь с помощью парсера преобразуем логи. Для этого в основном конфиге добавим секцию FILTER.

[FILTER]     Name parser     Match app.logs     Key_Name log     Parser app_log_parser     Reserve_Data On

Тут мы говорим, что ищем только логи, тег которых совпадает с app.logs, берём из записи поле log, применяем к нему наш парсер app_log_parser, а все остальные поля лога сохраняем (Reserve_Data On).

Шаг 4. Отгружаем в Cloud Logging

Ну вот мы и подошли к отправке логов в облако. Так как мы разворачивали контейнер Fluent Bit из образа, куда уже добавлен плагин Yandex Cloud Logging, нужно лишь сконфигурировать секцию OUTPUT.

[OUTPUT]     Name            yc-logging     Match           *     group_id        ${YC_GROUP_ID}     message_key     text     level_key       severity     default_level   WARN     authorization   instance-service-account

Для отправки логов нужна авторизация. Мы воспользуемся самым простым способом: привяжем к ВМ сервисный аккаунт, которому выдадим роль, необходимую для записи логов logging.writer, или выше.

Отлично, теперь создадим ВМ с этими конфигами.

Нам понадобится id image, из которого мы будем разворачивать ВМ:

IMAGE_ID=$(yc compute image get-latest-from-family container-optimized-image --folder-id standard-images --format=json | jq -r .id)

Дальше подставим его в команду создания ВМ:

yc compute instance create \     --name coi-vm \     --zone=ru-central1-a \     --network-interface subnet-name=default-ru-central1-a,nat-ip-version=ipv4 \     --metadata-from-file user-data=user-data.yaml,docker-compose=spec.yaml \     --create-boot-disk image-id=$IMAGE_ID \     --service-account-name service-account

Когда ВМ развернётся и контейнеры на ней запустятся, можно перейти в Cloud Logging и посмотреть логи:

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

По ним можно пофильтровать. Например, запрос json_payload.code >= 400 найдёт все строчки логов, связанные с ответами, содержавшими ошибки.

Также можно найти все сообщения, относившиеся к обработке одного запроса, если пофильтровать по json_payload.req_id.

Подробнее о языке запросов можно прочитать в документации. Весь код из этой статьи на GitHub.

P. S. Yandex Cloud Logging — это serverless-сервис в Yandex.Cloud. Если вам интересна экосистема Serverless-сервисов и все, что с этим связано, заходите в сообщество в Telegram, где можно обсудить serverless в целом.