1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
<html>
<head>
<title>syslogd generic design</title>
</head>
<body>
<h2>Generic design of a syslogd</h2>
<p>Written 2007-04-10 by
<a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a></p>
<p>The text below describes a generic approach on how a syslogd can be
implemented. I created this description for some other project, where it was not
used. Instead of throwing it away, I thought it would be a good addition to the
rsyslog documentation. While rsyslog differs in details from the description
below, it is sufficiently close to it. Further development of rsyslog will
probably match it even closer to the description.</p>
<p>If you intend to read the rsyslog source code, I recommend reading this
document here first. You will not find the same names and not all of the
concepts inside rsyslog. However, I think your understanding will benefit from
knowing the generic architecture.</p>
<font size="3"><pre>
+-----------------+
| "remote" PLOrig |
+-----------------+
|
I +--------+-----+-----+ +-----+-------+------+-----+
P | PLOrig | GWI | ... | | GWO | Store | Disc | ... |
C +--------+-----+-----+ +-----+-------+------+-----+
| | ^
v v |
+--------------+ +------------+ +--------------+
| PLGenerator | | RelayEng | | CollectorEng |
+--------------+ +------------+ +--------------+
| ^ ^
| | |
v v |
+-------------+ +------------+ +--------------+
| PLG Ext | | RelEng Ext | | CollcEng Ext |
+-------------+ +------------+ +--------------+
| ^ ^
| | |
v v |
+--------------------------------------------------------------+
| Message Router |
+--------------------------------------------------------------+
| ^
v |
+--------------------------------------------------------------+
| Message CoDec (e.g. RFC 3164, RFCYYYY) |
+--------------------------------------------------------------+
| ^
v |
+---------------------+-----------------------+----------------+
| transport UDP | transport TLS | ... |
+---------------------+-----------------------+----------------+
Generic Syslog Application Architecture
</pre></font>
<ul>
<li>A "syslog application" is an application whose purpose is the
processing of syslog messages. It may be part of a larger
application with a broader purpose. An example: a database
application might come with its own syslog send subsystem and not
go through a central syslog application. In the sense of this
document, that application is called a "syslog application" even
though a casual observer might correctly call it a database
application and may not even know that it supports sending of
syslog messages.</li>
<li>Payload is the information that is to be conveyed. Payload by
itself may have any format and is totally independent from to
format specified in this document. The "Message CoDec" of the
syslog application will bring it into the required format.</li>
<li>Payload Originators ("PLOrig") are the original creators of payload.
Typically, these are application programs.</li>
<li>A "Remote PLOrig" is a payload originator residing in a different
application than the syslog application itself. That application
may reside on a different machine and may talk to the syslog
application via RPC.</li>
<li>A "PLOrig" is a payload originator residing within the syslog
application itself. Typically, this PLOrig emits syslog
application startup, shutdown, error and status log messages.</li>
<li>A "GWI" is a inbound gateway. For example, a SNMP-to-syslog
gateway may receive SNMP messages and translate them into syslog.</li>
<li>The ellipsis after "GWI" indicates that there are potentially a
variety of different other ways to originally generate payload.</li>
<li>A "PLGenerator" is a payload generator. It takes the information
from the payload-generating source and integrates it into the
syslog subsystem of the application. This is a highly theoretical
concept. In practice, there may not actually be any such
component. Instead, the payload generators (or other parts like
the GWI) may talk directly to the syslog subsystem. Conceptually,
the "PLGenerator" is the first component where the information is
actually syslog content.</li>
<li>A "PLG Ext" is a payload generator extension. It is used to
modify the syslog information. An example of a "PLG Ext" might be
the addition of cryptographic signatures to the syslog
information.</li>
<li>A "Message Router" is a component that accepts in- and outbound
syslog information and routes it to the proper next destination
inside the syslog application. The routing information itself is
expected to be learnt by operator configuration.</li>
<li>A "Message CoDec" is the message encoder/decoder. The encoder
takes syslog information and encodes them into the required format<br>for a syslog message. The decoder takes a syslog message and
decodes it into syslog information. Codecs for multiple syslog
formats may be present inside a single syslog application.</li>
<li>A transport (UDP, TLS, yet-to-be-defined ones) sends and receives
syslog messages. Multiple transports may be used by a single<br>syslog application at the same time. A single transport instance
may be used for both sending and receiving. Alternatively, a
single instance might be used for sending and receiving
exclusively. Multiple instances may be used for different
listener ports and receivers.</li>
<li>A "RelayEng" is the relaying engine. It provides functionality
necessary for receiving syslog information and sending it to
another syslog application.</li>
<li>A "RelEng Ext" is an extension that processes syslog information
as it enters or exits a RelayEng. An example of such a component
might be a relay cryptographically signing received syslog
messages. Such a function might be useful to guarantee authenticity
starting from a given point inside a relay chain.</li>
<li>A "CollectorEng" is a collector engine. At this component, syslog
information leaves the syslog system and is translated into some
other form. After the CollectorEng, the information is no longer
defined to be of native syslog type.</li>
<li>A "CollcEng Ext" is a collector engine extension. It modifies
syslog information before it is passed on to the CollectorEng. An
example for this might be the verification of cryptographically
signed syslog message information. Please note that another
implementation approach would be to do the verification outside of
the syslog application or in a stage after "CollectorEng".</li>
<li>A "GWO" is an outbound gateway. An example of this might be the
forwarding of syslog information via SNMP or SMTP. Please note
that when a GWO directly connects to a GWI on a different syslog
application, no native exchange of syslog information takes place.
Instead, the native protocol of these gateways (e.g. SNMP) is
used. The syslog information is embedded inside that protocol.
Depending on protocol and gateway implementation, some of the
native syslog information might be lost.</li>
<li>A "Store" is any way to persistently store the extracted syslog
information, e.g. to the file system or to a data base.</li>
<li>"Disc" means the discarding of messages. Operators often find it
useful to discard noise messages and so most syslog applications<br>contain a way to do that.</li>
<li>The ellipsis after "Disc" indicates that there are potentially a variety of different other ways to consume syslog information.</li>
<li>There may be multiple instances of each of the described
components in a single syslog application.</li>
<li>A syslog application is made up of all or some of the above
mentioned components.</li>
</ul>
</p>
</body>
</html>
|
