LogXide — framework de logging em Rust para Python 12,5x mais rápido

Olá, apresentamos o LogXide para quem enfrenta gargalos de I/O de arquivos e logging em ambientes de alta carga, como aplicações web em Python e pipelines de dados.

1. Por que foi criado (The Problem)

O módulo logging padrão do Python é escrito em Python puro. Em ambientes comuns, isso é suficiente, mas em picos de tráfego ou em pipelines de logging de grande escala, ele ocupa o GIL (Global Interpreter Lock) durante operações de I/O, o que acaba degradando o desempenho de toda a aplicação.

2. Como isso foi resolvido (Architecture)

O LogXide foi implementado com a lógica central e os handlers em Rust, com bindings via PyO3.

• Python-side Level Check: com o FastLoggerWrapper, quando o nível de log está desativado (por exemplo, chamada de DEBUG com o nível INFO configurado), a chamada é descartada imediatamente no lado do Python, sem criação de PyObject nem travessia da fronteira do PyO3. Com essa otimização, a velocidade em chamadas vazias melhorou de 2 a 5 vezes.
• I/O não bloqueante: StreamHandler, HTTPHandler e OTLPHandler processam logs de forma assíncrona usando canais crossbeam e threads em segundo plano. Isso evita bloquear a thread principal da aplicação.
• write direto síncrono: no caso do FileHandler, o LogXide usa Mutex<BufWriter> para realizar I/O direto no SO e faz flush apenas quando necessário, reduzindo drasticamente o overhead de I/O.

3. Principais benchmarks (macOS ARM64, Python 3.12)

• FileHandler: 2.09M msgs/sec (contra 167K da stdlib, 12,5x mais rápido)
• StreamHandler: 2.14M msgs/sec (contra 11K da stdlib, 186x mais rápido)
• Em I/O real com formatação de arquivo, é 25% mais rápido que o Picologging, escrito em C, e 2,4x mais rápido que o Structlog, em Python puro.

4. Recursos embutidos e como usar

Basta trocar uma linha para from logxide import logging, e a estrutura permite reutilizar o código existente com logging.getLogger() como está. Seguindo as tendências recentes de arquitetura de backend, os seguintes handlers já vêm embutidos em nível nativo de Rust:

• OTLPHandler: envio direto baseado em Protobuf sem agente OpenTelemetry
• HTTPHandler: recurso de envio em lote (Batch)
• SentryHandler: suporte integrado para logging de erros (pip install logxide[sentry])
• ColorFormatter: suporte a saída colorida no terminal com caracteres de controle ANSI

5. Limitações claras (Trade-offs)

Ao avaliar a adoção, é importante saber que ele não é um drop-in replacement 100% compatível:

• Não é possível registrar handlers customizados escritos em Python herdando de logging.Handler. (Para manter o melhor desempenho, é preciso usar apenas os handlers embutidos implementados em Rust).
• Não é possível criar subclasses de Logger ou LogRecord.
• Em ambientes de pytest, é necessário usar a fixture caplog_logxide fornecida pelo LogXide em vez do caplog embutido.

Se você estava procurando um logger baseado em C ou uma biblioteca de logging estruturado por causa de gargalos de desempenho, esta pode ser uma excelente alternativa! A documentação oficial também inclui guias de integração prontos para Django, FastAPI e Flask, então vale a pena dar uma olhada e enviar seu feedback.

• Documentação oficial: https://indosaram.github.io/logxide/