Skip to content

fluent/fluent-logger-python

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

A Python structured logger for Fluentd/Fluent Bit

Many web/mobile applications generate huge amount of event logs (c,f. login, logout, purchase, follow, etc). To analyze these event logs could be really valuable for improving the service. However, the challenge is collecting these logs easily and reliably.

Fluentd and Fluent Bit solves that problem by having: easy installation, small footprint, plugins, reliable buffering, log forwarding, etc.

fluent-logger-python is a Python library, to record the events from Python application.

Requirements

  • Python 3.7+
  • msgpack
  • IMPORTANT: Version 0.8.0 is the last version supporting Python 2.6, 3.2 and 3.3
  • IMPORTANT: Version 0.9.6 is the last version supporting Python 2.7 and 3.4
  • IMPORTANT: Version 0.10.0 is the last version supporting Python 3.5 and 3.6

Installation

This library is distributed as 'fluent-logger' python package. Please execute the following command to install it.

Configuration

Fluentd daemon must be launched with a tcp source configuration:

<source>
  type forward
  port 24224
</source>

To quickly test your setup, add a matcher that logs to the stdout:

<match app.**>
  type stdout
</match>

Usage

FluentSender Interface

sender.FluentSender is a structured event logger for Fluentd.

By default, the logger assumes fluentd daemon is launched locally. You can also specify remote logger by passing the options.

For sending event, call emit method with your event. Following example will send the event to fluentd, with tag 'app.follow' and the attributes 'from' and 'to'.

To send events with nanosecond-precision timestamps (Fluent 0.14 and up), specify nanosecond_precision on FluentSender.

You can detect an error via return value of emit. If an error happens in emit, emit returns False and get an error object using last_error method.

If you want to shutdown the client, call close() method.

Event-Based Interface

This API is a wrapper for sender.FluentSender.

First, you need to call sender.setup() to create global sender.FluentSender logger instance. This call needs to be called only once, at the beginning of the application for example.

Initialization code of Event-Based API is below:

Then, please create the events like this. This will send the event to fluentd, with tag 'app.follow' and the attributes 'from' and 'to'.

event.Event has one limitation which can't return success/failure result.

Other methods for Event-Based Interface.

Handler for buffer overflow

You can inject your own custom proc to handle buffer overflow in the event of connection failure. This will mitigate the loss of data instead of simply throwing data away.

You should handle any exception in handler. fluent-logger ignores exceptions from buffer_overflow_handler.

This handler is also called when pending events exist during close().

Python logging.Handler interface

This client-library also has FluentHandler class for Python logging module.

You can also customize formatter via logging.config.dictConfig

You can inject your own custom proc to handle buffer overflow in the event of connection failure. This will mitigate the loss of data instead of simply throwing data away.

A sample configuration logging.yaml would be:

Asynchronous Communication

Besides the regular interfaces - the event-based one provided by sender.FluentSender and the python logging one provided by handler.FluentHandler - there are also corresponding asynchronous versions in asyncsender and asynchandler respectively. These versions use a separate thread to handle the communication with the remote fluentd server. In this way the client of the library won't be blocked during the logging of the events, and won't risk going into timeout if the fluentd server becomes unreachable. Also it won't be slowed down by the network overhead.

The interfaces in asyncsender and asynchandler are exactly the same as those in sender and handler, so it's just a matter of importing from a different module.

For instance, for the event-based interface:

or for the python logging interface:

NOTE: please note that it's important to close the sender or the handler at program termination. This will make sure the communication thread terminates and it's joined correctly. Otherwise the program won't exit, waiting for the thread, unless forcibly killed.

Circular queue mode

In some applications it can be especially important to guarantee that the logging process won't block under any circumstance, even when it's logging faster than the sending thread could handle (backpressure). In this case it's possible to enable the circular queue mode, by passing True in the queue_circular parameter of asyncsender.FluentSender or asynchandler.FluentHandler. By doing so the thread doing the logging won't block even when the queue is full, the new event will be added to the queue by discarding the oldest one.

WARNING: setting queue_circular to True will cause loss of events if the queue fills up completely! Make sure that this doesn't happen, or it's acceptable for your application.

Testing

Testing can be done using pytest.

Release

Contributors

Patches contributed by those people.

License

Apache License, Version 2.0