Syslog routing

A Syslog routing rule converts a raw message into a record for one allowed data model. The console presents the rule in the same order the idea should be understood:

match → extract and choose destination → map fields

1. Match#

The match stage decides whether the rule applies. Use a stable signal such as app name, hostname, facility, or a known message pattern.

Make rules specific enough that unrelated messages do not match accidentally. Put more specific rules before broad fallback behavior when order is relevant to the configured rule set.

2. Extract and select the model#

The extractor parses the useful body from the matched message. Depending on the source, this may use a known parser, structured content, or a configured pattern.

The destination model must be one of the ingest client's allowed models. This prevents routing configuration from expanding the client's authorization scope.

3. Map fields#

Map extracted or system values to model fields. The target field type remains authoritative; extracted values must normalize successfully.

Useful system context can include the transport, source address, observed hostname, or app name when the model and mapping allow it.

Test with discovery#

Discovery is the safest way to inspect real messages and generate a candidate rule. Review the inferred parser, match, extractor, and fields before approval.

Common mistakes#

• matching an unstable free-text message instead of a stable field;
• mapping a text value to an integer field;
• selecting a model outside the allowed set;
• confusing observed Syslog hostname with the endpoint DNS name;
• making one fallback rule so broad that it captures unrelated sources.