Вышла долгожданная версия Джанго 1.0. Мои самые искренние поздравления всем, кто участвовал и всем, кто сочувствовал. Совершенно серьезно я считаю, что на данный момент это лучший питоновый веб-фреймворк.

Тем не менее, я хочу по случаю посмотреть на этот релиз с нетрадиционной стороны и, возможно, несколько войти в диссонанс с эйфорией, которая сейчас начнется :-).

Разговаривая с людьми о Джанго, я обнаружил, что многие ждут релиз 1.0 как некое одиозное событие, которое... что? Оно, очевидно, что-то такое знаменует и означает. Но вот что именно в релизе 1.0 такого отличительного, что его все ждут.

Стабильность

Слышу, что ждут стабильности. Но это слово означает две разные вещи. По поводу одной — стабильности работы — в джанговском FAQ'е есть запись о том, что Джанго и так стабилен, и был стабильным еще до того, как даже исходники открылись. На нем работают реальные сайты и не падают. И это все правда.

Поэтому речь, конечно, не об этой стабильности. Речь о стабильности API, который в версии 1.0 перестанет изменяться.

Но секундочку... Возьмите любую произвольную ревизию кода, сохраните ее на диск и, уверяю вас, ее API тоже не будет меняться. Никогда. Вы можете написать на ней сайт, можете — два. Можете работать с ней 10 лет. API будет стабильным.

Развитие

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

Позвольте снова спросить, чем в этом смысле отличается релиз 1.0 от произвольно зафиксированной ревизии? Что, Джанго после 1.0 перестанет развиваться? Да нет, корные разработчики уже заявляли, что довольно быстро после 1.0 появятся 1.1, 1.2. Думаю и 2.0 будет довольно быстро... Может быть эти самые 1.1 и 1.2 будут сохранять обратную совместимость с 1.0? Да, наверняка. Но штука в том, что поддержка обратной совместимости — священная корова в разработке Джанго, и она ломается крайне редко и крайне неохотно. И только по делу. Номера версий тут не причина, а следствие. Фактически, версией 2.0 Джанго скорее всего станет первая же, в которой придется избавиться от какого-нибудь старого API, проявившего себя не слишком удачно.

Сторонние компоненты

Третий аспект "особенности" версии 1.0 — предполагается, что ее API будут использовать в качестве ориентира разработчики сторонних компонентов. И это снова правда. Но я, убейте меня, не верю, что разработчики сторонних компонентов не будут использовать и новые API. А значит их уже нельзя будет использовать с 1.0 напрямую. Да еще и эти компоненты не будут обязаны соблюдать полную обратную совместимость с 1.0, тут уж все зависит от специфики кода и желания разработчика. Если разработчик вменяемый, то он, опять таки, тоже старается сохранять обратную совместимость независимо от того, в какой версии фреймворка его стукнуло желание написать что-нибудь полезное.

Транк

Чтобы не быть голословным, расскажу, что у нас в Яндексе внутренние релизы Джанго — событие вполне заурядное. Как только кому-то из разработчиков нужна какая-то фича из транка, ближайшая удобная ревизия заворачивается в пакет, объявляется следующим релизом, и дальше разработчик-инициатор начинает кодить свой код, а остальные — апдейтить свои проекты под те несовместимости, которые к тому моменту накопились.

Думаю, мы продолжим делать это и после 1.0.

И вот это в Джанго, на мой взгляд, самое главное. Имея такой транк, который живет и практически не ломается, лично мне никаких релизов не надо :-)

И тем не менее...

Тем не менее, версия 1.0 — это хорошо. Я могу сходу придумать две причины, почему это так:

Поздравляем нас всех!

