Comments 16
Хорошая штука, тоже пользуемся. Странно, что вопрос конфигурирования практически не раскрыт в статье, по умолчанию он загружает весь лог в память, что может очень лихо съесть всю память на сервере. Для отключения такого поведения есть параметр `seek_from_end`.
Также, nginx-clickhouse с недавнего времени выставляет эндпойнт с метриками для Prometheus, в которых рассказывает, сколько логов он записал в CH, а сколько отбросил, не сумев распарсить.
Ну и Dockerfile там в репо тоже есть, чтобы с rpm не возиться.
Также, nginx-clickhouse с недавнего времени выставляет эндпойнт с метриками для Prometheus, в которых рассказывает, сколько логов он записал в CH, а сколько отбросил, не сумев распарсить.
Ну и Dockerfile там в репо тоже есть, чтобы с rpm не возиться.
Стоило бы исправить spoiler для Json Файла дашборда или что еще лучше — сделать pr в репозиторий автора.
Да, действительно нужно было под сполер убрать — уже убрал.
Там 3 моих Pull request
github.com/mintance/nginx-clickhouse/pulls
Там 3 моих Pull request
github.com/mintance/nginx-clickhouse/pulls
del
Мы используем связку: nginx->rsyslog-kafka->kafka->ch(kafkaEngine->MV->mergetree)
Для логов лучше записывать в буфер движок, буфер сам скинет в mergetree.
Иначе можно накопить большое количество на данных на мердж.
Насколько я помню, плагин table в Grafana загружает все строки и только потом делает по ним пагинацию. Т.е. это пагинация на стороне фронт-энда. Если у вас будет значимое кол-во логов в базе — таблица может «подвесить» бразуер.
Делал тоже самое на коленке (простой nodejs udp-сервер). Мне сырые данные не нужны, только агрегированные, поэтому просто сохранял все данные в таблицу с типом Null и навешиваю на неё materialized views, поэтому на диск практически ничего не пишет.
Столкнулся с проблемой, что если nginx отдаёт данные из кеша, то в логах response_time = 0 из-за чего статистика получается далёко от реальности.
Ставил также модуль pinba для nginx, он показывал всё правильно, но получалась слишком замороченная установка.
Интересно, это как-то можно пофиксить? А то получается, что nginx постоянно напрягается, обрабатывая https и шифруя данные из кеша, но этого нигде не видно.
Столкнулся с проблемой, что если nginx отдаёт данные из кеша, то в логах response_time = 0 из-за чего статистика получается далёко от реальности.
Ставил также модуль pinba для nginx, он показывал всё правильно, но получалась слишком замороченная установка.
Интересно, это как-то можно пофиксить? А то получается, что nginx постоянно напрягается, обрабатывая https и шифруя данные из кеша, но этого нигде не видно.
Хорошее начинание, и очень приятно, что реализация весьма короткая, но у меня есть пара вопросов к реализации:
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, то утилита просто «сдается» и больше не пробует записать? То есть, к примеру, если кластер временно перегружен, то данные потеряются. Мне кажется, для различных задач могут быть предпочтительны разные подходы, и вряд ли пользователи ожидают такое поведение по умолчанию.
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, то утилита просто «сдается» и больше не пробует записать? То есть, к примеру, если кластер временно перегружен, то данные потеряются. Мне кажется, для различных задач могут быть предпочтительны разные подходы, и вряд ли пользователи ожидают такое поведение по умолчанию.
как бы есть всегда rabbitmq/kafka/etc
Безусловно. Однако это не отменяет ровно тех же соображений: любой сетевой сервис, будь то RabbitMQ или Kafka точно также может перестать на время принимать данные (даже если сам кластер абсолютно стабилен, это могут быть сетевые проблемы), и для надежной доставки нужно уметь перепосылать данные. Также, что ClickHouse, что любой другой сервис может быть подвержен временным перегрузкам (например при обновлении версии и временному выводу из строя одного из узлов), и иногда может отвечать с бОльшей задержкой, чем обычно. Отсутствие ограничение у размера буфера может привести к неограниченному росту потребления памяти демоном при каких-либо проблемах, что в конечном итоге приведет к тому, что либо этот демон упадет с OOM, либо это создаст проблемы для остальных сервисов, которые запущены на той же машине. В таком сценарии отсутствие чекпоинтов приведет к тому, что опять же часть данных не будет доставлена.
Соображения выше справедливы для любого локального агента, который доставляет данные в сторонний сервис, вне зависимости от характера этого сервиса.
Соображения выше справедливы для любого локального агента, который доставляет данные в сторонний сервис, вне зависимости от характера этого сервиса.
Вечер добрый. Автор стал отвечать в Issue. Может стоит создать issue на эти темы?
А есть что-нибудь человеческое для аналитики с Clickhouse по типу ELK?
Юскейс: хочу посмотреть все логи с request_time больше 3 секунд. А потом посмотреть топ-10 клиентов сделавших такие запросы? Исключив из них конкретный User-Agent? И всё это в 3 клика мышкой
Лучше так: nginx access logs -> fluentd -> clickhouse
Sign up to leave a comment.
Собираем логи из Nginx с помощью nginx-clickhouse, отправляем в Clickhouse и отображаем в Grafana