Extensible Markup Language (XML) is a text-based open standard designed for both human-readable and machine-readable data interchange. Like JSON, it is used primarily to transmit data between a server and web application. It is described in W3C Recommendation: Extensible Markup Language (XML).
The XML parser processes input in XML format, and adds the parsed data to the message object.
To create an XML parser, define an xml_parser that has the xml() option. By default, the parser will process the ${MESSAGE} part of the log message. To process other parts of a log message using the XML parser, use the template() option. You can also define the parser inline in the log path.
parser xml_name {
xml(
template()
prefix()
drop-invalid()
exclude-tags()
strip-whitespaces()
);
};In the following example, the source is an XML-encoded log message. The destination is a file that uses the format-json template. The log line connects the source, the destination and the parser.
source s_local {
file("/tmp/aaa");
};
destination d_local {
file(
"/tmp/bbb"
template("$(format-json .xml.*)\n")
);
};
parser xml_parser {
xml();
};
log {
source(s_local);
parser(xml_parser);
destination(d_local);
};
You can also define the parser inline in the log path.
log {
source(s_file);
parser { xml(prefix(".SDATA")); };
destination(d_file);
};The XML parser inserts an ".xml" prefix by default before the extracted name-value pairs. Since format-json replaces a dot with an underscore at the beginning of keys, the ".xml" prefix becomes "_xml". Attributes get an _ prefix. For example, from the XML input:
<tags attr='attrval'>part1<tag1>Tag1 Leaf</tag1>part2<tag2>Tag2 Leaf</tag2>part3</tags>
The following output is generated:
{"_xml":{"tags":{"tag2":"Tag2 Leaf","tag1":"Tag1 Leaf","_attr":"attrval","tags":"part1part2part3"}}}
When the text is separated by tags on different levels or tags on the same level, the parser simply concatenates the different parts of text. For example, from this input XML:
<tag> <tag1>text1</tag1> <tag1>text2</tag1> </tag>
The following output is generated:
.xml.tag.tag1 = text1text2
Whitespaces are kept as they are in the XML input. No collapsing happens on significant whitespaces. For example, from this input XML:
<133>Feb 25 14:09:07 webserver syslogd: <b>|Test\n\n Test2|</b>\n
The following output is generated:
[2017-09-04T13:20:27.417266] Setting value; msg='0x7f2fd8002df0', name='.xml.b', value='|Test\x0a\x0a Test2|'
However, note that users can choose to strip whitespaces using the strip-whitespaces() option.
Define a source that correctly detects the end of the message, otherwise the XML parser will consider the input invalid, resulting in a parser error.
To ensure that the end of the XML document is accurately detected, use any of the following options:
Ensure that the XML is a single-line message.
In the case of multiline XML documents:
If the opening and closing tags are fixed and known, you can use multi-line-mode(prefix-suffix). Using regular expressions, specify a prefix and suffix matching the opening and closing tags. For details on using multi-line-mode(prefix-suffix), see the multi-line-prefix() and multi-line-suffix() options.
In the case of TCP, you can encapsulate and send the document in syslog-protocol format, and use a syslog() source. Make sure that the message conforms to the octet counting method described in RFC6587.
For example:
59 <133>Feb 25 14:09:07 webserver syslogd: <book>\nText\n</book>
Considering the new lines as one character, 59 is appended to the original message.
You can use a datagram-based source. In the case of datagram-based sources, the protocol signals the end of the message automatically. Ensure that the complete XML document is written in one message.
Unless the opening and closing tags are fixed and known, stream-based sources are currently not supported.
In case you experience issues, start syslog-ng with debug logs enabled. There will be a debug log about the incoming log entry, which shows the complete message to be parsed. The entry should contain the entire XML document.
The XML parser comes with certain limitations.
It is not possible to address each element of a vector-like structure individually. For example, take this input:
<vector>
<entry>value1</entry>
<entry>value2</entry>
...
<entry>valueN</entry>
</vector>
After parsing, the entries cannot be addressed individually. Instead, the text of the entries will be concatenated:
vector.entry = "value1value2...valueN"
Note that xmllint has the same behavior:
$ xmllint --xpath "/vector/entry/text()" test.xml value1value2valueN%
The XML parser does not support CDATA. CDATA inside the XML input is ignored. This is true for the processing instructions as well.
The XML parser is based on the glib XML subset parser, called "GMarkup" parser, which is not a full-scale XML parser. It is intended to parse a simple markup format that is a subset of XML. Some limitations are inherited:
Do not use the XML parser if you expect to interoperate with applications generating full-scale XML. Instead, use it for application data files, configuration files, log files, and so on, where you know your application will be the only one writing the file.
The XML parser is not guaranteed to display an error message in the case of invalid XML. It may accept invalid XML. However, it does not accept XML input that is not well-formed (a condition that is weaker than requiring XML to be valid).
If the key is longer than 255 characters, syslog-ng drops the entry and an error log is emitted. There is no chunking or any other way of recovering data, not even partial data. The entry will be replaced by an empty string.
The XML parser has the following options.
| Synopsis: | drop-invalid() |
| Format: | yes|no |
| Default: | no |
| Mandatory: | no |
Description: If set, messages with an invalid XML will be dropped entirely.
| Synopsis: | exclude-tags() |
| Format: | list of globs |
| Default: |
None If not set, no filtering is done. |
| Mandatory: | no |
Description: The XML parser matches tags against the listed globs. If there is a match, the given subtree of the XML will be omitted.
parser xml_parser {
xml(
template("$MSG")
exclude-tags("tag1", "tag2", "inner*")
);
};
From this XML input:
<tag1>Text1</tag1><tag2>Text2</tag2><tag3>Text3<innertag>TextInner</innertag></tag3>
The following output is generated:
{"_xml":{"tag3":"Text3"}}| Synopsis: | prefix() |
Description: Insert a prefix before the name part of the parsed name-value pairs to help further processing. For example:
To insert the my-parsed-data. prefix, use the prefix(my-parsed-data.) option.
To refer to a particular data that has a prefix, use the prefix in the name of the macro, for example, ${my-parsed-data.name}.
If you forward the parsed messages using the IETF-syslog protocol, you can insert all the parsed data into the SDATA part of the message using the prefix(.SDATA.my-parsed-data.) option.
Names starting with a dot (for example, .example) are reserved for use by syslog-ng OSE. If you use such a macro name as the name of a parsed value, it will attempt to replace the original value of the macro (note that only soft macros can be overwritten, see Hard vs. soft macros for details). To avoid such problems, use a prefix when naming the parsed values, for example, prefix(my-parsed-data.)
The prefix() option is optional and its default value is ".xml".
| Synopsis: | strip-whitespaces() |
| Format: | yes|no |
| Default: | no |
| Mandatory: | no |
Description: Strip the whitespaces from the XML text nodes before adding them to the message.
parser xml_parser {
xml(
template("$MSG")
strip-whitespaces(yes)
);
};
From this XML input:
<tag1> Tag </tag1>
The following output is generated:
{"_xml":{"tag1":"Tag"}}| Synopsis: | template("${<macroname>}") |
Description: The macro that contains the part of the message that the parser will process. It can also be a macro created by a previous parser of the log path. By default, the parser processes the entire message (${MESSAGE}).
The date parser can extract dates from non-syslog messages. It operates by default on the ${MESSAGE} part of the log message, but can operate on any template or field provided. The parsed date will be available as the sender date (that is, the ${S_DATE}, ${S_ISODATE}, ${S_MONTH}, and so on, and related macros). (To store the parsed date as the received date, use the time-stamp(recvd) option.)
Note that parsing will fail if the format string does not match the entire template or field. Since by default syslog-ng OSE uses the ${MESSAGE} part of the log message, parsing will fail, unless the log message contains only a date, but that is unlikely, so practically you will have to segment the message (for example, using a csv-parser()) before using the date-parser(). You can also use date-parser() to parse dates received in a JSON or key-value-formatted log message.
parser parser_name {
date-parser(
format("<format-string-for-the-date>")
template("<field-to-parse>'")
);
};In the following example, syslog-ng OSE parses dates like 01/Jan/2016:13:05:05 PST from a field called MY_DATE using the following format string: format("%d/%b/%Y:%H:%M:%S %Z") (how you create this field from the incoming message is not shown in the example). In the destination template every message will begin with the timestamp in ISODATE format. Since the syslog parser is disabled, syslog-ng OSE will include the entire original message (including the original timestamp) in the ${MESSAGE} macro.
source s_file {
file("/tmp/input" flags(no-parse));
};
destination d_file {
file(
"/tmp/output"
template("${S_ISODATE} ${MESSAGE}\n")
);
};
log {
source(s_file);
date-parser(format("%d/%b/%Y:%H:%M:%S %Z") template("${MY_DATE}") );
destination(d_file);
};
In the template option, you can use template functions to specify which part of the message to parse with the format string. The following example selects the first 24 characters of the ${MESSAGE} macro.
date-parser(format("%d/%b/%Y:%H:%M:%S %Z") template("$(substr ${MESSAGE} 0 24)") );The date-parser() parser has the following options.
| Synopsis: | format(string) |
| Default: |
Description: Specifies the format how syslog-ng OSE should parse the date. You can use the following format elements:
%% PERCENT %a day of the week, abbreviated %A day of the week %b month abbr %B month %c MM/DD/YY HH:MM:SS %C ctime format: Sat Nov 19 21:05:57 1994 %d numeric day of the month, with leading zeros (eg 01..31) %e like %d, but a leading zero is replaced by a space (eg 1..31) %D MM/DD/YY %G GPS week number (weeks since January 6, 1980) %h month, abbreviated %H hour, 24 hour clock, leading 0's) %I hour, 12 hour clock, leading 0's) %j day of the year %k hour %l hour, 12 hour clock %L month number, starting with 1 %m month number, starting with 01 %M minute, leading 0's %n NEWLINE %o ornate day of month -- "1st", "2nd", "25th", etc. %p AM or PM %P am or pm (Yes %p and %P are backwards :) %q Quarter number, starting with 1 %r time format: 09:05:57 PM %R time format: 21:05 %s seconds since the Epoch, UCT %S seconds, leading 0's %t TAB %T time format: 21:05:57 %U week number, Sunday as first day of week %w day of the week, numerically, Sunday == 0 %W week number, Monday as first day of week %x date format: 11/19/94 %X time format: 21:05:57 %y year (2 digits) %Y year (4 digits) %Z timezone in ascii. eg: PST %z timezone in format -/+0000
For example, for the date 01/Jan/2016:13:05:05 PST use the following format string: format("%d/%b/%Y:%H:%M:%S %Z")
| Synopsis: | template("${<macroname>}") |
Description: The macro that contains the part of the message that the parser will process. It can also be a macro created by a previous parser of the log path. By default, the parser processes the entire message (${MESSAGE}).
| Synopsis: | stamp | recvd |
| Default: | stamp |
Description: Determines if the parsed date values are treated as sent or received date. If you use time-stamp(stamp), syslog-ng OSE adds the parsed date to the S_ macros (corresponding to the sent date). If you use time-stamp(recvd), syslog-ng OSE adds the parsed date to the R_ macros (corresponding to the received date).
| Synopsis: | time-zone(string) |
| Default: |
Description: If this option is set, syslog-ng OSE assumes that the parsed timestamp refers to the specified timezone. The timezone set in the time-zone() option overrides any timezone information parsed from the timestamp.
The timezone can be specified by using the name, for example, time-zone("Europe/Budapest")), or as the timezone offset in +/-HH:MM format, for example, +01:00). On Linux and UNIX platforms, the valid timezone names are listed under the /usr/share/zoneinfo directory.
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Términos de uso Privacidad Cookie Preference Center