Syslog Severity Mix Analyzer

Syslog severity review turns a stream of device, server, and application messages into a quick picture of operational pressure. Severity codes tell operators whether a line describes a routine state, a warning, an error, or a condition that needs immediate attention. A good first read combines line volume with seriousness and the emitter responsible for most of it.

A severity mix is especially useful during collector triage, firewall troubleshooting, network change review, and post-incident cleanup. A short sample can show whether a noisy hour is mostly informational chatter, one router repeating warnings, or several hosts producing error-level messages. That helps decide whether to widen the search, inspect one emitter, tune log collection, or escalate a service owner.

Severity codes still need judgment. A high error share does not prove an outage, and a low error share does not prove the slice is healthy. Collector filters, sampling windows, vendor wording, and missing priority headers can all shape the mix. The safest reading keeps the original log lines, the source label, and the selected classification mode with the summary.

The most useful result is a small review list: total lines, the share of emergency through error messages, the dominant severity, and the emitters whose own error share is above the warning threshold. That is enough to guide a first investigation without pretending to replace a full log search or monitoring platform.

Technical Details:

Syslog priority values combine facility and severity in one number at the start of a message. The severity part is the lower three bits of the priority value, so the severity code is found with modulo 8. Codes 0 through 3 represent emergency, alert, critical, and error conditions. Codes 4 through 7 represent warning, notice, informational, and debug conditions.

Many real samples are not clean RFC messages. Appliance logs, journal excerpts, and application lines often mix formal priority headers with plain words such as ERROR, WARN, failed, or debug. A useful first pass therefore needs a clear priority rule and a separate word rule, with the chosen mode kept visible when results are compared.

Rule Core

Classification follows one of three paths. Auto PRI then words uses a leading <PRI> value when it exists, then falls back to word matching. PRI numbers only ignores message words and treats lines without a usable priority as informational. Message words only ignores the priority number and classifies from terms in the message text.

The error share is the count of emerg, alert, crit, and err lines divided by the total classified line count. The warning threshold is a percent from 0 to 100. A summary or emitter is flagged only when its error share is greater than the threshold, so a 20.0% error share is still in range when the threshold is exactly 20%.

Emitter extraction is heuristic because syslog samples do not all carry the same fields. RFC 5424-style lines prefer the hostname and app name after the timestamp. BSD-style lines prefer the hostname and tag after the timestamp. Key-value text can use host=, hostname=, device=, app=, or service=. When none of those patterns fits, the second token is used, and otherwise the emitter is marked as unknown.

Everyday Use & Decision Guide:

Start with a focused sample from one collector, site, device group, or incident window. Put that name in Source label so copied rows and JSON summaries remain tied to the log slice. Leave Classification mode on Auto PRI then words unless you already know the sample should trust only priority headers or only message wording.

Paste syslog or application lines into Syslog lines, choose Browse logs, drop a LOG or TXT file onto the textarea, or load the sample. Selected files are read by the browser for analysis. The page also mirrors changed inputs into the current URL for sharing, so use sanitized excerpts when logs contain secrets, customer data, tokens, or internal addresses that should not appear in browser history or copied links.

• Use Syslog Severity Ledger to see every severity code, count, and share in the sample.
• Use Emitter Noise Queue when the first question is which host, service, or device tag is producing the serious lines.
• Raise Error share warning for noisy maintenance windows where a higher error share is expected. Lower it for short samples where a small number of errors should stand out.
• Switch to PRI numbers only when devices produce reliable <PRI> prefixes and message wording is inconsistent.
• Switch to Message words only when pasted application lines lack priority headers or when a vendor uses priority values that are not meaningful for the excerpt.

Do not treat a high error+ percentage as a root cause by itself. Pair it with the dominant severity, the top emitter, and a few original lines from that emitter before changing collector filters or opening an incident handoff.

Step-by-Step Guide:

Use one compact pass to classify the slice, then check whether the top emitter and severity mix match the event you are investigating.

