Современные сервисы и особенно микро-сервисы требуют обширного мониторинга. Но дело в том, что кроме общих соображений и статей вроде 4 golden signals не так уж и много информации как и что мониторить. И каждый раз приходится эту проблему решать вновь.

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

Я не пытаюсь объять всё возможное, но если вы пишите back сервисы, используете rest, вебсокеты, event driven архитектуру и пока не успели обрасти мониторингом, то в этом докладе вы сможете найти много полезного.

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

В своем докладе на Стачке 2024 я предлагаю:

* окунуться во все разнообразие идей для тестирования

* отобрать наиболее актуальные и интересные решения

* предложить сборку мечты для тестирования на суд Python сообществу

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

Чем интересна данная тема для обсуждения? Это будет поверхностный обзор архитектуры событийных систем, с открытым для предложений окном.

Модный и популярный сейчас среди Go разработчиков протокол gRPC основан на Protobuf, который существует в нескольких версиях, сложность с Protobuf на Python в том, что Python 3 асинхронный лишь условно, а декодирование Protobuf блокирует другие операции системы так как по интерпретатор ограничен одним процессом.

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

Ручки сервиса будут просто проксировать приходящие Protobuf события так как они пришли в kafka, после чего отдельное приложение будет вычитывать сообщения и обрабатывать события.

Я - автор библиотеки / CLI-инструмента INSTLD (https://github.com/pomponchik/instld). Он под завязку набит питонячьей магией, в частности переопределяет машинерию импортов, парсит исходные коды программ и так далее. На конференции я расскажу самые интересные подробности внутрянки, например:

- Как сделать так, чтобы при выполнении инструкции import вызывался ваш собственный код?

- Как реализовывать метаязыки на базе комментариев? Как для этого научиться прочитать комментарий из кодовой базы в рантайме и парсить его.

- Как обеспечить временную установку пакетов во временную директорию?

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