Кстати, линтер сейчас есть, некоторые вещи позволяет на ревью не пускать сразу. Его, конечно, тоже надо внедрять осторожно. Если включить все и сразу - то первые PR'ы после этого пройдут его примерно через никогда. Один из вариантов - идти по пути наименьшего срабатывания. Включили одну проверку: упало в 5 местах - терпимо, правим, оставляем включенной. Включили вторую: упало в 5000 мест - к ней мы не готовы, зайдем попозже:-)
Нет, мы не пытаемся изобрести sentry или opentracing, хотя подход в middleware очень напоминает последний. По поводу opencensus — интересно, посмотрим, спасибо!
Про elasticsearch и способы логирования — да, действительно, можно сделать все совсем иначе, не как в статье, но здесь блок про elasticsearch дан как пример.
Про логирование через print: в production-коде — да, в небольшом примере — допустимо, как мне кажется, суть от его использования не меняется. Опять, в итоговом пакете print не используется.
Про сериализацию с помощью json — соглашусь, но в нашем случае сериализация словаря из десятка параметров не несет критичной просадки.
Подключение к моделям в django-prometheus действительно есть, вот только нам не очень подходит из-за необходимости подключать доп.класс к моделям. Кроме того, насколько я помню, он собирает метрики в разрезе именно моделей, а нам необходимо подсчет относительно запросов пользователей.
По поводу велосипедостроения — возможно, но задачи продуктов пакет решает. Но никогда не лишним будет узнать иное мнение и сделать лучше.
Про лог SQL-запросов в production — пакет, указанный в конце статьи, этого тоже не делает, для этого мы используем сторонние инструменты, в том числе упомянутый в статье pgBadger.
Логи к базе действительно можно включить через настройку backend'а. В статье этот блок дан не для того, чтобы показать, что их нужно включать именно так, а скорее для того, чтобы поэтапно перейти к сбору статистики по запросам.
Да, django-prometheus действительно хороший инструмент. К сожалению, на момент, когда нам понадобился сбор метрик — он не подошел нам по ряду причин:
— доп.пакеты, которые нежелательно было тянуть в окружение
— нужны были связи с дополнительными метриками и логами
— необходимость раскладывать логи в разные форматы для последующей обработки
Возможно, стоит на него еще раз взглянуть, поскольку сейчас часть требований стала неактуальна. Спасибо!
get_response передается в __init__ как параметр и дальше используется как атрибут объекта. Если вопрос в том, как он попадает в __init__ — то это базовое поведение middleware в django.
Спасибо большое за то, что прочитали)
Кстати, линтер сейчас есть, некоторые вещи позволяет на ревью не пускать сразу. Его, конечно, тоже надо внедрять осторожно. Если включить все и сразу - то первые PR'ы после этого пройдут его примерно через никогда. Один из вариантов - идти по пути наименьшего срабатывания. Включили одну проверку: упало в 5 местах - терпимо, правим, оставляем включенной. Включили вторую: упало в 5000 мест - к ней мы не готовы, зайдем попозже:-)
Спасибо, надеюсь, кто-то действительно увидит в этом подходе новые варианты для себя
Про elasticsearch и способы логирования — да, действительно, можно сделать все совсем иначе, не как в статье, но здесь блок про elasticsearch дан как пример.
Про логирование через print: в production-коде — да, в небольшом примере — допустимо, как мне кажется, суть от его использования не меняется. Опять, в итоговом пакете print не используется.
Про сериализацию с помощью json — соглашусь, но в нашем случае сериализация словаря из десятка параметров не несет критичной просадки.
По поводу велосипедостроения — возможно, но задачи продуктов пакет решает. Но никогда не лишним будет узнать иное мнение и сделать лучше.
Про лог SQL-запросов в production — пакет, указанный в конце статьи, этого тоже не делает, для этого мы используем сторонние инструменты, в том числе упомянутый в статье pgBadger.
Да, django-prometheus действительно хороший инструмент. К сожалению, на момент, когда нам понадобился сбор метрик — он не подошел нам по ряду причин:
— доп.пакеты, которые нежелательно было тянуть в окружение
— нужны были связи с дополнительными метриками и логами
— необходимость раскладывать логи в разные форматы для последующей обработки
Возможно, стоит на него еще раз взглянуть, поскольку сейчас часть требований стала неактуальна. Спасибо!