Логирование запросов

Логирование запросов можно включить, установив директиву query_log в разделе searchd конфигурационного файла.

Запросы также могут отправляться в syslog, если указать syslog вместо пути к файлу. В этом случае все поисковые запросы будут отправлены демону syslog с приоритетом LOG_INFO, с префиксом [query] вместо временной метки. Для syslog поддерживается только формат лога plain.

Пример query_log:

searchd {
...
    query_log = /var/log/query.log
    query_log_format = sphinxql # default
...
}

Формат логирования

Поддерживается два формата лога запросов:

sphinxql (по умолчанию): Логирует в формате SQL. Также предоставляет простой способ воспроизведения записанных запросов.
plain: Логирует полнотекстовые запросы в простом текстовом формате. Этот формат рекомендуется, если большинство ваших запросов в основном полнотекстовые или если вам не нужно логировать не-полнотекстовые компоненты, такие как фильтрация по атрибутам, сортировка или группировка. Запросы, записанные в формате plain, не могут быть воспроизведены. Обратите внимание, что запросы, обработанные через Buddy, не логируются в этом режиме.

Для переключения между форматами можно использовать настройку searchd query_log_format.

Формат лога SQL

Формат лога SQL является настройкой по умолчанию. В этом режиме Manticore логирует все успешные и неуспешные select-запросы. Запросы, отправленные как SQL или через бинарный API, логируются в формате SQL, но JSON-запросы логируются как есть. Этот тип логирования работает только с обычными файлами логов и не поддерживает службу 'syslog' для логирования.

Пример query_log_format:

query_log_format = sphinxql # default

Особенности формата лога SQL Manticore по сравнению с простым форматом включают:

Полные данные оператора логируются там, где это возможно.
Ошибки и предупреждения логируются.
Лог запросов может быть воспроизведен.
Логируются дополнительные счетчики производительности (в настоящее время - время распределенных запросов на агента).
Каждая запись в логе является валидным оператором Manticore SQL/JSON, который восстанавливает полный запрос, за исключением случаев, когда записанный запрос слишком велик и его необходимо сократить по соображениям производительности.
JSON-запросы логируются как комментарии, пропуская лишние пробелы между элементами.
Дополнительные сообщения, счетчики и т.д. логируются как комментарии.

Пример записей лога sphinxql:

/* Sun Apr 28 12:38:02.808 2024 conn 2 (127.0.0.1:53228) real 0.000 wall 0.000 found 0 */ SELECT * FROM test WHERE MATCH('test') OPTION ranker=proximity;
/* Sun Apr 28 12:38:05.585 2024 conn 2 (127.0.0.1:53228) real 0.001 wall 0.001 found 0 */ SELECT * FROM test WHERE MATCH('test') GROUP BY channel_id OPTION ranker=proximity;
/* Sun Apr 28 12:40:57.366 2024 conn 4 (127.0.0.1:53256) real 0.000 wall 0.000 found 0 */  /*{ "index" : "test", "query": { "match": { "*" : "test" } }, "_source": ["f"], "limit": 30 } */

Простой формат лога

При формате лога plain Manticore логирует все успешно выполненные поисковые запросы в простом текстовом формате. Не-полнотекстовые части запросов не логируются. JSON-запросы записываются как однострочные записи. Запросы, обработанные через Buddy, не логируются.

Пример query_log_format:

query_log_format = plain

Формат лога следующий:

[query-date] real-time wall-time [match-mode/filters-count/sort-mode total-matches (offset,limit) @groupby-attr] [table-name] {perf-stats} query

где:

