From f7f20c3f5e0be02585741f5f54d198689ccd7866 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Mon, 15 Apr 2024 18:27:18 +0200 Subject: Adding upstream version 8.2402.0+dfsg. Signed-off-by: Daniel Baumann --- source/configuration/modules/workflow.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 source/configuration/modules/workflow.rst (limited to 'source/configuration/modules/workflow.rst') diff --git a/source/configuration/modules/workflow.rst b/source/configuration/modules/workflow.rst new file mode 100644 index 0000000..9df5f74 --- /dev/null +++ b/source/configuration/modules/workflow.rst @@ -0,0 +1,30 @@ +Where are the modules integrated into the Message Flow? +======================================================= + +Depending on their module type, modules may access and/or modify +messages at various stages during rsyslog's processing. Note that only +the "core type" (e.g. input, output) but not any type derived from it +(message modification module) specifies when a module is called. + +The simplified workflow is as follows: + +.. figure:: module_workflow.png + :align: center + :alt: module_workflow + +As can be seen, messages are received by input modules, then passed to +one or many parser modules, which generate the in-memory representation +of the message and may also modify the message itself. The internal +representation is passed to output modules, which may output a message +and (with the interfaces introduced in v5) may also modify +message object content. + +String generator modules are not included inside this picture, because +they are not a required part of the workflow. If used, they operate "in +front of" the output modules, because they are called during template +generation. + +Note that the actual flow is much more complex and depends a lot on +queue and filter settings. This graphic above is a high-level message +flow diagram. + -- cgit v1.2.3