Протоколирование в Sentry для Twisted

При настройке протоколирования в Sentry для наших проектов возник интересный вопрос: как лучше передавать сообщения об ошибках из Twisted. Простое гугление подсказало один из очевидных вариантов, но он имел свои недостатки: ошибки протоколировались в лучшем случае в непотребном виде:

'Traceback (most recent call last):\n  File "/usr/lib/python2.7/dist-packages/XXX/XXX/XXX/xxx.py", line 180, in connect\n    connection = cx_Oracle.connect(**self.dsn)\nDatabaseError: ORA-12170: TNS:\xd0\xb8\xd1\x81\xd1\x82\xd0\xb5\xd0\xba\xd0\xbb\xd0\xbe \xd0\xb2\xd1\x80\xd0\xb5\xd0\xbc\xd1\x8f \xd0\xbe\xd0\xb6\xd0\xb8\xd0\xb4\xd0\xb0\xd0\xbd\xd0\xb8\xd1\x8f \xd1\x81\xd0\xbe\xd0\xb5\xd0\xb4\xd0\xb8\xd0\xbd\xd0\xb5\xd0\xbd\xd0\xb8\xd1\x8f\n\n'

Понятно, что для практических целей это трудноприменимо, поэтому путем экспериментов и чтения документации Twisted был найден следующий более оптимальный вариант:

Continue reading Протоколирование в Sentry для Twisted

Service name given as port is unknown

Встретился с забавной ошибкой от twisted при отладке очередного проекта:

Service name given as port is unknown: service/proto not found ('5672')

Поиск выводит только на сообщения с похожей ошибкой без ответов, а ларчик открывается просто: при вызове connectTCP номер порта должен быть строго целым числом, иначе twisted ищёт нужный порт, считая что вы передали ему название сервиса (как описано в /etc/services). Конечно, в этом справочнике сервисов такого названия не будет.

К слову о многопоточности

Довелось по работе столкнуться с сервисом шифрования, который был написан по словам авторов, вроде бы очень просто и примитивно, но протокол был очень неприятный: обмен шёл 18-байтовыми блоками символов через TCP-порт. Решил сделать к нему небольшой проксирующий сервис на twisted, который бы вёл приём данных через HTTP POST запросы, выдавая результат в ответ. Стал проверять на скорость работы, и, этот «лёгкий простой» Java-сервис шифрования оказалось не выдержал и 100 единовременных запросов. Пришлось в тестах ограничиться 10-ю потоками, а заодно озадачиться вопросом как twisted переиспользует объекты протокола в многопоточном доступе (об этом другая история).

Мораль такова: как и бывший коллега в тестах обнаружил, что twisted выдерживает на удивление столько потоков, что падаёт то, что стоит за ним, так и здесь получилось, что то, что кажется кому-то простым и надёжным, на деле оказывается весьма падуче-тяжеловесным, когда речь идёт о высокой нагрузке. И спасибо разработчикам twisted за столь стремительный фреймворк 🙂

Польза новых задач

По-настоящему мощь очередного фреймворка понимаешь, когда наконец-то сталкиваешься с задачей под которую он очевидно был заточен и вокруг базы под которую он обрастал. Как сейчас столкнулся на работе с необходимостью реализации немного извращённого соединения с обменом данными через TCP-сокеты сообщениями по ISO 8583. Быстрый любопытный взгляд в классы Twisted открыл что всё написано до нас, и всё, что остаётся – обернуть в красивую запускалку, дописать чуток логики и поработать над тестами, которые открыли несколько скрытых болезней. Ну и спасибо нашим админам, ещё поучиться засовывать получившийся модуль в красивый debian-пакет со скриптами и прочими свистелками :).

Мощь python и лень

Вот, что и требовалось доказать – стоило перестать лениться и откладывать «на потом», как за вечер бот из предыдущего поста научился понимать Atom (в необходимой мере) и постить в Blogger (благодаря чему обновляется ещё одно зеркало зеркало моего блога). А всё благодаря более-менее продуманной архитектуре, да удобству python и Twisted в качестве средства разработки. И зачем люди ещё пишут на PHP сложные системы…

Кстати, у Blogger’а выяснилась пара забавных моментов. Первый – это то, он строго следует спецификациям Atom при создании и редактировании сообщений. Но при этом, если отправлять ему содержимое поста с типом xhtml, завернутое в <div xmlns="http://www.w3.org/1999/xhtml">...</div>, то назад он возвращает содержимое завёрнутое как html, но при этом сохраняет этот самый div. Логика загадочна для меня.

Второй момент ещё более непонятный: по ходу тестирования я делал пачки постингов в блог. В какой-то момент получилось так, что пост проходит, возвращается назад с присвоенным id и т.п., а в блоге не появляется. Никаких намёков на то, почему так, нет. Буду пробовать дальше 🙂

Дополнение: всё оказалось очень просто. Из-за кучи постингов во время тестов blogger включил для моего аккаунта требование вводить captcha перед каждым постом. По сути можно было написать в блог только через веб-форму. Налицо явная недоработка API, так как ошибку внятную можно было и вернуть.