1. Enter a short name in Source label, such as edge collector sample or dc1 firewall 10:00-10:15.
2. Choose Classification mode. Use Auto PRI then words for mixed syslog and application text, PRI numbers only for formal syslog headers, or Message words only for plain messages.
3. Set Error share warning to the percent that should trigger review. The default value of 20 means a sample above 20.0% error+ is flagged.
4. Paste lines into Syslog lines, use Browse logs, drop a LOG or TXT file, or press Load sample. If the result says Paste syslog or application log lines before classifying severity mix., add non-empty lines before reading the tables.
5. Read the summary. It reports the error+ percentage, total classified lines, emergency-alert-critical-error count, number of PRI-parsed lines, dominant severity, and active mode.
6. Open Syslog Severity Ledger to confirm whether the mix is dominated by errors, warnings, notices, or informational lines.
7. Open Emitter Noise Queue to check emitters with high error share and follow the suggested review action for rows above the threshold.
8. Use Syslog Severity Bar Chart for a quick distribution view, then open JSON if another workflow needs the source label, mode, threshold, metrics, severity rows, emitters, and parsed line details.

A useful handoff includes the source label, classification mode, threshold, error+ percentage, dominant severity, and the top emitter row.

Interpreting Results:

The error+ percentage is the main pressure signal. It counts severity codes 0 through 3, so it groups emergency, alert, critical, and error lines together. A high value should send you to the top rows in Emitter Noise Queue, not straight to a conclusion about outage size.

• PRI parsed tells you how many lines used a leading priority value. If that number is low in auto mode, most classifications came from message words.
• dominant names the severity with the highest count. It can be info even when a smaller group of error lines still deserves review.
• mix in range means the overall error share is less than or equal to the threshold. It does not prove the selected log window is complete.
• error mix high means the overall error share is greater than the threshold. Confirm whether the sample was prefiltered around failures before escalating.
• An emitter row with Inspect this emitter before widening collector filters. crossed the same greater-than threshold within that emitter's own lines.

When results look surprising, compare the mode against a few original lines. A line such as <5>... failed login becomes notice in PRI mode but err in word mode, so mode choice can change the mix even when the pasted text is unchanged.

Worked Examples:

Firewall sample with formal priority headers

A seven-line edge sample contains <3>, <2>, <4>, and several lower-severity messages. With Auto PRI then words, the leading priority values classify those formal lines first. If three of seven lines are severity 0 through 3, the summary reports 42.9% error+. With Error share warning at 20, the result shows error mix high and the firewall emitter should be reviewed before widening collector filters.

Application lines without PRI values

A small application excerpt contains ERROR app01 health check failed, INFO app01 recovered after restart, and WARN app01 retry queue depth changed. In auto mode, no priority header exists, so severity comes from words. The ledger shows one err, one warning, and one info, while Emitter Noise Queue groups the rows under app01.

Boundary case at the warning threshold

In a 10-line sample with exactly two emergency-alert-critical-error lines, error+ is 20.0%. If Error share warning is also 20, the badge remains mix in range because the flag uses greater-than comparison. Lowering the threshold to 19 makes the same sample show error mix high.

A confusing mixed-mode line

A vendor line begins with <5> but says failed in the message body. Auto mode trusts the priority and classifies it as notice. If the device's priority values are known to be unreliable for this export, rerun with Message words only and compare whether the severity ledger now matches the incident notes.

FAQ:

Glossary:

PRI

The priority number at the start of many syslog messages, written in angle brackets and used to derive facility and severity.

Severity code

The syslog seriousness value from 0 to 7, where 0 is emergency and 7 is debug.

error+

The combined share of emergency, alert, critical, and error lines in the current sample.

Emitter

The host, app, device, service, tag, or fallback token used to group noisy sources.

Dominant severity

The severity with the highest count in the current sample.

Classification mode

The selected rule path that decides whether priority values, message words, or both drive severity assignment.

References:

• RFC 5424: The Syslog Protocol, IETF, March 2009.
• RFC 3164: The BSD Syslog Protocol, IETF, August 2001.