Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. В этой статье я расскажу вам о нашем опыте работы с vector.dev, как превращать логи в метрики обычным способом и как это можно автоматизировать до такой степени, что вам понадобиться только yaml-developer.

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

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

Предыстория

Vector.dev начали использовать за год до моего прихода в компанию. Когда я пришел, через него уже обрабатывались логи и метрики как-то уже считались по ним. Коллегами уже был сделан первый подход к облегчению работы по преобразованию логов в метрики – часть конфигураций была шаблонизирована, некоторые параметры вынесены в yaml файлы, а генерация и развертывание выполнялись через ansible. Мой приход ознаменовался испытательным сроком, а значит и испытаниями.

Прохожу посвящение

У нас в компании Ви.Tech, так получилось, что испытание – это погружение в vector.dev. Это тот инструмент должны знать все SR-инженеры, потому что это наш основной сервис для обработки логов в компании. 

Моей первой задачей было обеспечить сбор метрик по логам для подсчета SLI/SLO. Итак, передо мной логи доступа http-сервера nginx в виде JSON. JSON это уже хорошо, так как это структурированные логи.

Осталось малость:

• Изучить Vector Remap Language

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

• Добавить обработчики логов для новых метрик

С первым я справился достаточно быстро, потому что у vector.dev хорошая документация и даже есть online VRL playground, где можно потренироваться работать с языком VRL без установки vector себе локально.

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

Как мы добавляли подсчет метрик по логам раньше

Чтобы добавить подсчет метрики для одного сервиса нужно:

1. Скопировать кусок из нашего кода, вставить, поправить. Пример куска для копирования – новый трансформ mysvc-accesslog-metrics-prepare

   

   Это такой фильтр по path и нужен для того, чтобы отобрать подходящие пути из URL path и только эти логи считать в метрику. При этом видно, что приемник “inputs” определенный и он не един для всех, его надо менять каждый раз.

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

   

3. Еще докинуть строчку в общий файл. Все метрики публикуются через экспортер Prometheus в эндпоинт /metrics. Трансформ access_log_to_metrics служит источником всех метрик для экспортера, потому нам нужно подключать в него новый источник метрик mysvc-accesslog-metrics-prepare. Забудешь добавить – метрик новых не будет.

   

4. А еще и тесты добавить и отладить это все… и так для каждого сервиса.

В итоге мог уйти весь день на написание кода и отладку.

Мне предстояло сделать такое для десятка сервисов. 

Тяжко. Лениво. Что делать? Переделать!

Хватит пасты! Рефакторинг – переделываю подсчет метрик по логам запросов http-сервера. 

Что переделал

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

   • имя сервиса - service_name

   • метод - method

   • путь - path

   • код ответа - status

2. Создал новый yml-файл описания метрик (у нас был и раньше подобный, но гораздо менее гибко настраиваемый). Часть файла представлена ниже

   

3. Создал JSON-схему для упрощения написания yaml и его валидации. Если использовать Visual Studio Code, то вы получите выпадающие подсказки и проверку yml на соответствие схеме на лету. Часть ее представлена ниже

   

   В текущей версии схемы поддерживается только определение метрик типа счетчик (metric_type: counter) и гистограмма (metric_type: histogram), просто потому, что другие типы нам пока не были нужны.

4. Создал новые обработчики (трансформы) для vector.dev с использованием шаблонов jinja. Часть кода с шаблонами ниже

   

5. Добавил также и кодогенерацию тестов. Часть кода теста приведена ниже

   

Защищайтесь! - Взрыв кардинальности

Когда у вас слишком много значений в метке, например, если в path попадает url вида /products/product-name, где product-name может быть любым – это значит возможен взрыв кардинальности. У нас на сайте vseinstrumenti.ru более 1 миллиона товаров, это значит миллион уникальных product-name. Когда к нам приходит поисковый робот он обходит быстро эти страницы, тут мы и получаем взрыв кардинальности - на выходе метрик становится десятки тысяч строк, а объем ответа с эндпоинта /metrics может расти до десяток в сотен мегабайт. При этом коллектор метрик просто не успеет их собрать и вы перестанете получать метрики. 

