Чем собирать статистику запросов от клиентов на сервере?

Question

[Алексей Денисов]

Есть небольшой сервис NGINX + PHP + MSQL,
требуется вести статистику запросов от клиента, с дальнейшим изучением
и возможностью Сортировки данных по ip адресу, времени и строке запроса.
Name => { IP , Time, Request}

Не могу сообразить что использовать для этой цели:
Redis, MySql, Ассоциативный многомерный массив ?

Изначально думал Redis , но с ним пока не знаком,
имеется ли возможность вывода и сортировки данных по ключу Name?
MySql наверное нет, так как добавляются новые строки(100-300 за сутки) для каждого Name и это наверное "Из пушки по воробьям".

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

example

Comments

[сергей кузьмин]

Алексей Денисов Prometheus / InfluxDB - заточены под это дело

[alexalexes]

Name => { IP , Time, Request}

А еще не забудьте user agent, proxy.

Redis, MySql, Ассоциативный многомерный массив ?

При таком выборе инструментов я бы размышлял так:
"Если для получения данных аналитики нельзя сделать запрос в формате SQL, то это не хранилище данных, а просто лог, в крайнем случае - кэш".

MySql наверное нет, так как добавляются новые строки(100-300 за сутки)

Для реляционной СУБД - смешные цифры, даже при тестировании так слабо не нагружают.

Answer 1

[Everything_is_bad]

MySql наверное нет, так как добавляются новые строки(100-300 за сутки) для каждого Name и это наверное "Из пушки по воробьям".

это ты сейчас взял и придумал, всё ок для твоих объемов c mysql для этого, используй его.

ЗЫ хотя тут и текстовые логи тоже без проблем подходят.

Comments

[Алексей Денисов]

Да всё верно, как мне кажется MySql не создана для постоянного Добавления строк в таблицы, разве нет?

И потом пока не понятно,
Если клиентов около 1000 и примерно 100 Запросов от каждого, это какая логика получается?
Для каждого клиента создавать таблицу, или свой столбец - пока не понятно.

Один клиент может сделать 10 запросов в сутки, а другой 300 запросов

[Everything_is_bad]

Алексей Денисов,

как мне кажется MySql не создана для постоянного Добавления строк в таблицы, разве нет?

уже второй какую-то ерунду придумал и написал.

Для каждого клиента создавать таблицу, или свой столбец - пока не понятно.

ой приехали, ты еще и базовые знания реляционных субд не осилил. Ни то, ни другое. Одна таблица с ссылкой на клиента, если про него ты уже хранишь что-то в базе.

[Ипатьев]

Алексей Денисов, вот правда, вы сейчас удивили. Какие ещё колонки?! Как вы себе это представляете? Вроде давно сюда пишете, за это время обычно такие базовые вещи осваиваются. Ну кроме "MySql не создана для постоянного Добавления строк в таблицы" - эта ересь каждому второму нубу в голову приходит, и там сидит прочно.

Но по структуре это уже должно быть на уровне таблицы умножения, от зубов отскакивать:
Сходные по структуре данные пишутся в одну таблицу. Строками.
Client, IP , Time, Request. Что здесь сложного?
Ну только как правильно сказано выше, вместо имени пишется id клиента из соответствующей таблицы.

[Алексей Денисов]

Спасибо всем за информативные комментарии.

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

Значит все гораздо проще,
Создаю таблицу в которую с помощью PHP пишу строку с нужными параметрами.

По идее требуется проверять порядка 10 url адресов, которые запрашивает клиент.
Вот в этих PHP и будет осуществляться запись в Таблицу.

(Надеюсь верное решение,
Не откажусь от комментариев...)

Answer 2

[Ипатьев]

> 100-300 за сутки для каждого. логи сервера не подходят для этого.

довольно забавное заблуждение.
Редис вам понадобится при нагрузках 100-300 в секунду. Для всего, что меньше, идеально подойдут текстовые логи. А вы заодно, освоите один из самых базовых навыков для работы с сервером.

Логи пишете в файл. чтобы получить лог по определенному name пишете в консоли
grep name log.txt
Ну или при желании читаете в пхп и выводите в красивой табличке
Ну или совсем лень, то можно писать в БД и выбирать запросами.

Answer 3

[ky0]

Берёте любую систему централизованного логирования (например, Graylog) - и отправляете в него логи веб-сервера. Получаете ровно то, что хотите - возможность отображения и агрегации данных по определённым полям.

Ассоциативный многомерный массив, кек...

Answer 4

[Alexey Dmitriev]

В гугле что-то типа "insert nginx logs to mysql" + nginx custom log с нужными столбцами

Comments

[Алексей Денисов]

Проблем с использованием mysql вроде нет, просто он и так Активно используется в работе сервиса.
Каждый запросы от клиента использует запрос в БД для вытягивания данных.
Поэтому думаю что накладно будет ещё раз обращаться к БД для записи логов.

[Ипатьев]

Алексей Денисов, а вы не думайте. При отсутствии знаний думать вообще вредно. Попробуйте, посмотрите, будет ли накладно. Так вы получите практический опыт, а не останетесь со своим суеверием.

[Ипатьев]

Alexey Dmitriev я так понимаю, что на момент запроса имя ещё неизвестно, так что он не веб-сервером будет писать, а из пхп.

[Everything_is_bad]

Ипатьев, там вообще песец, он раздумывает делать ли под каждого клиента отдельную таблицу или отдельный столбец.

Answer 5

[AlexVWill]

Обычный текстовый лог (можно в JSON), который потом читать lnav визуально, а парсить тем инструментом, что больше подходит для этой задачи...

Answer 6

[Hardoman]

Никогда, никогда не пишите логи в базу напрямую. В первую очередь из-за скорости, во-вторых, это синхронное действие процесса и оно должно выполняться всегда, а при недоступности базы повесит процесс в wait.
Если надо парсить большой объем логов (не ваш случай), то их отдельно можно стримить куда угодно, хоть в кафку, хоть в elasticsearch специально предназначенными для этого сервиса и типа vector.
Ротировать локальные логи logrotate'ом

Comments

[Everything_is_bad]

"никогда не говори никогда"
в данном случае даже полезно, у ТС отпадут прям чудовищные предубеждения про базы данных, лишний раз спроектирует таблицу, там тоже всё плохо, плюс получит опыт на проблемах, ошибка записи или упала база, где логи и т.п