статистика базы данных и отчетность с или без разбора встроенных журналов

Question

Я предпочитаю универсальную статистическую утилиту / плагин / приложение, но не ограничиваю себя, поскольку конкретные тоже могут преуспеть.

Я хочу видеть способ, которым я могу видеть статистику запросов для ВСЕХ запросов.

например, отображение и сортировка или фильтрация

1. все запросы или
2. все запросы сделаны на
3. все или конкретные базы данных, или
4. на конкретные таблицы.
5. или на определенных столбцах или
6. с определенным регулярным выражением запроса /params; сортировка по количеству самых совершенных запросов, самые длинные запросы в зависимости от времени
7. Хотя некоторые графические диаграммы были бы плюсом. Есть ли приложения или встроенные функции для таких вещей?

Для этого вам нужно будет регистрировать все запросы, а затем запускать / анализировать эти журналы через какой-то анализатор. Это может потребовать специального приложения синтаксического анализа журнала сборки.

Текущий сервер является сервером большого объема: 500 - 3000 запросов в секунду. Журнал может быть сохранен на другом жестком диске.

Вопросы:

1. Есть ли готовые приложения для таких вещей?

2. Замедлит ли это регулярные запросы? Если да, то сколько, примерно?

3. Есть ли способ видеть живые запросы и вести журналы где-либо еще, или не делать вообще, и делать отчеты о статистике в реальном времени каким-либо другим приложением?

4. Я мог бы не анализировать журналы с помощью создателя статистики для конкретной базы данных, а просто получить файл журнала и создать собственное приложение синтаксического анализатора и создать статистику и графическую диаграмму с этими журналами. Можно поместить эти проанализированные состояния в другую БД со значениями запросов + время, требуемое для выполнения + дата запроса, а затем генерировать отчеты из него позже. Это хорошая идея?

5. Я не заметил никакого "живого" способа сделать все это без регистрации в файле.

6. Есть какое-нибудь приложение для mysql и postgres? Это то, что я использую.

7. Какие-нибудь стратегические рекомендации по выполнению всего этого? Я только начал думать "как сделать анализ производительности в деталях".

Answer 1

Это сложная проблема, и, вероятно, нет простого ответа.

Один из подходов, который я использовал, - это использование pg_logforward для перехвата журналов, пересылки их пользовательскому демону, который записывает нормализованные записи журнала в другую базу данных PostgreSQL. (Hadoop и т.д. Также будет возможно.) Затем выполните специальные запросы к этой базе данных или создайте себе симпатичный внешний интерфейс. Это не сделано заранее, но это самый мощный подход на данный момент, IMO.