uWSGI 2.0.20 | Логирование (Ведение журнала) — efim360.ru

uWSGI 2.0.20 | Логирование (Ведение журнала)

Смотрите также

Форматирование журналов запросов 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

uWSGI 2.0.20 | Технический выпуск

uWSGI 2.0.20 | Технический выпуск

Особое примечание: это последняя версия с лицензией GPL2+linking_exception. Следующие версии будут под MIT.   Изменения Переключение Python по умолчанию для сборки на […]