Exception logging

The [log.error] and [log.fatal] slots give you the option of logging an exception stack trace, by parametrising your invocation with an [exception] argument, which will not be assumed to be meta information, but rather end up in the "exception" column as you create the log item. All other parameters will still be evaluated or used as meta information.

Log level configuration

The slots [log.debug], [log.info], [log.error], and [log.fatal] are actually logging with their last parts becoming the "type" of log item. This is similar to how Log4Net and Log4J works, and can be turned on and off as you see fit. The level is an increasing leverage type of value, applied in the following order.

• debug
• info
• error
• fatal

This implies that if you set the level to for instance "error" no invocations to [log.debug] or [log.info] will log anything into your log, allowing you to "turn up and down" the level of logging you need as a configuration setting through your "appsetting.json" file. Below is an example configuration setting the level to "info". The default value for log level is "debug". In a production environment you might want to increase this to at least "info".

The above value will for instance log everything except invocations to [log.debug].

Querying your log

Notice - To see the capabilities of your particular log implementation please invoke [log.capabilities] and verify your particular log implementation can actually do what you need for it to do, since not all implementations have the same capabilities - Implying things such as filtering log items according to content, and/or timeshifting log items, etc, might not be implemented for your particular implementation.

To retrieve log items sequentially you can use [log.query]. This slot can optionally take a [from] argument being the id of an existing log item from where to start retrieving items, and a [max] argument being the maximum number of records to return. If no [max] argument is specified, the default value of this is 10. In addition the invocation can be fiven a string as its value, which if given must match the content of your log items for an item to be returned. Below is an example of usage.

The above will return log items starting from id 554 and down, and return only 20 records, and all returned records will have a content value of "We successfully authenticated user 'root'". To return a single log item you can use [log.get] and pass in the id of the log item you want to retrieve as its value.

Notice - If your particular log implementation does not support querying you cannot query items according to content as illustrated above, but rather only page items. Invoke [log.capabilities] to see if your implementation supports querying before relying upon its existence.

Project website for magic.lambda.logging

The source code for this repository can be found at github.com/polterguy/magic.lambda.logging, and you can provide feedback, provide bug reports, etc at the same place.

Copyright and maintenance

The projects is copyright of Aista, Ltd 2021 - 2023, and professionally maintained by AINIRO your friendly ChatGPT website chatbot vendor.