Комментарии: 44 (feed)

  1. drey

    Я думаю Иван ты сам ответил на вопросы заданные в начале поста. :) Целиком тебя поддерживаю.

  2. [...] Jacob Kaplan-Moss post Django downloads page complete release notes Ivan Sagalaev post [...]

  3. Boo

    Полностью согласен. 1.0 - это просто чекпоинт.
    Собственно, я как сидел на транке, так и буду сидеть :)
    Поздравляю с долгожданным чекпоинтом!

  4. Serge Matveenko

    Есть одно важное обстоятельство, которое вы не учли. 1.0 - версия, которая заменит 0.96 в дистрибутивах. Например, сегодня в Debian поставляется джанго 0.95 в stable и 0.96 в testing (http://packages.debian.org/search?keywords=python-django)). И пакеты не обновляются после каждого commit-а разработчиков.

    Еще: стабильность - это еще поддержка. Заплатку на дырку в безопасности ставят на все поддерживаемые версии и на транк. И никто не будет ставить ее на конкретный SVN-rev. А значит, если мы под 1.0, то получаем поддержку и нам не нужно тратить время на то, чтобы повторить действия, которые уже сделаны в 1.0 или на решение проблем связанных с обновлением до транка через пачку ревизий, меняющих API.

  5. Иван Сагалаев

    Например, сегодня в Debian поставляется джанго 0.95 в stable и 0.96 в testing

    Штука в том, что большинство (по моим наблюдениям) проектов работает на транке, и уже давно. Пакеты любой ОС, даже если это Ubuntu с полугодовым циклом обновлений, всегда будут отставать от транка на полгода минимум, а это редко приемлемо.

    Еще: стабильность - это еще поддержка. Заплатку на дырку в безопасности ставят на все поддерживаемые версии и на транк. И никто не будет ставить ее на конкретный SVN-rev

    Ничто не мешает поставить ее вручную. Раз уж человек пользуется непакетированной версией.

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

  6. vansickle

    ОДИОЗНЫЙ (от латинского odiosus - ненавистный, противный), известный своими отрицательными качествами, вызывающий резко неприязненное отношение.

    вы наверное имели в виду "некое знаковое событие"

  7. Иван Сагалаев

    Да, никогда не знал, что у слова "одиозный" есть отрицательная эмоциональная окраска... Использовал всю жизнь именно как "знаковый", "значительный".

  8. LongMan

    Для меня самое главное в любом релизе — это психология. Релиз это чекпоинт, который кое к чему обязывает разработчиков.

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

    Кроме того, я считаю, команде, разрабатывающей фреймворк «for perfectionsts with deadlines», давно не хватало этого самого deadline для самих себя.

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

    Вот так: я люблю и транки и релизы. И я испытываю благодарность и зависть. Зависть — потому что я не участвовал в этом :-)

  9. Александр Соловьёв

    Выход 1.0 хорош для опенсорсных проектов, где нельзя простым движением руки собрать новый пакетик и заставить всех заапдейтиться. А декларировать использование 1.0 и поддерживать проект именно на уровне 1.0 намного проще, чем вести его по транку и одновременно пытаться решать проблемы тех, у кого они есть (и они просто забыли обновить джангу час назад ;).

    В общем, мне кажется, жить проще станет. И, надеюсь, ревизии будут почаще выходить. :)

  10. bialix

    Есть мнение, что народ массово сидит на trunk когда нет достаточно частых и планомерных релизов. Так что отсутствие релиза хотя бы раз в 3-6 месяцев — это плохо для проекта и для пользователей такого проекта. Разработчикам проекта это по барабану, потому что они всегда используют trunk.

    Так что я не согласен с посылом статьи "trunk — вот что главное". Главное не это, а рабочий trunk в каждой ревизии. Но такого не бывает, рано или поздно возникают регрессии.

    И не стоит недооценивать готовые пакеты в дистрибутивах.

    Мои 5 копеек, конечно.

  11. Курилов Дмитрий

    Я редко когда не согласен с Иваном Сагалаевым. Сейчас как раз такой случай. Я не согласен с оценкой значимости релиза.

    Такому проекту, как Django, важно иметь регулярные стабильные версии.

    Почему стабильные? Потому что проект Django самым непосредственным образом используется в ряде других проектов. Особенно это становится видно, когда результатом проекта становится продукт, который написан на Django и используется третьими лицами. В этом случае использование транка неприемлемо.

    Ну представьте сами, что будет, если такой продукт будет создан на основе транка. Это значит, что разработчикам помимо работы над непосредственно самим продуктом добавляется работа по фиксу уже рабочего кода в случаях изменения API в транке. А ребятам, использующим продукт, совсем не сладко. Обновили систему, обновили код Django из транка (на предмет баг-фиксов), и на тебе! Не работает! Я с этим столкнулся, когда использовал транк и появился autoescape в шаблонах Django. Вот веселуха была.

    А если используется стабильная версия, пользователи безболезненно обновляются (автоматически или "нажатием одной кнопки"), разработчики непосредственно заняты функционалом продукта. И даже если разработчики захотят выпустить новую версию продукта, которая основана на новой версии Django, это будет несложно. Потому что это будет прогнозируемо. Понятно, что надо изменить, что бы продукт заработал в новой версии.

    Почему регулярные? Потому что нельзя, что бы функционал последней стабильной версии слишком отставал от кода в транке, как было с версией 0.96. Уж слишком мои внутренности протестовали, что бы я отказался от использования функционала транка для нового проекта. Будь версия 0.97 или 0.98, я бы использовал её.

    Ну и действительно, весьма примечателен рост активности разработчиков Django. Возможно, это говорит о долгожданности такого шага.

    Так что регулярные и стабильные версии Djagno действительно важны. А то, что кто-то кричит про нестабильность Django, действительно важно только для маркетинга. Разумные люди крикунов не слушают.

  12. Иван Сагалаев

    Ну представьте сами, что будет, если такой продукт будет создан на основе транка. Это значит, что разработчикам помимо работы над непосредственно самим продуктом добавляется работа по фиксу уже рабочего кода в случаях изменения API в транке.

    М-м? Процитирую себя:

    Возьмите любую произвольную ревизию кода, сохраните ее на диск и, уверяю вас, ее API тоже не будет меняться.

    И еще:

    А если используется стабильная версия, пользователи безболезненно обновляются

    Они безболезненно обновляются, только если новая версия из той же мажорной цифры (и то это не гарантируется). Но неминуемо придет время, когда Джанго будет уже 2.0, и пользователи не смогут "безболезненно" обновляться.

    Так что регулярные и стабильные версии Djagno действительно важны.

    А где я написал, что не важны? :-). Я написал, что надо понимать, чем именно они важны, а чем нет. При этом я даже не претендую на универсальность своей точки зрения.

  13. pf

    Возьмите любую произвольную ревизию кода, сохраните ее на диск и, уверяю вас, ее API тоже не будет меняться.

    Но если в этой ревизии найдется баг, то бэкпорт фикса будете делать вы, а не тот человек, который за это отвечает. Простая перемотка до текущей HEAD поломает продукт, который вообще говоря не обязательно писали вы.

    А ведь баг может быть секьюрным, который тихо пофиксили между r45903 и r46030, а вы сидите на r45905. А это значит, что человек, который отвечает за поддержку, должен постоянно читать баг-трек джанги, я так понимаю, что трафик там весьма нехилый.

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

  14. Иван Сагалаев

    Раз уж мы говорим о Джанго, то тут речь идет только о секьюрных багах, а не "в том числе" секьюрных багах. Остальные фиксы в стабильные версии не бэкпортятся. А для бэкпорта секьюрных багов не нужно следить за всеми ревизиями, нужно быть только подписанным на django-annonunce, где такие вещи объявляются. Их там крайне мало, кстати.

    Но в целом да, я повторюсь, что согласен с тем, что это выбор того, кому быть майнтейнером — пользователю или разработчикам. По факту довольно много людей уже выбрали "жизнь в транке", и не жалеют.

  15. Курилов Дмитрий

    Они безболезненно обновляются, только если новая версия из той же мажорной цифры (и то это не гарантируется). Но неминуемо придет время, когда Джанго будет уже 2.0, и пользователи не смогут "безболезненно" обновляться.

    А мне и минорная цифра не нужна, для поддержки уже существующего проекта нужны только баг-фиксы. Другое дело, что рано или поздно поддержка версии X.Y будет прекращена. Но если поддержка продлится хотя бы полтора года, этого уже будет достаточно. За полтора года можно перейти на Django X.Z. Или на Django Y.0. Или подписаться на django-annonunce и поддерживать Django X.Y :-)

  16. Владимир Сергеев

    Отличная новость. Вот как знал - надо почитать фиды на ночь, и вот ОНО. Супер!

  17. [...] популярного веб-фреймворка для разработки на Python, Django 1.0 released! Есть предложение устроить django party в Киеве, по примеру [...]

  18. Boo

    По факту довольно много людей уже выбрали "жизнь в транке", и не жалеют.

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

  19. Иван Сагалаев

    За август соглашусь :-). Менялось все много и часто. Мы внутри два раза отменяли релиз как раз чтобы дождаться, когда rush закончится.

    Посмотрим, кстати. Если ребята начнут придерживаться планов типа "один релиз в пару месяцев", возможно действительно сидение на транке потеряет свои выгоды. Но я пока не верю :-)

  20. Александр Кошелев

    Я всегда, с первого дня знакомства с джангой пользовался транком. И буду продолжать им пользоваться и впредь.

    Но сам факт выхода первой.ноль версии меня радует. И в большей степени своей психологической важностью, а не технической. О чем в блоге и написал.

    А по поводу использования в продакшен конкретной ревизии, то до недавнего времени я придерживался мнения, что вполне себе это нормально и беспроблемно. Но сейчас, когда ко мне обратился человек, который стал заниматься моим старым проектом и у него не получалось поднять песочницу у себя по простой причине - он не знал номер ревизии. Ситуация ещё усложнялась тем, что помимо конкретной ревизии нужно аплинуть ещё и конкретный патч к нему чтобы всё заработало. Да, в этой ситуации сказать"такой-то релиз" гораздо проще.

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

  21. LongMan

    А еще, а еще, django_evolution ждали релиза, чтобы совместимость закоммитить. И вот оно снова работает на транке :-)

    Слава релизам :-)

  22. bialix

    Александр Кошелев:

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

    несколько дней подряд думал над этой фразой. так и не понял, что значит "применить патч к каталогу"? патчатся только файлы, по крайней мере стандартной утилитой patch.

  23. Иван Сагалаев

    патчатся только файлы, по крайней мере стандартной утилитой patch.

    Вот скажите, зачем это буквоедство? Вызов patch -p0 < some.diff внутри каталога с universal-патчем на входе применяется ко всем файлам внутри него. Чем это не "применить патч к каталогу"? Можно еще пообсуждать, что patch применяет патчи таки не целиком файлами, а отдельными "ханками"...

  24. bialix

    это еще не буквоедство, не надо наезжать. я пока только уточнить хотел, поскольку скилл "телепатия" не прокачан вовсе.

  25. flexair.ya.ru/index_profile.xml

    С таким подходом Django проекты можно будет хостить только на VPS как минимум. Причем свой VPS для каждого проекта. Это приведет к печальным последствиям:

    1. стоимость хостинга с 5 баксов в месяц повыситься до 50. А этот VPS еще настроить надо...(ща мне расскажут про стоимость разработки...)
    2. (следствие первого) порог вхождения гораздо выше. Т.е. каждый студент пробовал программировать на php, т.к. ставим WAMP - кодим, где хостить тоже найдем нахаляву (для начала). Django тут пролетает.

    Сам пишу на Django для себя. Во многом благодаря этому форуму. С позицией "Главное - Транк" не согласен. Для Гиков энтузиастов, когда хочется потестить вкусные новые фичи из транка - клевый подход. Для крупного проекта в котором куча программистов ПОСТОЯННО его поддерживает - наверное, тоже хорошо. Для проекта сделал и оно работает - не пройдет.

    Поддержка проектов, когда для каждого проекта свой VPS очень усложняется и Бизнес такого не поймет. Я надеюсь, что разработчики Django изначально ориетнировались на упрощение поддержки проектов. Поэтому, будут регулярно выпускать стабильные релизы. И они изначально ориентировались на простоту поддержки со стороны бизнеса (когда важно точно знать, когда выйдет следующий релиз платформы, и какое времы будет поддерживаться вышедший стабильный релиз). Иначе они, наверняка, выбрали бы другую лицензию...

    Еще пример.
    PHP.

    нужен сайт - берем виртуальный хостинг, ставим Drupal, настраиваем, качаем плагины к нужной версии. Работает, пока не поменяют мажорную версию php.

    Django.
    качаем Cicero, идем на форум, узнаем, какой нужен транк, покупаем VPS, настраиваем VPS, ставим forum, настраиваем... Ничего не трогаем, даже, если не дай бог выйдет какой-то чудо плагин борьбы со спамом или аторизации по отпечатку сетчатки глаза - ничего поставить не получиться - т.к. плагин для другого транка.

    Если что - просьба не обижаться. Сам использую Django. По жизни чаще занимаюсь саппортом, а не разработками (сисамдин). А при подходе "главное транк" каждому проекту потребуется vps однозначно, + постоянный программист и сисадмин, если нужно что-то поменять. В такую ситуацию лезть очень не хочется.

  26. Александр Кошелев

    несколько дней подряд думал над этой фразой. так и не понял, что значит "применить патч к каталогу"? патчатся только файлы, по крайней мере стандартной утилитой patch.

    это еще не буквоедство, не надо наезжать. я пока только уточнить хотел, поскольку скилл "телепатия" не прокачан вовсе.

    Не надо ссориться. Да, наверно,я просто не совсем очевидно выразился. Но Ваня абсолютно прав, я имел ввиду типичный паттерн патчинга джанги.

  27. Александр Кошелев

    С таким подходом Django проекты можно будет хостить только на VPS как минимум

    Что-то причинно-следственная связь не прослеживается

  28. bialix

    Не надо ссориться. Да, наверно,я просто не совсем очевидно выразился. Но Ваня абсолютно прав, я имел ввиду типичный паттерн патчинга джанги.

    Я ни разу не патчил джангу, поэтому не знал про "типичные паттерны патчинга джанги". Просто сейчас развелось много разных нестандратных инструментов, сразу не угадаешь.

  29. Иван Сагалаев

    я имел ввиду типичный паттерн патчинга джанги.

    А я имел в виду практически любой open source проект. Тут нет ничего джанго-специфичного, и именно поэтому я искренне удивлен вопросом "как это". А как еще-то? :-)

  30. flexair.ya.ru

    Что-то причинно-следственная связь не прослеживается

    написали прокт - зафиксировали API (транк).
    паписали другой прокт - зафиксировали другой транк. На виртуальном хостинге такое не получиться. Вариант, когда на рельсовом проекте делают Freeze рельсов+gem'ов для конкретного проекта, по сути тот же VPS (по отжиранию кешем памяти, т.к. кроме своего кода у тебя для каждого проекта еще свой код фреймворка) и преимущества виртуального хостинга исчезают. "Дешевая памать" не спасет.

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

    Еще раз повторю, для гиков и крупных проектов все по другому.

  31. Иван Сагалаев

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

    Почему? По-моему, хостер будет поддерживать одну — последнюю — версию. Если хостер "любит" Джангу, то максимум две. Поэтому, официальные релизы или нет, а вариант "написали и забыли" на шаренном хостинге будет работать только для сред, не обновляющихся годами. Что и видно на примере PHP, где мажорные версии заменяют друг друга очень медленно.

  32. flexair.ya.ru

    Почему? По-моему, хостер будет поддерживать одну — последнюю — версию. Если хостер "любит" Джангу, то максимум две.

    Потому что у хостера много проектов, которые написали и перестали менять. Т.е. написали и забыли, а оно работает.

    Поэтому, официальные релизы или нет, а вариант "написали и забыли" на шаренном хостинге будет работать только для сред, не обновляющихся годами.

    При регулярных релизах раз в 4-6 месяцев не вопрос поддерживать несколько стабильных версий.

  33. Александр Кошелев

    написали прокт - зафиксировали API (транк).
    паписали другой прокт - зафиксировали другой транк. На виртуальном хостинге такое не получиться.

    Да ладно! А зачем мне джанга хостера вообще? Я могу её с собой таскать. Было бы желание. Это же не версию всей среди включая интерпретатор сменить, как в php.

  34. flexair.ya.ru

    Да ладно! А зачем мне джанга хостера вообще? Я могу её с собой таскать. Было бы желание. Это же не версию всей среди включая интерпретатор сменить, как в php.

    Аналог рельсовых фризов для джемов и самих рельсов (уже писал про это). Довольно быстро попадешь в VPS, т.к. приложение будет ооочень нагружать дисковую систему, подгружая свой фреймворк для каждого проекта и заполняя этим файловый кеш. Потому хостер тебя спровадит на VPS, где приложение и будет тормозить (т.к. на vps машине таких много и все мыслят похоже).

  35. Александр Кошелев

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

    Так процесс может месяцами висеть в памяти, а загружает модули он в момент старта. В общем не беда ни разу.

  36. bialix

    я имел ввиду типичный паттерн патчинга джанги.

    А я имел в виду практически любой open source проект. Тут нет ничего джанго-специфичного, и именно поэтому я искренне удивлен вопросом "как это". А как еще-то? :-)

    Ну что ж, продолжаем занудничать.

    Иван, в англоязычных форумах и почтовых рассылках мне никогда не попадался термин "патчить каталог". Чаще говорят о patching source tree. А как еще-то?

  37. Александр Кошелев

    Иван, в англоязычных форумах и почтовых рассылках мне никогда не попадался термин "патчить каталог". Чаще говорят о patching source tree. А как еще-то?

    К счастью мы имеем возможность писать комментарии в русскоязычный блог, да ещё и на русском же языке, поэтому почему бы не иметь свой собственный глоссарий предметной области?:)

  38. hidded

    Почему? По-моему, хостер будет поддерживать одну — последнюю — версию. Если хостер "любит" Джангу, то максимум две.

    Гм. А какая религия не позволяет сделать чекаунт необходимой ревизии в домашнюю директорию на хостинге и прописать необходимое в PYTHONPATH?

    Не надо придумывать проблемы там, где их нет.

  39. Slach

    Иван а можно немного раскрыть тему "заворачивания новой версии django в пакет" ???

    насколько я понимаю это Debian?

    вы используете какой то СВОЙ пакет и свои debian/rules и соответсвенно сами осуществляете сборку и сами прописываете все build depends?

    или взяли за основу debian пакет из официальных репозиториев?

    а как тогда быть с тем, что apt-get install python-django до 1.0.1 тянет на etch за собой ~200 метров левых библиотек? ну понятно что локальный репозиторий и трафик никто уже не считает... но вот у меня это вызывает дискомфорт

  40. Иван Сагалаев

    У нас свой пакет, написанный с нуля. Ничего сложнее python setup.py install при установке он не делает. Зависимостей мы ему написали две: python (точнее python-support) и python-imaging.

  41. Вася Триллер

    А новичкам плохо. Django book всё ещё написан для 0.95, и бегать от DB до http://docs.djangoproject.com/en/dev/releases/1.0-porting-guide/ уже достало. Кроме того, плавно начинаешь запутываться.

    А так, в принципе, радуюсь :)

  42. adnull

    Почему? По-моему, хостер будет поддерживать одну — последнюю — версию. Если хостер "любит" Джангу, то максимум две.

    Вы неправы. Я - хостер python приложений. Мы только обоими руками за то, что бы разработчики ставили свою версию джанго (даже в инструкциях рекомендуем). Потому что когда центральная версия обновится, саппорт завалят письмами.

  43. Slach

    Иван спасибо за ценный совет
    сделали свой пакет для django

    а можно еще вопрос?
    как вы мониторите производительность в продакшене??

    ну вот допустим для PHP у меня есть модуль который время выполнения и важные параметры из $_REQUEST и $_SERVER формирует в UDP пакет и отсылает на демон статистики
    который высчитывает всякие там группировки по скритам, хостам и держит это в памяти (SQLite) за какой то промежуток времени
    к нему цепляется Cacti и снимает показатели типа top5

    есть ли какие либо подобные решения для Django??
    т.е. меня интересует возможность подцепиться к django fastcgi и снять какоую нибудь status_page через cacti

  44. Иван Сагалаев

    Про это, к сожалению, подробно рассказать не могу... Насколько я знаю, у flup (сервера FastCGI в Django) такого интерфейса нет. Админы наши мониторят "здоровье" серверов в целом по куче глобальных параметров. И пока что подробности о состоянии отдельного процесса нам наверное мало что дадут, потому что на нашем кластере крутятся что-то типа 9 джанговских проектов, от мелких до крупных. Но мысль все равно хорошая, я постараюсь устранить собственное невежество в этом вопросе...

Добавить комментарий

Format with markdown