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. |