Combined log format for UWSGI

[f213]

Выхлоп UWSGI очень сложно парсить в opensearch и, думаю, в других системах обсервабилити.

Поправил выхлоп, чтобы он совпадал с apache combined log format, который везде понимается по дефлоту.

[kazqvaizer]

Честно говоря во время ресеча возможностей абсорберов логов я заметил что все поддерживают JSON формат по умолчанию. Как думаешь, возможно стоит идти по этому пути - так проще настраивать алерты и без дополнительных реджексов фильтровать данные просто по конкретным полям?

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

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

[f213]

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

В такой парадигме формат apache для логов доступа мне кажется самым хорошим вариантом — их все умеют и генерить, и парсить. C JSON это становится сложнее, т.к. нужно кучу разных инструментов подгонять под один формат, а не говорить им «просто сделай мне combined».

На проектах, где я делал opensearch в последний год, я просто копипастил регулярку в конфигу fluent-bit, и в журнал падали разобранные логи одинакового формата от всех контейнеров, что работают с http — и express.js, и django, и (простите) quart.

[nkiryanov]

мне ок, точнее без разницы: что раньше, что сейчас. Если где-то станет лучше — отлично.

Если рассуждать про логи, то не нравится что пишем в двух местах — что-то в django (exception), что-то в uwsgi. Понравился подход из go (наверняка он в этом не одинок):

1. логи пишут на уровне web-приложения, через middleware
2. как следствие — конфиг на уровне приложения: легче что-то убрать (нужны ли логи от healthcheck-проб?), можно делать разные конфиги для разных окружений (локально для человека, в проде — в json или что нам подходит)

наверняка есть какой-то смысл писать в uwsgi (перформанс?), но так не погружался.

[nvo87]

мне тоже ОК.

Правда за все мои проекты был только ФСК, который просил это настроить. Но возможно в общей массе, остальным это будет полезно из коробки.

[e-stepanov]

все поддерживают JSON формат по умолчанию

Пока делал коммерсант, мне еще показался удачным формат logfmt: простые key=value. Не такой экономный, как формат apache, но при этом снижает когнитивную нагрузку в процессе чтения. По сравнению с json и читаемее, и экономнее, и вроде как не менее универсально. Помнится, что агрегаторы логов его тоже хорошо поддерживают из коробки, по крайней мере fluentbit и promtail.

Если чисто говорить про access логи из uwsgi, nginx и т.п., то мне ок вариант из PR. Если смотреть в сторону универсального решения, то я бы посмотрел в сторону logfmt.