Request Demo
Integrations

Python

Install


$ pip install coralogix_logger

Or directly from the sources:

$ git clone https://github.com/coralogix/python-coralogix-sdk.git
$ cd sdk-python
$ python setup.py install

Configuration

Using Coralogix SDK requires four mandatory parameters and one optional parameter:

private_key (String): The private key is the password for your company, used to validate your authenticity. This key will be sent to your mail once you register to Coralogix.

application Name(String): The name of your main application. For example, a company named Startup which develops app_1 and app_2 can use “Startup app_1” and “Startup app_2” for this parameter; or if they want to debug their test environment they might insert the “Startup app_1 – Test” or “Startup app_1 – Staging”.

subsystem Name(String): The name of your sub-system. Your application probably has multiple subsystems, e.g. “Backend servers”, “Middleware”, “Frontend servers”, “Database servers” etc. In order to help you examine only the data you need, inserting the subsystem parameter is vital.

Implementation

Adding Coralogix logging handler in your logging system:

import logging
# For version 1.x. 
from coralogix.coralogix_logger import CoralogixLogger
# For version 2.x and above. 
from coralogix.handlers import CoralogixLogger

PRIVATE_KEY = "[YOUR_PRIVATE_KEY_HERE]"
APP_NAME = "[YOUR_APPLICATION_NAME]"
SUB_SYSTEM = "[YOUR_SUBSYTEM_NAME]"

# Get an instance of Python standard logger.
logger = logging.getLogger("Python Logger")
logger.setLevel(logging.DEBUG)

# Get a new instance of Coralogix logger.
coralogix_handler = CoralogixLogger(PRIVATE_KEY, APP_NAME, SUB_SYSTEM)

# Add coralogix logger as a handler to the standard Python logger.
logger.addHandler(coralogix_handler)

# Send message
logger.info("Hello World!")
CoralogixLogger.flush_messages()

Also, you can configure the SDK with dictConfig for Python logging library:

import logging PRIVATE_KEY = '[YOUR_PRIVATE_KEY_HERE]' APP_NAME = '[YOUR_APPLICATION_NAME]' SUB_SYSTEM = '[YOUR_SUBSYSTEM_NAME]' logging.config.dictConfig({ 'version': 1, 'disable_existing_loggers': False, 'formatters': { 'default': { 'format': '[%(asctime)s]: %(levelname)s: %(message)s', } }, 'handlers': { 'coralogix': { 'class': 'coralogix.handlers.CoralogixLogger', 'level': 'DEBUG', 'formatter': 'default', 'private_key': PRIVATE_KEY, 'app_name': APP_NAME, 'subsystem': SUB_SYSTEM, } }, 'root': { 'level': 'DEBUG', 'handlers': [ 'coralogix', ] }, 'loggers': { 'backend': { 'level': 'DEBUG', 'handlers': [ 'coralogix', ] } } })

uWSGI:

By default, uWSGI does not enable threading support within the Python interpreter core. This means it is not possible to create background threads from Python code. As the Coralogix logger relies on being able to create a background thread (for sending logs), this option is required.

You can enable threading either by passing –enable-threads to uWSGI command line:


$ uwsgi wsgi.ini --enable-threads

Another option is to enable threads in your wsgi.ini file:

wsgi.ini:


enable-threads = true


If you are using multiple processes/workers and you don’t use “lazy-apps = true” then you must wait for the process to finish the fork before you can send logs with Coralogix logger.

You can configure the logger during the initialization process but you must wait for the fork to complete before you can actually send your logs.

You can use uWSGI @postfork decorator to be sure when it’s safe to use Coralogix logger:

import uwsgi
from uwsgidecorators import *

@postfork
def on_worker_ready():
    #It is now safe to send logs with Coralogix logger

Need help? We love to assist our customers, simply book your implementation session, and we will walk you through, step by step.

Start solving your production issues faster

Let's talk about how Coralogix can help you

Managed, scaled, and compliant monitoring, built for CI/CD

Get a demo

No credit card required

Get a personalized demo

Jump on a call with one of our experts and get a live personalized demonstration