Собираем логи из Nginx с помощью nginx-clickhouse, отправляем в Clickhouse и отображаем в Grafana

[strangeman]

Хорошая штука, тоже пользуемся. Странно, что вопрос конфигурирования практически не раскрыт в статье, по умолчанию он загружает весь лог в память, что может очень лихо съесть всю память на сервере. Для отключения такого поведения есть параметр `seek_from_end`.

Также, nginx-clickhouse с недавнего времени выставляет эндпойнт с метриками для Prometheus, в которых рассказывает, сколько логов он записал в CH, а сколько отбросил, не сумев распарсить.

Ну и Dockerfile там в репо тоже есть, чтобы с rpm не возиться.

[chemtech]

Спасибо за поленый комментарий

[denaspireone]

Стоило бы исправить spoiler для Json Файла дашборда или что еще лучше — сделать pr в репозиторий автора.

[chemtech]

Да, действительно нужно было под сполер убрать — уже убрал.
Там 3 моих Pull request
github.com/mintance/nginx-clickhouse/pulls

[chemtech]

del

[Nengchak]

Мы используем связку: nginx->rsyslog-kafka->kafka->ch(kafkaEngine->MV->mergetree)

[sanchezzzhak]

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

[hagen1778]

Насколько я помню, плагин table в Grafana загружает все строки и только потом делает по ним пагинацию. Т.е. это пагинация на стороне фронт-энда. Если у вас будет значимое кол-во логов в базе — таблица может «подвесить» бразуер.

[morozovsk]

Делал тоже самое на коленке (простой nodejs udp-сервер). Мне сырые данные не нужны, только агрегированные, поэтому просто сохранял все данные в таблицу с типом Null и навешиваю на неё materialized views, поэтому на диск практически ничего не пишет.

Столкнулся с проблемой, что если nginx отдаёт данные из кеша, то в логах response_time = 0 из-за чего статистика получается далёко от реальности.
Ставил также модуль pinba для nginx, он показывал всё правильно, но получалась слишком замороченная установка.

Интересно, это как-то можно пофиксить? А то получается, что nginx постоянно напрягается, обрабатывая https и шифруя данные из кеша, но этого нигде не видно.

[youROCK]

Хорошее начинание, и очень приятно, что реализация весьма короткая, но у меня есть пара вопросов к реализации:

1) Исходя из следующего:

github.com/mintance/nginx-clickhouse/blob/master/nginx/nginx.go#L64
github.com/mintance/nginx-clickhouse/blob/master/main.go#L82

Я правильно понимаю, что утилита читает лог nginx до конца в память и только потом пытается отправить всё в nginx?

2) Исходя из следующего:

github.com/mintance/nginx-clickhouse/blob/master/main.go#L85

Правильно ли я понимаю, что если не удается записать в ClickHouse, то утилита просто «сдается» и больше не пробует записать? То есть, к примеру, если кластер временно перегружен, то данные потеряются. Мне кажется, для различных задач могут быть предпочтительны разные подходы, и вряд ли пользователи ожидают такое поведение по умолчанию.

[denaspireone]

как бы есть всегда rabbitmq/kafka/etc

[youROCK]

Безусловно. Однако это не отменяет ровно тех же соображений: любой сетевой сервис, будь то RabbitMQ или Kafka точно также может перестать на время принимать данные (даже если сам кластер абсолютно стабилен, это могут быть сетевые проблемы), и для надежной доставки нужно уметь перепосылать данные. Также, что ClickHouse, что любой другой сервис может быть подвержен временным перегрузкам (например при обновлении версии и временному выводу из строя одного из узлов), и иногда может отвечать с бОльшей задержкой, чем обычно. Отсутствие ограничение у размера буфера может привести к неограниченному росту потребления памяти демоном при каких-либо проблемах, что в конечном итоге приведет к тому, что либо этот демон упадет с OOM, либо это создаст проблемы для остальных сервисов, которые запущены на той же машине. В таком сценарии отсутствие чекпоинтов приведет к тому, что опять же часть данных не будет доставлена.

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

[chemtech]

Вечер добрый. Автор стал отвечать в Issue. Может стоит создать issue на эти темы?

[phikus]

А есть что-нибудь человеческое для аналитики с Clickhouse по типу ELK?
Юскейс: хочу посмотреть все логи с request_time больше 3 секунд. А потом посмотреть топ-10 клиентов сделавших такие запросы? Исключив из них конкретный User-Agent? И всё это в 3 клика мышкой

[morozovsk]

metabase + clickhouse-driver

[fessmage]

Лучше так: nginx access logs -> fluentd -> clickhouse