Python integration

The Python library is suited for native Python logging integration and for adding logging24 to existing Python applications with minimal changes. It is a real product surface for Python application logging, even though it is not the primary recommendation for general infrastructure-wide forwarding.

Positioning

If you want host-level or service-level forwarding across machines, prefer Linux Binary or l24 CLI . Use the Python path when logs should be emitted directly from Python application code through the native logging stack.

When to use this

  • You need a native Python logging handler.
  • You want to add logging24 to an existing Python application with minimal code changes.
  • Your application architecture is already centered on Python logging handlers.

How this fits in the product

logging24 has long had a Python-oriented surface alongside host-level forwarders. In the current docs set, the canonical operational forwarding paths remain the Linux binary and the l24 CLI, but the Python library remains an appropriate choice for application-level integration in Python services.

Basic handler example

handler = l24.Logging24Handler("ingest.logging24.com", "YOUR_TOKEN")
logging.getLogger().addHandler(handler)
logging.error("This goes to logging24")

Use a write token for this path and store it securely rather than embedding raw tokens directly in source code.

Operational guidance

Best fit Application-level logging from Python code through the native Python logging system.
Simple adoption path Works well when you want straightforward logging24 integration in an existing Python application.
Not ideal for General host-wide forwarding where a dedicated forwarder would be simpler and easier to operate.
Token handling Prefer environment variables or secret files over hardcoded token strings.
Timestamps Custom timestamps may be supplied when your integration needs the original event time instead of emission time.

Related links