Форматирование журналов запросов uWSGI — https://uwsgi-docs.readthedocs.io/en/latest/LogFormat.html
Базовое ведение журнала
Самая простая форма ведения журнала (логирования) в uWSGI — это запись запросов, ошибок и информационных сообщений в stdout/stderr. Это происходит в конфигурации по умолчанию. Самой простой формой перенаправления логов являются параметры:
- —logto
- —logto2
- —daemonize
которые позволяют перенаправлять журналы в файлы.
Базовое ведение журнала в файлы
Для записи в файлы вместо stdout/stderr используйте —logto или для одновременной демонизации uWSGI —daemonize.
./uwsgi -s :3031 -w simple_app --daemonize /tmp/mylog.log ./uwsgi -s :3031 -w simple_app --logto /tmp/mylog.log # logto2 открывает файл журнала только после того, как привилегии были снижены до указанного uid/gid. ./uwsgi -s :3031 -w simple_app --uid 1001 --gid 1002 --logto2 /tmp/mylog.log
Базовое ведение журнала (подключенный режим UDP)
С помощью ведения журнала UDP вы можете централизовать ведение журнала кластера или перенаправить сохранение журналов на другую машину, чтобы разгрузить дисковый ввод-вывод (I/O). Ведение журнала UDP работает как в демоническом, так и в интерактивном режимах. Ведение журнала UDP работает в режиме подключенного сокета, поэтому сервер UDP должен быть доступен до запуска uWSGI. Более простой подход (работа в режиме без подключения) см. в разделе, посвященном ведению журнала сокетов.
Чтобы включить подключенный режим UDP, передайте адрес UDP-сервера в параметр —daemonize или —logto:
./uwsgi -s :3031 -w simple_app --daemonize 192.168.0.100:1717 ./uwsgi -s :3031 -w simple_app --logto 192.168.0.100:1717
Это перенаправит все данные stdout/stderr в сокет UDP на 192.168.0.100, порт 1717. Теперь вам нужен сервер UDP, который будет управлять вашими сообщениями UDP. Вы можете использовать netcat или даже uWSGI:
nc -u -p 1717 -s 192.168.0.100 -l ./uwsgi --udp 192.168.0.100:1717
Второй способ немного более полезен, так как он будет печатать источник (ip:port) каждого сообщения. В случае регистрации нескольких серверов uWSGI на одном и том же UDP-сервере это позволит вам отличить один сервер от другого. Естественно, вы можете написать ваши собственные приложения для управления/фильтрации/сохранения журналов, полученных через udp.
Подключаемые регистраторы (плагинные ведения журналов)
uWSGI также поддерживает подключаемые регистраторы, которые позволяют вам более гибко выбирать, где и что регистрировать. В зависимости от конфигурации вашей сборки uWSGI некоторые регистраторы могут быть доступны или недоступны.
Некоторые могут потребоваться для загрузки в виде подключаемых модулей. доступны в вашей сборке, вызовите uWSGI с параметром —logger-list.
Чтобы настроить подключаемый регистратор, используйте параметры —logger или —req-logger.
—logger настроит регистратор для каждого сообщения.
—req-logger настроит регистратор для информационных сообщений запроса.
Это синтаксис:
--logger <plugin>[:options]
--logger "<name> <plugin>[:options]" # Кавычки требуются только в командной строке — файлы конфигурации их не используют.
Вы можете настроить любое количество регистраторов. Именованные плагины используются для маршрутизации журналов. Ниже приведён очень простой пример разделённого журнала запросов/ошибок с использованием текстовых файлов.
[uwsgi]
req-logger = file:/tmp/reqlog
logger = file:/tmp/errlog
Маршрутизация журналов
По умолчанию все строки журнала отправляются всем объявленным регистраторам.Если это не то, что вы хотите, вы можете использовать —log-route (и —log-req-route для регистраторов запросов), чтобы указать регулярное выражение для маршрутизации определенного журнала. сообщения по разным адресам.
Например:
[uwsgi]
logger = mylogger1 syslog
logger = theredisone redislog:127.0.0.1:6269
logger = theredistwo redislog:127.0.0.1:6270
logger = file:/tmp/foobar # This logger will log everything else, as it's not named
logger = internalservererror file:/tmp/errors
# ...
log-route = internalservererror (HTTP/1.\d 500)
log-route = mylogger1 uWSGI listen queue of socket .* full
Это приведет к регистрации каждой ошибки уровня 500 в /tmp/errors, в то время как полные ошибки очереди прослушивания будут отображаться в /tmp/foobar. Это несколько похоже на «Подсистему сигнализации uWSGI (из 1.3)«, хотя сигналы тревоги обычно тяжелее и должны использоваться только в критических ситуациях.
Ведение журнала в файлы
плагин logfile — встроен по умолчанию.
uwsgi --socket :3031 --logger file:/tmp/uwsgi.log
При желании можно настроить автоматическую ротацию логов:
uwsgi --socket :3031 --logger file:logfile=/tmp/uwsgi.log,maxsize=2000000
Это заменит файл журнала, как только он достигнет 2 млн байт. Новое имя будет исходным файлом журнала с заменой расширения на метку времени.
Вы также можете указать имя резервной копии вместо того, чтобы позволять uWSGI создавать ее автоматически.
Ведение журнала в сокеты
Плагин logsocket — встроен по умолчанию.
Вы можете войти в несвязанный сокет UNIX или UDP, используя —logger socket:… (или —log-socket …).
uwsgi --socket :3031 --logger socket:/tmp/uwsgi.logsock
будет отправлять записи журнала в сокет Unix /tmp/uwsgi.logsock.
uwsgi --socket :3031 --logger socket:192.168.173.19:5050
будет отправлять дейтаграммы журналов на UDP-адрес 192.168.173.19 через порт 5050. Вы также можете выполнять многоадресную рассылку журналов на несколько серверов журналов, передав многоадресный адрес:
uwsgi --socket :3031 --logger socket:225.1.1.1:1717
Ведение журнала в системный журнал
Плагин syslog — встроен по умолчанию
Плагин системного журнала syslog направляет журналы в стандартный системный журнал Unix.Вы можете передать необязательный идентификатор для отправки и «средство» (facility) для записи в журнале.
uwsgi --socket :3031 --logger syslog:uwsgi1234
или
uwsgi --socket :3031 --logger syslog:uwsgi1234,local6
для отправки на объект local6
Ведение журнала в удалённый системный журнал
Плагин rsyslog — встроен по умолчанию
Плагин rsyslog направляет журналы в стандартный системный журнал Unix, расположенный на удаленном сервере.В дополнение к адресу и порту удаленного сервера системного журнала вы можете передать необязательный идентификатор для отправки в качестве параметра «средство» (facility) для записи журнала.
uwsgi --socket :3031 --logger rsyslog:12.34.56.78:12345,uwsgi1234
Ведение журнала через Redis
Плагин redislog — встроен по умолчанию.
По умолчанию подключаемый модуль redislog «публикует»(publish) каждую строку журнала в очереди публикации/подписки redis Синтаксис подключаемого модуля регистратора:
--logger redislog[:<host>,<command>,<prefix>]
По умолчанию хост host сопоставляется с 127.0.0.1:6379, команда command сопоставляется с «публикацией uwsgi», а префикс prefix пуст. Чтобы опубликовать в очередь с именем foobar, используйте redislog:127.0.0.1:6379,publish foobar. Ведение журнала Redis не ограничивается pub/sub. Например, вы можете поместить элементы в список, как в следующем примере.
--logger redislog:/tmp/redis.sock,rpush foo,example.com
Поскольку ошибки могут привести к блокировке главного сервера при записи строки журнала на удаленный сервер, рекомендуется использовать параметр —threaded-logger, чтобы разгрузить запись журнала во вторичный поток.
Ведение журнала через MongoDB
Плагин mongodblog — встроен по умолчанию.
Синтаксис регистратора для ведения журнала MongoDB (mongodblog):
--logger mongodblog[:<host>,<collection>,<node>]
Где host — это адрес экземпляра MongoDB (по умолчанию 127.0.0.1:27017), имена коллекций collection, в которые записываются строки журнала (по умолчанию uwsgi.logs), а node — это идентификационная строка для экземпляра, отправляющего журналы (по умолчанию: имя хоста сервера).
--logger mongodblog
Будет запускать регистратор со значениями по умолчанию, в то время как
--logger mongodblog:127.0.0.1:9090,foo.bar
Будет записывать журналы на сервер mongodb 127.0.0.1:9090 в коллекцию foo.bar, используя имя узла по умолчанию. Как и в случае с регистратором Redis, хорошим выбором является разгрузка записей журнала в выделенный поток.
[uwsgi] threaded-logger = true logger = mongodblog:127.0.0.1:27017,uwsgi.logs_of_foobar # As usual, you could have multiple loggers: # logger = mongodblog:192.168.173.22:27017,uwsgi.logs_of_foobar socket = :3031
Ведение журнала через ZeroMQ
Как и в случае с ведением журнала UDP, вы можете централизовать/распространять ведение журнала через ZeroMQ. Создайте свой демон регистратора, используя сокет ZMQ_PULL:
import zmq ctx = zmq.Context() puller = ctx.socket(zmq.PULL) puller.bind("tcp://192.168.173.18:9191") while True: message = puller.recv() print message,
Теперь запустите ваш сервер uWSGI:
uwsgi --logger zeromq:tcp://192.168.173.18:9191 --socket :3031 --module werkzeug.testapp:test_app
(—log-zeromq является псевдонимом для этого регистратора.)
Плагин «Crypto logger»
Если вы размещаете свои приложения в облачных службах без постоянного хранилища, вы можете отправлять свои журналы во внешние системы. Однако журналы часто содержат конфиденциальную информацию, которую не следует передавать в открытом виде. Регистратор подключаемого модуля logcrypto пытается решить эту проблему, шифруя каждый пакет журнала перед отправкой его по UDP на сервер, способный расшифровать его. В следующем примере каждый пакет журнала будет отправлен на сервер UDP, доступный по адресу 192.168.173.22:1717, с шифрованием текста секретным ключом ciaociao с Blowfish в режиме CBC.
uwsgi --plugin logcrypto --logger crypto:addr=192.168.173.22:1717,algo=bf-cbc,secret=ciaociao -M -p 4 -s :3031
Пример сервера доступен по адресу https://github.com/unbit/uwsgi/blob/master/contrib/cryptologger.rb
Плагин «Graylog2 logger»
Плагин graylog2 — по умолчанию не скомпилирован.
Этот плагин будет отправлять журналы на сервер Graylog2 в родном для Graylog2 формате GELF.
uwsgi --plugin graylog2 --logger graylog2:127.0.0.1:1234,dsfargeg
Плагин «Systemd logger»
Плагин systemd_logger — по умолчанию не скомпилирован.
Этот плагин будет записывать записи журнала в журнал Systemd.
uwsgi --plugin systemd_logger --logger systemd
Написание собственных плагинов для логгеров
Этот плагин, foolog.c, будет записывать ваши сообщения в файл, указанный с помощью –logto/–daemonize, с простым префиксом, используя векторный ввод-вывод.
#include <uwsgi.h> ssize_t uwsgi_foolog_logger(struct uwsgi_logger *ul, char *message, size_t len) { struct iovec iov[2]; iov[0].iov_base = "[foo] "; iov[0].iov_len = 6; iov[1].iov_base = message; iov[1].iov_len = len; return writev(uwsgi.original_log_fd, iov, 2); } void uwsgi_foolog_register() { uwsgi_register_logger("syslog", uwsgi_syslog_logger); } struct uwsgi_plugin foolog_plugin = { .name = "foolog", .on_load = uwsgi_foolog_register, };
Информационные ссылки
Стандарт uWSGI — Раздел «Logging» — https://uwsgi-docs.readthedocs.io/en/latest/Logging.html
