Can't create two handlers with different configurations

[d1skort]

import logging
import sys
from logstash_async.handler import AsynchronousLogstashHandler


host = 'localhost'

test_logger1 = logging.getLogger('python-logstash-logger')
test_logger1.setLevel(logging.INFO)
test_logger1.addHandler(AsynchronousLogstashHandler(
    host,
    5002,
    database_path=None,
    transport='logstash_async.transport.UdpTransport'
))

test_logger1.info('logger1')


test_logger2 = logging.getLogger('python-logstash-logger2')
test_logger2.setLevel(logging.INFO)
test_logger2.addHandler(AsynchronousLogstashHandler(
    host,
    5000,
    database_path=None,
    transport='logstash_async.transport.UdpTransport'
))


test_logger2.info('logger2')  # goes to 5002 port :(

I think problem is here:

 class AsynchronousLogstashHandler(Handler):
     """Python logging handler for Logstash. Sends events over TCP by default.
     :param host: The host of the logstash server, required.
     :param port: The port of the logstash server, required.
     :param database_path: The path to the file containing queued events, required.
     :param transport: Callable or path to a compatible transport class.
     :param ssl_enable: Should SSL be enabled for the connection? Default is False.
     :param ssl_verify: Should the server's SSL certificate be verified?
     :param keyfile: The path to client side SSL key file (default is None).
     :param certfile: The path to client side SSL certificate file (default is None).
     :param ca_certs: The path to the file containing recognized CA certificates.
     :param enable: Flag to enable log processing (default is True, disabling
                   might be handy for local testing, etc.)
     :param event_ttl: Amount of time in seconds to wait before expiring log messages in
                       the database. (Given in seconds. Default is None, and disables this feature)
     """
 
     _worker_thread = None
...

_worker_thread -- class based attribute and shares between different handlers

[stephenpaulger]

@d1skort did you find a workaround for this?

[d1skort]

Hello! Nope.

[stephenpaulger]

@d1skort ok, thanks for getting back to me. It's a shame as I've been using this with a single handler in prod for months without issue. I'll have to look at getting logstash managing the splitting out of logs.

[eht16]

A simple solution could be to seperate the events in Logstash by the logger name.

[jloehel]

A simple solution could be to seperate the events in Logstash by the logger name.

Can I work on this issue?

[eht16]

A simple solution could be to seperate the events in Logstash by the logger name.

Can I work on this issue?

What exactly do you want to work on? The quoted sugestion is to be done in the Logstash configuration, nothing this library can do.

An alternative would be to use multiple worker threads, one per configured log handler or so. Or using one worker thread with multiple transports which then need to be mapped to the configured handlers to route the log events to the proper transport. Both of this variants involves much overhead in managing multiple worker threads or multiple transports. I don't think it would improve this library and so probably won't accept a PR.

IMO this is done easier in Logstash.

[jloehel]

A simple solution could be to seperate the events in Logstash by the logger name.

Can I work on this issue?

What exactly do you want to work on? The quoted sugestion is to be done in the Logstash configuration, nothing this library can do.

An alternative would be to use multiple worker threads, one per configured log handler or so. Or using one worker thread with multiple transports which then need to be mapped to the configured handlers to route the log events to the proper transport. Both of this variants involves much overhead in managing multiple worker threads or multiple transports. I don't think it would improve this library and so probably won't accept a PR.

IMO this is done easier in Logstash.

Okay, I thought it is still an issue.