Comments 11
UFO just landed and posted this here
Плюс к этому django-prometheus вполне умеет собирать данные по запросам (есть две MW) и вполне подключается к моделям и начинает считать время запросов и их кол-во. Ну про логирование через print() я вообще промолчу =)
Страсть к велосипедостроению наблюдаю я в этом посте.
Ну и дальше IMHO — не думаю, что лог SQL-запросов это хорошая идея в production, а время запроса итак есть в логах nginx и uwsgi.
Страсть к велосипедостроению наблюдаю я в этом посте.
Ну и дальше IMHO — не думаю, что лог SQL-запросов это хорошая идея в production, а время запроса итак есть в логах nginx и uwsgi.
Подключение к моделям в django-prometheus действительно есть, вот только нам не очень подходит из-за необходимости подключать доп.класс к моделям. Кроме того, насколько я помню, он собирает метрики в разрезе именно моделей, а нам необходимо подсчет относительно запросов пользователей.
По поводу велосипедостроения — возможно, но задачи продуктов пакет решает. Но никогда не лишним будет узнать иное мнение и сделать лучше.
Про лог SQL-запросов в production — пакет, указанный в конце статьи, этого тоже не делает, для этого мы используем сторонние инструменты, в том числе упомянутый в статье pgBadger.
По поводу велосипедостроения — возможно, но задачи продуктов пакет решает. Но никогда не лишним будет узнать иное мнение и сделать лучше.
Про лог SQL-запросов в production — пакет, указанный в конце статьи, этого тоже не делает, для этого мы используем сторонние инструменты, в том числе упомянутый в статье pgBadger.
Логи к базе действительно можно включить через настройку backend'а. В статье этот блок дан не для того, чтобы показать, что их нужно включать именно так, а скорее для того, чтобы поэтапно перейти к сбору статистики по запросам.
Да, django-prometheus действительно хороший инструмент. К сожалению, на момент, когда нам понадобился сбор метрик — он не подошел нам по ряду причин:
— доп.пакеты, которые нежелательно было тянуть в окружение
— нужны были связи с дополнительными метриками и логами
— необходимость раскладывать логи в разные форматы для последующей обработки
Возможно, стоит на него еще раз взглянуть, поскольку сейчас часть требований стала неактуальна. Спасибо!
Да, django-prometheus действительно хороший инструмент. К сожалению, на момент, когда нам понадобился сбор метрик — он не подошел нам по ряду причин:
— доп.пакеты, которые нежелательно было тянуть в окружение
— нужны были связи с дополнительными метриками и логами
— необходимость раскладывать логи в разные форматы для последующей обработки
Возможно, стоит на него еще раз взглянуть, поскольку сейчас часть требований стала неактуальна. Спасибо!
Мне почему-то кажется, что автор пытается переизобрести opentracing, sentry (beta), или opencensus (beta)…
Теперь, о elasticsearch — если есть необходимость, можно реализовать, или использовать готовый обработчик логов, который сразу будет слать логи в elk.
Например, django-structlog. В нем реализовано почти все, кроме генерации traceid — нужно будет добавлять менеджеры контекста и/или middleware, там где необходимо.
Список того, что делать не следует:
- Не логгируйте с помощью
print— логи должны приходить туда, где их ожидают. Приprint, нужно вручную отслеживать контекст приложения, добавлять форматирование, а также передаватьio.Stream, если у вас более одного обработчика логов. - Не сериализуйте в prod среде с помощью встроенного
json. Он достаточно медленный, если вводные данные не являются объектомio.Stream. Есть достаточное количество оберток над native-библиотеками (orjson, ujson, rapidjson).
Нет, мы не пытаемся изобрести sentry или opentracing, хотя подход в middleware очень напоминает последний. По поводу opencensus — интересно, посмотрим, спасибо!
Про elasticsearch и способы логирования — да, действительно, можно сделать все совсем иначе, не как в статье, но здесь блок про elasticsearch дан как пример.
Про логирование через print: в production-коде — да, в небольшом примере — допустимо, как мне кажется, суть от его использования не меняется. Опять, в итоговом пакете print не используется.
Про сериализацию с помощью json — соглашусь, но в нашем случае сериализация словаря из десятка параметров не несет критичной просадки.
Про elasticsearch и способы логирования — да, действительно, можно сделать все совсем иначе, не как в статье, но здесь блок про elasticsearch дан как пример.
Про логирование через print: в production-коде — да, в небольшом примере — допустимо, как мне кажется, суть от его использования не меняется. Опять, в итоговом пакете print не используется.
Про сериализацию с помощью json — соглашусь, но в нашем случае сериализация словаря из десятка параметров не несет критичной просадки.
Очень интересный материал, спасибо!
Но есть новичковый вопрос: в первом же фрагменте кода никак не могу понять, мы же не наследуем RequestTimeMiddleware ни от какого базового класса, откуда тогда берется self.get_response(request)?
Но есть новичковый вопрос: в первом же фрагменте кода никак не могу понять, мы же не наследуем RequestTimeMiddleware ни от какого базового класса, откуда тогда берется self.get_response(request)?
get_response передается в __init__ как параметр и дальше используется как атрибут объекта. Если вопрос в том, как он попадает в __init__ — то это базовое поведение middleware в django.
APM из ELK стека не подошел?
Sign up to leave a comment.
Логирование запросов к приложению Django