We've been hoping that mkdocs-material will ship the much anticipated search enhancements for some time, but it's time to recognize that we need to do something to improve the search results with how things work right now. This is a big commit that changes the titles of the various pages from the code-annotated synopsis to just the name of the function. This makes it much easier now to match things like `kumo.reject` directly, but `reject` remains awkward to find. I think this is the best that we can do at this time. A few functions have been annotated with the `status: deprecated` to show as deprecated in the toc/nav (shows with a little trash can next to the name).
2.0 KiB
tags
| tags | |
|---|---|
|
kumo.configure_log_hook
kumo.configure_log_hook { PARAMS }
Configures the lua logging hook. When enabled, each matching log event will cause a new Message to be generated and have its body assigned to the log record (or to its template expansion if you have configured that), and passed to the should_enqueue_log_record event.
kumo.on('init', function()
kumo.configure_log_hook {
-- name will be passed to should_enqueue_log_record as the hook_name
-- parameter so that you can reason about different instances of the
-- log hook in the case where you are sending data to multiple
-- different places.
name = 'webhook',
headers = { 'Subject', 'X-Customer-ID' },
}
end)
This allows you to utilize KumoMTA's internal queueing to dispatch log events to external systems such as webhooks or some external queuing system for processing elsewhere in your deployment architecture.
See should_enqueue_log_record for an example.
The following options are configurable for the logging hook and work the same way as their counterparts in local log file logging. Rather than duplicate the information here, this section links to those options:
In addition, the following options are supported:
name
{{since('2023.08.22-4d895015', indent=True)}}
Required string naming the hook.
The name will be passed as the *hook_name* parameter to the
[should_enqueue_log_record](../events/should_enqueue_log_record.md) event.
deferred_spool
If set to true, the generated message will not be immediately saved to the
spool in the case that your
should_enqueue_log_record indicates
that the message should be queued.