real-time — это сквозное время от начала до завершения запроса. В логах SphinxQL ему соответствует поле real.
wall-time — это внутренняя метрика Manticore для времени выполнения запроса по часам. В логах SphinxQL ей соответствует поле wall, и это же значение используется query_log_min_msec. Для распределенных и многоисточниковых запросов wall-time может отличаться от real-time.
perf-stats - включает статистику CPU/IO, когда Manticore запущен с --cpustats (или это было включено через SET GLOBAL cpustats=1) и/или --iostats (или это было включено через SET GLOBAL iostats=1):
- ios - количество выполненных операций ввода-вывода с файлами;
- kb - объем данных в килобайтах, прочитанных из файлов таблиц;
- ms - время, затраченное на операции ввода-вывода.
- cpums - время в миллисекундах, затраченное на обработку запроса процессором.
match-mode может иметь одно из следующих значений:
- "all" для режима SPH_MATCH_ALL;
- "any" для режима SPH_MATCH_ANY;
- "phr" для режима SPH_MATCH_PHRASE;
- "bool" для режима SPH_MATCH_BOOLEAN;
- "ext" для режима SPH_MATCH_EXTENDED;
- "ext2" для режима SPH_MATCH_EXTENDED2;
- "scan" если использовался режим полного сканирования, либо указанный с SPH_MATCH_FULLSCAN, либо если запрос был пустым.
sort-mode может иметь одно из следующих значений:
- "rel" для режима SPH_SORT_RELEVANCE;
- "attr-" для режима SPH_SORT_ATTR_DESC;
- "attr+" для режима SPH_SORT_ATTR_ASC;
- "tsegs" для режима SPH_SORT_TIME_SEGMENTS;
- "ext" для режима SPH_SORT_EXTENDED.

Примечание: режимы SPH* специфичны для устаревшего интерфейса sphinx. Интерфейсы SQL и JSON будут логировать, в большинстве случаев, ext2 как match-mode и ext и rel как sort-mode.

Для распределенных запросов используйте счетчики SHOW STATUS dist_wall, dist_local и dist_wait для анализа, где тратится время. Эти счетчики дополняют друг друга и не являются прямыми заменами для real/wall лога запросов.

Пример лога запросов:

[Fri Jun 29 21:17:58 2021] 0.004 sec [all/0/rel 35254 (0,20)] [lj] [ios=6 kb=111.1 ms=0.5] test
[Fri Jun 29 21:17:58 2021] 0.004 sec [all/0/rel 35254 (0,20)] [lj] [ios=6 kb=111.1 ms=0.5 cpums=0.3] test
[Sun Apr 28 15:09:38.712 2024] 0.000 sec 0.000 sec [ext2/0/ext 0 (0,20)] [test] test
[Sun Apr 28 15:09:44.974 2024] 0.000 sec 0.000 sec [ext2/0/ext 0 (0,20) @channel_id] [test] test
[Sun Apr 28 15:24:32.975 2024] 0.000 sec 0.000 sec [ext2/0/ext 0 (0,30)] [test] {     "table" : "test",     "query":     {         "match":         {             "*" : "test"         }     },     "_source": ["f"],     "limit": 30 }

Логирование только медленных запросов

По умолчанию логируются все запросы. Если вы хотите логировать только запросы, время выполнения которых превышает заданный лимит, можно использовать директиву query_log_min_msec.

Ожидаемая единица измерения - миллисекунды, но также можно использовать выражения с временными суффиксами.

Пример query_log_min_msec:

searchd {
...
    query_log = /var/log/query.log
    query_log_min_msec  = 1000
    # query_log_min_msec  = 1s
...
}

Режим прав доступа к файлу лога

По умолчанию файлы логов searchd и запросов создаются с правами доступа 600, поэтому только пользователь, под которым работает Manticore, и root могут читать файлы логов. Опция query_log_mode позволяет установить другие права доступа. Это может быть полезно для предоставления доступа на чтение файлов логов другим пользователям (например, решениям мониторинга, работающим под непривилегированными пользователями).

Пример query_log_mode:

searchd {
...
    query_log = /var/log/query.log
    query_log_mode = 666
...
}

Query_logging.md 11 KB Permalink History Raw