Python package for logging to LogDNA
bash
$ pip install logdna
```python import logging from logdna import LogDNAHandler import os
key=os.environ['INGESTION_KEY']
log = logging.getLogger('logdna') log.setLevel(logging.INFO)
options = { 'hostname': 'pytest', 'ip': '10.0.1.1', 'mac': 'C0:FF:EE:C0:FF:EE' }
options['index_meta'] = True options['custom_fields'] = 'meta'
test = LogDNAHandler(key, options)
log.addHandler(test)
log.warning("Warning message", extra={'app': 'bloop'}) log.info("Info message")
``` Required * LogDNA Ingestion Key
Optional
* Hostname - (string)
* MAC Address - (string)
* IP Address - (string)
* Index Meta - (bool) - formatted as options['index_meta']
After initial setup, logging is as easy as: ```python
log.info('My Sample Log Line')
log.info('My Sample Log Line', extra={ 'level': 'MyCustomLevel' })
log.info('My Sample Log Line', extra={ 'level': 'Warn', 'app': 'myAppName'})
meta = { 'foo': 'bar', 'nested': { 'nest1': 'nested text' } }
opts = { 'level': 'warn', 'meta': meta }
log.info('My Sample Log Line', extra=opts) ```
To use LogDNAHandler with fileConfig (e.g., in a Django settings.py
file):
``python
import os
import logging
from logdna import LogDNAHandler # required to register
logging.handlers.LogDNAHandler`
LOGGING = {
# Other logging settings...
'handlers': {
'logdna': {
'level': logging.DEBUG,
'class': 'logging.handlers.LogDNAHandler',
'key': os.environ.get('LOGDNA_INGESTION_KEY'),
'options': {
'app': '
(This example assumes you have set environment variables for ENVIRONMENT
and LOGDNA_INGESTION_KEY
.)
<your ingestion key>
The LogDNA API Key associated with your account.
''
<your custom app>
The default app named that is included in every every log line sent through this instance.
''
<your custom env>
The default env passed along with every log sent through this instance.
''
<your custom hostname>
The default hostname passed along with every log sent through this instance.
False
Python LogRecord objects includes language-specific information that may be useful metadata in logs.
Setting include_standard_meta
to True
automatically populates meta objects with name
, pathname
, and lineno
from the LogRecord.
WARNING This option is deprecated and will be removed in the upcoming major release.
False
We allow meta objects to be passed with each line. By default these meta objects are stringified and not searchable, and are only displayed for informational purposes.
If this option is set to True then meta objects are parsed and searchable up to three levels deep. Any fields deeper than three levels are stringified and cannot be searched.
WARNING If this option is True, your metadata objects MUST have consistent types across all log messages or the metadata object might not be parsed properly.
Info
Debug
, Trace
, Info
, Warn
, Error
, Fatal
, <your custom level>
The default level passed along with every log sent through this instance.
Sets the verbosity of log statements for failures.
30000
The amount of time (in ms) the request should wait for LogDNA to respond before timing out.
List of tags used to dynamically group hosts. More information on tags is available at How Do I Use Host Tags?
'https://logs.logdna.com/logs/ingest'
A custom ingestion endpoint to stream log lines into.
List of fields out of record
object to include in the meta
object. By default, args
, name
, pathname
, and lineno
will be included.
False
Enables logging of the API response when an HTTP error is encountered
''
The log line to be sent to LogDNA.
Info
Debug
, Trace
, Info
, Warn
, Error
, Fatal
, <your custom level>
The level passed along with this log line.
''
<your custom app>
The app passed along with this log line.
''
<your custom env>
The environment passed with this log line.
None
A standard dictonary containing additional metadata about the log line that is passed. Please ensure values are JSON serializable.
NOTE: Values that are not JSON serializable will be removed and the respective keys will be added to the __errors
string.
False
We allow meta objects to be passed with each line. By default these meta objects will be stringified and will not be searchable, but will be displayed for informational purposes.
If this option is turned to true then meta objects will be parsed and will be searchable up to three levels deep. Any fields deeper than three levels will be stringified and cannot be searched.
WARNING When this option is true, your metadata objects across all types of log messages MUST have consistent types or the metadata object may not be parsed properly!
The time in seconds since the epoch to use for the log timestamp. It must be within one day or current time - if it is not, it is ignored and time.time() is used in its place.
This project makes use of the poetry package manager for local development.
shell
$ poetry install
lint Run linting rules w/o attempting to fix them
shell
$ poetry run task lint
lint:fix
Run lint rules against all local python files and attempt to fix where possible.
shell
$ poetry run task lint:fix
test:
Runs all unit tests and generates coverage reports
shell
poetry run task test
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!
MIT © LogDNA Copyright © 2017 LogDNA, released under an MIT license. See the LICENSE file and https://opensource.org/licenses/MIT
Happy Logging!
Bumps cryptography from 39.0.0 to 39.0.1.
Sourced from cryptography's changelog.
39.0.1 - 2023-02-07
* **SECURITY ISSUE** - Fixed a bug where ``Cipher.update_into`` accepted Python buffer protocol objects, but allowed immutable buffers. **CVE-2023-23931** * Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.0.8.
.. _v39-0-0:
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase
.
After upgrading from 1.18.0, we noticed running our celery worker hanging and tracked it down to this:
```python from logging.config import dictConfig from django.conf import settings from celery.signals import setup_logging
@setup_logging.connect def config_loggers(args, *kwargs): dictConfig(settings.LOGGING) ```
Double-checking and removing celery from the picture, we could get a hang by just calling dictConfig
from the shell.
Downgrading to 1.18.0 resolved the issue.
Breaking the manual hang in the shell results in this stack trace:
```
dictConfig(settings.LOGGING) ^CTraceback (most recent call last): File "/app/.heroku/python/lib/python3.9/code.py", line 90, in runcode exec(code, self.locals) File "
", line 1, in File "/app/.heroku/python/lib/python3.9/logging/config.py", line 809, in dictConfig dictConfigClass(config).configure() File "/app/.heroku/python/lib/python3.9/logging/config.py", line 537, in configure _clearExistingHandlers() File "/app/.heroku/python/lib/python3.9/logging/config.py", line 274, in _clearExistingHandlers logging.shutdown(logging._handlerList[:]) File "/app/.heroku/python/lib/python3.9/logging/init.py", line 2142, in shutdown h.close() File "/app/.heroku/python/lib/python3.9/site-packages/logdna/logdna.py", line 265, in close self.request_thread_pool.shutdown(wait=True) File "/app/.heroku/python/lib/python3.9/concurrent/futures/thread.py", line 235, in shutdown t.join() File "/app/.heroku/python/lib/python3.9/threading.py", line 1053, in join self._wait_for_tstate_lock() File "/app/.heroku/python/lib/python3.9/threading.py", line 1073, in _wait_for_tstate_lock if lock.acquire(block, timeout): KeyboardInterrupt ```
This task consists of subtasks of getting this library fully covered and having integration testing
d00b952
)e326e4c
)lib