Для решения этой проблемы мы ранее использовали отдельный файл с описаниями замен через regexp. Это было неудобно – приходилось дублировать условие совпадения path в двух местах: в файле описания условия отбора и файле описания замен path по regexp. После переделки стало удобнее. 

Теперь для таких случаев мы задаем условие по совпадению регулярного выражения (поле re в условии отбора логов в metrics-catalog.yml) и сразу указываем значение для замены в label_override – это то, что будет в метке path в итоговой метрике. 

Посмотрите на пример metrics-catalog.yml

В итоге мы увидим такую серию метрики типа counter
vi_http_requests_total{path=”/products/:name”, method=”GET”, status=”200”, cluster_name=”k8s_с1”, container_name=”site-app”, service_name=”site” } 

В этом случае все разнородные адреса в метке path будут заменены на /products/:name и вместо десятков тысяч строк будут лишь сотни, как мы ожидаем.

Идея для развития

Если присмотреться к нашим регулярным выражениям в label_override, то можно увидеть избыточность, а именно часть (?P<name>(тут само выражение)). Так мы даем имя одной из групп регулярного выражения, но зачем? 

А затем, что у нас была идея автоматизировать установку значения label_override. Написать инструмент, который бы посмотрел в re: ^/product/(?P<name>([^/]+-\\d+/))$, нашел имя name внутри (?P<name>(тут само выражение)) и сконструировал бы значение вида /products/:name для label_override. 

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

Дополнительная защита от взрыва кардинальности

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

Для защиты от этого vector.dev предлагает компонент tag_cardinality_limit. Он следит за количеством значений в метках и итоговым количеством метрик. Если кардинальность переваливает за заданный предел, то он может отбрасывать часть меток метрики или отбрасывать ее целиком. 

Мы используем этот компонент с такими настройками:

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

Мы собираем внутренние метрики компонентов vector – это дает возможность мониторить его работу в нужных нам частях. В этом случае нам достаточно настроить алерт на рост метрики component_discarded_events_total для компонента с именем “metrics-cardinality-limiter”, что позволит нам обратить внимание на проблему и перейти к устранению причины – найти высоко кардинальную метрику. Если вы используете Victoria Metrics для хранения метрик, как и мы, то можете проверить наличие высоко кардинальных метрик в Cardinality Explorer.

Как добавляем метрики теперь

1. Определяем метрику и условия отбора логов в метрику в файле metrics-catalog.yml

   

   Кроме фильтров отбора метрик мы добавили еще поддержку исключения из подсчета. Например, нужно исключить из подсчета все запросы с method=”OPTION” (cм. в metrics-catalog секцию exclude_events).

2. Генерируем новый конфиг и выкатываем через CI/CD

   

3. Готово. Метрики уже считаются!

Что дала нам переделка подсчета метрик

1. Экономию времени инженеров – вместо 3-5 часов кодинга на VRL с отладкой и борьбы с toml файлами, теперь достаточно 20-30 минут.

2. Упрощение поддержки – теперь не нужно глубоко разбираться в vector, достаточно описать метрики в yml, т.е. достаточно yaml-девелопера.

На самом деле на этом мы не остановились. Позже, с изобретением нами Unified Log Pipeline, это решение было для него адаптировано и сделало его еще более гибким – оно теперь подходит для любых логов.

Как это может быть полезно вам

Вы можете ознакомиться с нашим открытым кодом к vector.dev для преобразования логов в метрики тут https://github.com/vseinstrumentiru/vector.dev-metrics-to-logs-helper.
В нем представлены:

• базовый набор файлов для ansible и vector

• metrics-catalog.yml

• JSON-схема для metrics-catalog.yml

• пример логов

• Makefile для запуска задач

• Readme как это все запустить

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

Если появятся вопросы по коду или как его завести – прошу писать мне тут в личные сообщения или на почту. Актуальные контакты есть в https://github.com/r3code .

А если у вас есть вопросы по самому vector.dev, то предлагаю вам заглянуть в группу русскоговорящего сообщества Vector в Telegram https://t.me/vectordev_ru