strigo / wryte Goto Github PK

To support:

logger.info('message', x=y)

Instead of having to provide a plethora of fields every time something happens, it would make sense to allow to create child loggers consisting of permanent fields:

wryte = Wryte()
new_wryte = wryte.child({'key1': 'value1'})
new_wryte.info(...)
...

new_wryte will include the key1 field for every log message it generates.

Instantiating the handler with coloring options could automatically color warning yellow, error in red and critical in maroon or something.

https://docs.python.org/3/howto/logging-cookbook.html#adding-contextual-information-to-your-logging-output

Since kv pair string support in the context was removed in the API, it now isn't supported in the CLI either. We should add that back for the CLI only.

By enabling via a flag or an env var, we should support adding things like the instance-id, instance-type, region and local ipv4 to each log message.

For example, log.info({}) will fail as the first field is expected to be a string.

• SyslogHandler
• File Handlers (rotating, watching, etc..)
• HTTPHandler
• Graylog2 (https://github.com/severb/graypy or https://github.com/keeprocking/pygelf)
• Logentries (https://github.com/LogentriesCommunity/le_python)
• CloudWatch (https://github.com/kislyuk/watchtower or https://github.com/osperlabs/logbeam)
• Logmatic (https://github.com/logmatic/logmatic-python)
• RMQ (https://github.com/albertomr86/python-logging-rabbitmq)
• Kafka (https://github.com/taykey/python-kafka-logging, https://stackoverflow.com/questions/21102293/how-to-write-to-kafka-from-python-logging-module)
• Papertrail (via syslog? https://help.papertrailapp.com/kb/configuration/configuring-centralized-logging-from-python-apps/)
• Loggly (https://github.com/varshneyjayant/loggly-python-handler)
• Fluentd log collector (https://github.com/fluent/fluent-logger-python)
• Logstash (http://python-logstash-async.readthedocs.io/en/latest/usage.html)

Let's say that you just received a login event (e.g. wryte.info('User Logged In)).
You would now like to follow up that that event throughout its logs (db connections, etc..).

It would be good to allow to bind an auto-generated context_id which will follow the event until it finishes and then lose the id.

https://github.com/logzio/logzio-python-handler

The current default format is timestamp - name - level - message. We should allow to simply log message by providing a flag when instantiating the logger.

We can use the logger.findCaller() method to retrieve stack information.

This should be configurable via WRYTE_INCLUDE_SRC and a method flag and should be documented that it shouldn't be used in production as it degrades performance greatly.

Just like EC2

It would be nice to support automated delivery of exceptions, nicely formatted, when an exception object is passed to the logger.

https://github.com/cmanaha/python-elasticsearch-logger/blob/master/cmreslogging/handlers.py#L61

Currently only basic config options are allowed.

on:

• Logger hierarchy
• Reserved fields
• Examples on how to provide log objects (key=value, multiple-dicts, nested dicts, etc..)
• Reorganize the docs to be much clearer.

Something like wryter.info('my_message', _nl=False) would make sense.

When using the simple flag, Wryte should output kv pairs like so:

2018-04-10T21:58:53.682506 - Wryte - INFO - w00t - key1=value1 key2=value2

Pros:

Single line log messages

Cons:

May overflow a single line and then be half readable

An event implies that "Something applicative happened now". e.g. user logged in or credit card transaction made.

It would be useful to add a type field which will default to type=log. When sending an event via wryte.event, it can append a type=event kv instead. This will allow users to search only on events instead of their context (the logs).

e.g. wryter.info('my_message', _fg='green', _bg='white')

Much like Grafana's env-var based configuration, it would be nice to support configuring wryte via environment variables.

For instance:

WRYTE_LOGGER_NAME_aggr_elasticsearch_endpoint would configure the logger named LOGGER_NAME to emit JSON formatted logs to the endpoint provided.

Like so:

WRYTE_LOGGER_NAME_console_enabled
WRYTE_LOGGER_NAME_console_level
WRYTE_LOGGER_NAME_aggr_elasticsearch_endpoint # implicit enablement
WRYTE_LOGGER_NAME_aggr_elasticsearch_level
WRYTE_LOGGER_NAME_aggr_logzio_enabled # implicit enablement
WRYTE_LOGGER_NAME_aggr_logzio_level
WRYTE_LOGGER_NAME_aggr_logzio_token
...

To increase performance, maybe a conversion table for severity levels can be avoided and the user should take the hit if providing a wrongly named level (uppercase, lowercase, etc..)