|
1 | 1 | # Преобразование логов http accesslog в метрики с vector.dev |
2 | 2 |
|
3 | | -В данном каталоге лежат файлы описывающий подход, позволяющий генерировать метрики из логов без переписывания кода трансформов под каждый сервис. |
| 3 | +В данном каталоге лежат файлы описывающий подход, позволяющий генерировать [метрики из логов](https://vector.dev/docs/reference/configuration/transforms/log_to_metric/) без переписывания кода трансформов [vector.dev](https://vector.dev/) под каждый сервис. |
4 | 4 |
|
5 | | -**Внимание!** [Версия v1](https://github.com/vseinstrumentiru/vector.dev-metrics-to-logs-helper/tree/1.0.0) содержала [баг #1](/../../issues/1) который проявлялся, только если вы добавляли разные определения метрик (разные лейблы, разные фильтры). В текущей версии это исправлено (см. [новый граф обработки](docs/vector_topology-separate-metric-fileters.svg)). |
| 5 | +**Описание:** |
6 | 6 |
|
7 | 7 | 1. Полагаемся на то, что все сервисы пишут логи в фиксированном формате JSON и имеют одинаковый набор обязательных полей. См. [example_logs] |
8 | 8 | 2. Для кодогенерации использован Ansible и jinja2 шаблоны. Генерируем toml файлы конфигурации vector.dev и тесты к ним, где нужно. |
9 | 9 | 3. Метрики определяются в файле [ansible-playbook/vars/metrics-catalog.<env>.yml], после этого запускаем генерацию через ansible. См пример в Makefile. По умолчанию генерируется для `env=testing`, чтобы генерировать для production запускать `VECTOR_ENV=production make <команда>` |
10 | | -4. Отдельной задачей конфигурации выгружаются на серверы с агрегаторами vector.dev, и для применения новой конфигурации выполняется перезапуск процесса vector |
| 10 | +4. Отдельной задачей конфигурации выгружаются на серверы с агрегаторами vector.dev, и для применения новой конфигурации выполняется перезапуск процесса vector (здесь не приведены). |
| 11 | + |
| 12 | + |
| 13 | +## Как было раньше |
| 14 | + |
| 15 | +Каждый раз под новый источник мы писали новый код VRL, часто делая copy/paste с незначительными правками. Это могло занимать с отладкой и тестами весь рабочий день. |
| 16 | +Потому в 2023 нас это перестало устраивать и мы придумали это подход. Подробно читайте https://habr.com/ru/articles/809801/ и https://habr.com/ru/articles/864614/. |
11 | 17 |
|
12 | 18 | ## Что нам дал рефакторинг |
13 | 19 |
|
14 | 20 | * Мы вместо 5 часов теперь тратим 10-30 минут на добавление/изменение метрик с учетом выкатки на прод |
15 | 21 | * Появилась автоматическая валидация по схеме, теперь ошибку при описании метрки допустить сложнее |
16 | | -* Теперь для добавления новой метрки не нужно знать как это закодировать на языку VRL - достаточно YAML девелопера ) |
| 22 | +* Теперь для добавления новой метрки не нужно знать как это закодировать на языке VRL - достаточно YAML девелопера ) |
17 | 23 |
|
18 | 24 |
|
19 | 25 | ## Ограничения |
|
31 | 37 | 4. Выполните сборку и тесты `VECTOR_ENV=<env> make test-vector-transforms`, если не указать VECTOR_ENV, то используется `VECTOR_ENV=testing` |
32 | 38 | 5. Созданные файлы смотрите в каталоге [.generated/vector_config] |
33 | 39 |
|
| 40 | +## Граф компонентов vector.dev |
| 41 | + |
| 42 | +В приведенной конфигурации создается следующий граф компонентов: |
| 43 | + |
| 44 | + |
| 45 | + |
| 46 | + |
34 | 47 | ## Контакты |
35 | 48 |
|
36 | 49 | Если вам интересны подробности вы можете писать нам, см. сайт https://vitech.team/ ("По вопросам сотрудничества") или приходите работать к нам. |
|
0 commit comments