What Is Syslog? Facility, Severity, and Port 514

Syslog is the protocol that lets a device write down what happens to it as plain text lines and send them to a central server. Switches, firewalls, servers, printers, and UPS units have done it almost the same way for forty years: something happens, the device writes a line, the line goes out on the network. The only thing you have to provide is someone listening.

In a courtroom, the court clerk does exactly this. The judge speaks, the parties speak, a witness speaks; the clerk writes down what was said, as it was said, with the time. The clerk doesn’t decide anything and doesn’t even need to understand it. The job is to make sure a record exists. When an appeal arrives months later, nobody consults memories. They consult the transcript.

The devices on your network are talking all the time. The problem in most organizations isn’t that they’re silent; it’s that there’s no clerk. This article covers what a syslog line looks like, how the number in its first brackets decodes, why the protocol chose UDP 514, and what it doesn’t carry. Then it looks at real records from a lab switch and gets to the hard question: once the logs start flowing, which of them matter?

It’s the first article in the monitoring and alerts guide. If you already have a log line and want to decode it, jump to the anatomy of a syslog line.

What Is Syslog, and What Problem Does It Solve?

Syslog separates the device that produces events from the server that keeps them. The device only says “this happened” and releases the line; where it’s written, how long it’s kept, and who reads it are no longer the device’s concern. All of the protocol’s strength comes from that split, and so do all its gaps.

The clerk analogy fits exactly: a judge doesn’t keep the transcript. Doing both jobs would mean doing both badly.

An Event With No Record Didn’t Happen

The most expensive fault is the one that leaves no trace. A port drops for a minute at 3 a.m. and comes back. In the morning nobody notices; users say “the internet went out for a bit, I think,” you check and everything’s normal, and three weeks later it happens again.

That isn’t an undiagnosable fault. It’s an unrecorded one. The difference is whether you have a transcript.

Why the Log on the Device Isn’t Enough

Every switch and firewall keeps a log internally. The problem isn’t that it exists; it’s that it slips away in three ways:

1. It isn’t persistent. The buffer in memory can be too small, or cleared when power goes.
2. It’s bounded. When it fills, the oldest lines are overwritten. The chattier the device, the shorter its history.
3. It’s out of reach during the fault. The moment you need it most is the moment the device isn’t answering. If the log is on it, so is your evidence.

I measured the first point on my lab switch, and the proof sits somewhere interesting. After the switch restarted from a power cut, the oldest line in its buffer was this:

<185> Aug 19 06:57:16 0.0.0.0-1 SIM[Cnfgr_Thread ]: sim_util.c(3804) 8 %% Switch was reset due to power disruption.

Nothing before it. The whole history before the outage went with the outage. The device is telling you it lost its memory, from inside the memory it lost.

When You Don’t Need Syslog

In a three-person office with one router and one switch, central logging is an extra layer for nothing. If you can count the devices on one hand and checking each one takes a few minutes, you already have the solution.

The threshold isn’t device count; it’s how long it takes to answer a question. If you can’t answer “what happened last night, and when?” without logging into devices one by one, you need central logging.

One common situation deserves separating out. Many organizations have no central log but do have one structured record: RADIUS accounting. It arrives on its own with wireless or 802.1X, nobody sets it up separately, and it accumulates for years. It’s a real record, but it answers a different question:

• RADIUS accounting records sessions: who connected, when, when they left, how much traffic passed. Fixed fields, known structure.
• Syslog records events: which port dropped, which process failed, which configuration changed. Free-form sentences.

One answers “who got in,” the other “what broke.” If you only have the first, you have no record that answers the second.

There’s a third channel not to confuse with either: SNMP. SNMP pulls numbers from a device; syslog receives the sentences the device writes. SNMP tells you the CPU is at 80 percent; syslog tells you which process is causing it. They’re not rivals but two channels for the same event, and a proper setup collects both. The mechanism is covered in What Is SNMP?

Why Windows Doesn’t Send Syslog on Its Own

This is where mixed-network logging projects most often stall. Switches, firewalls, printers, and Linux servers speak syslog natively; Windows doesn’t.

Windows writes events to the Event Log, a separate system: records are not text lines but structured objects with IDs and fields. An event has a number like 4624, its body is split into fields, and the file format isn’t text.

In practice: connecting most devices to a collector is a one-line setting, while Windows servers need an agent to translate. Plan the two groups separately, or you’ll finish the rollout to a picture where “everything’s flowing except the servers.”

What Does a Syslog Message Look Like? Anatomy of a Line

A syslog message is plain text in three parts: the priority field, time and source, and the body. One line, no delimiters, variable length.

A real line from my lab switch:

<189> Aug 19 06:57:33 sercebilisimsw01-1 TRAPMGR[trapTask]: traputil.c(735) 235 %% Link Up: Vl5

Look at three places:

• The leading <189> isn’t decoration; it’s the only structured information the protocol carries.
• The middle ties the record to who and when.
• The text at the end is written freely by the vendor and doesn’t have to follow any standard.

The Priority Field: The Number in the Brackets

The priority field (PRI) packs two separate facts into one number: where the message came from and how urgent it is. The formula is one line:

PRI = (facility × 8) + severity

If that’s confusing on first read, that’s normal: one number, two facts buried inside, and no visible boundary between them. An example makes it click. Take 189 from the line above:

1. 189 ÷ 8 = 23, remainder 5.
2. The quotient 23 is facility 23.
3. The remainder 5 is severity 5.

Facility 23 is local7; severity 5 is notice. This line is a notable-but-normal record from facility local7.

Instead of trusting the arithmetic, I asked the device:

show logging

Logging is enabled
Console Logging: Level warnings. Messages : 85 logged, 315 ignored
Buffer Logging: Level informational. Messages : 210 logged, 190 ignored
File Logging: Level emergencies. Messages : 0 logged, 400 ignored
Logging facility level : local7

The last line says local7. The quotient matches the device’s own setting exactly.

Time, Source, and Body

After the priority field comes the part that ties the record to a moment and a device. Above, Aug 19 06:57:33 is the timestamp and sercebilisimsw01-1 is the name the device gives itself.

Those two fields come from different places, and neither deserves blind trust. The device reads the timestamp from its own clock; if the clock drifts, the record is archived at the wrong time. The name is also written by the device, and the collector accepts it without checking. My switch says sercebilisimsw01-1 because that name was typed into it; the trailing -1 is the unit number in a stack, which appears even on a single unit.

In the body, the standard ends. TRAPMGR[trapTask]: traputil.c(735) 235 %% Link Up: Vl5 is entirely the vendor’s choice and carries four parts:

1. TRAPMGR[trapTask]: the process and thread that produced it.
2. traputil.c(735): which source file and line of the firmware it came from.
3. 235: the device’s own event counter, incremented per message.
4. %% Link Up: Vl5: the actual message for a human.

Only the last part is written for you; the first three are for the vendor’s support team. Another brand reports the same event in a completely different sentence, because no standard defines this field.

This is the most misunderstood part of the protocol. Syslog standardizes how a message travels, not what it says. Connect several brands to one collector and their records sit side by side without speaking the same language.

RFC 3164 and RFC 5424: Two Formats, Both in the Field

My lab switch writes Aug 19 06:57:33, so it uses the old format. The missing year looks trivial but hurts long-term retention: in a record archived for two years, which year’s August 19 is it? The collector fills the gap from the moment it received the line, so accuracy depends on the server’s clock, not the device’s.

What Structured Data Looks Like on the Wire

The Turkish original of this article stops at the table above. Here is what the second column actually looks like, from a capture I took on the lab collector while testing plain-text transport, and it shows something RFC 3164 has no way to say:

<13>1 2026-08-19T00:58:11.200471+00:00 sercesyslog gizli-test - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="46500"] PAROLA=CokGizli123 duz metin gidiyor

Read it left to right:

1. <13> is the priority field again: 13 = 1 × 8 + 5, facility user, severity notice, the default for a message sent by hand with logger.
2. The 1 right after it is the version number. That digit alone tells a collector it’s reading RFC 5424, not the old format.
3. 2026-08-19T00:58:11.200471+00:00 is a full timestamp: year, microseconds, and time zone. The ambiguity from the previous section is gone.
4. The two dashes are empty fields (process ID and message ID); RFC 5424 marks a missing value with - rather than dropping it.
5. [timeQuality tzKnown="1" isSynced="1" syncAccuracy="46500"] is a structured-data element, and it’s the interesting part.

timeQuality is defined in RFC 5424 itself. The sender attaches it to say how much its own timestamp can be trusted: tzKnown="1" means it knows its time zone, isSynced="1" means its clock is synchronized to an external source, and syncAccuracy="46500" is the claimed accuracy in microseconds, here 46.5 milliseconds. In other words, the message carries a statement about the reliability of its own clock. An old-format line can’t do that; you have to take its timestamp on faith.

Two caveats keep this honest. First, it’s a claim by the sender, unauthenticated like everything else in syslog: a device with a broken clock that believes it’s synced will say so. Second, it only helps if your collector keeps structured data instead of flattening it; many default configurations write the line to a file and discard the brackets’ meaning. If you’re building a pipeline where timestamps matter, it’s cheap to keep this field and alert on isSynced="0", which catches a drifting sender before its records land in the wrong order.

The rest of that line is the reason the capture exists: PAROLA=CokGizli123 duz metin gidiyor is Turkish for “PASSWORD=VerySecret123 going as plain text,” a test string I sent over port 514 to show it can be read by anyone capturing the traffic. A matching test over TLS on port 6514 gave the opposite result: searching that capture for PAROLA returned zero matches, and only TCP headers were visible.

Facility and Severity: Two Facts in One Number

Severity says how urgent a message is; facility says where it came from. They’re independent: a printer can send a critical message, the kernel an informational one.

A court file’s cover carries the same two facts: which court it belongs to and how urgent it is. One decides where it’s filed, the other who looks at it and when. Syslog packs both into one number, and splitting it is the collector’s first job.

The Eight Severity Levels, and Which Ones Matter

Severity takes eight values, and a smaller number means more urgent:

Two lines from the same device make the difference concrete:

<189> Aug 19 06:57:33 sercebilisimsw01-1 TRAPMGR[trapTask]: %% Link Up: Vl5
<185> Aug 19 06:57:16 0.0.0.0-1 SIM[Cnfgr_Thread ]: %% Switch was reset due to power disruption.

1. 189 = 23 × 8 + 5 → local7.notice. An interface came up. Normal operation.
2. 185 = 23 × 8 + 1 → local7.alert. The device restarted after a power cut. The first line to read in the morning.

One character apart. But that character is the difference between “all fine” and “something happened here overnight.”

24 Facilities, and Why local0-local7 Exist

Facility takes 24 values, split in two for historical reasons.

The first 16 have fixed meanings you can’t change. The list dates from 1980s Unix: kern for the kernel, mail, auth for authentication, lpr for the print queue. A switch or firewall has no entry, because when the list was written there was no such category as “network device.”

The remaining 8 are deliberately undefined. They’re named local0 to local7, and you give them meaning. The standard never says “local4 means this”; it means whatever you decide.

In practice, you assign one value per device class and have the collector write each to its own place:

The payoff: you know which device class sent a record from the leading number alone, without reading the line.

There’s a trap. My lab switch uses local7 by default, and most vendors pick the same default. Assign nothing, and all your devices land on the same value; the separation facility offers never happens.

How the Threshold Works: “This Level and Above”

Devices keep a separate threshold per destination and never send messages below it. The show logging output above shows the mechanism in numbers:

The third row is the most common field mistake, measured: set the threshold too tight and logging “works” while staying empty. Nobody plans to produce emerg messages; that level is for the moment the system is gone.

Why Syslog Uses Port 514 and UDP

Syslog uses UDP 514 by default, and the choice follows from its purpose: a device should not slow down to report on itself.

UDP sets up no connection, no handshake, no delivery wait. The device drops the line on the network and goes back to work. For a switch that matters: logging never gets in the way of its real job, forwarding packets.

Why the Loss Is Silent

The price: UDP guarantees no delivery and tells nobody when it fails. If a line is lost in transit, the sender doesn’t know and the receiver doesn’t notice a gap. Both sides are content; the record is gone.

In the courtroom, that’s a missing page from the transcript. The problem isn’t the missing page; it’s that nobody wrote down how many pages there were.

On a lightly loaded internal link, UDP loss is negligible. It matters in two cases: a busy, narrow link between device and collector, or a collector that can’t keep up with a sudden burst. Both happen exactly when you need the records most.

That’s one reason management traffic belongs on its own VLAN. If logs share a link with user traffic, they’re among the first to drop when it fills; a separate management network, covered in What Is a VLAN?, takes them out of the crowd. The real argument for prioritizing them isn’t speed. If someone is guessing passwords against your firewall and the lines reporting it get lost in that same congestion, you’ve lost the event itself, not a few seconds of comfort.

One @ or Two: A One-Character Difference on the Sender

On a Linux sender, the transport is chosen with a single character, which surprises almost everyone the first time:

*.* @192.168.1.46:514
*.* @@192.168.1.46:514

1. One @ means UDP.
2. Two @@ means TCP.

One character, and the difference is whether loss is silent. Check it first when you inherit a configuration.

When You Need TCP or TLS

• TCP, if you need to notice loss. Delivery is acknowledged and a dropped connection is visible, at the cost of a bit more work on the device.
• TLS, if records must not be readable in transit. Syslog is plain text; anyone capturing packets on the same network can read usernames, device names, and configuration changes, as the capture above showed. Encrypted syslog uses port 6514.
• Both, if the logs may become evidence. A record expected to hold up has to be both complete and unaltered.

Don’t confuse what TLS does here: it encrypts the transport; it doesn’t sign the record. It makes the line unreadable in transit and proves the collector’s identity with a certificate, so the sender knows it’s talking to its own collector. Once the line is written to disk, TLS is done; whether that file is changed later is a separate question. And 6514 has to be its own port, because an encrypted session begins with a handshake from its first byte; a collector listening on 514 would take those bytes for a syslog line.

What Syslog Doesn’t Carry: Identity, Integrity, Order

This is where a record’s value as evidence is decided. Syslog was designed forty years ago on the assumption that everyone on a network trusted everyone else. That assumption is gone, and the protocol makes no attempt to compensate.

A Source Address Is Not an Identity

The collector assigns an incoming record to a device by the packet’s source address. That isn’t authentication. Over UDP, a source address can be forged; any machine on the network can produce records that appear to come from your switch.

Both outcomes are bad: fabricated records enter the archive, or real ones lose their value among fakes. The practical measure lives around the protocol, not in it: open the collector’s 514 not to the whole network but only to known senders. That doesn’t replace authentication, but it raises the bar noticeably.

Who Guarantees a Record Wasn’t Changed?

Short answer: not syslog. The line carries no signature and no checksum. Once it reaches the collector it’s an ordinary text file, and anyone who can write to that file can change it.

That’s not a flaw so much as the edge of its scope. Integrity is a separate layer built on top: chaining records with hashes, narrowing write access, keeping the archive on separate storage.

Depending on what your logs contain and which rules you fall under, that layer isn’t optional:

• Logs almost always contain IP addresses and usernames, which the EU’s GDPR treats as personal data. That brings the storage limitation principle of Article 5(1)(e) (keep it no longer than needed) and the security requirements of Article 32 to your log archive.
• If you handle payment cards, PCI DSS v4.0 requirement 10.5.1 asks for at least 12 months of audit log history, with the most recent three months immediately available for analysis.

None of that is syslog’s job. It’s the collector’s, and the policy around it.

If the Clock Drifts, How Useful Is the Transcript?

Time is the most critical field in a transcript. If two devices’ clocks are ten minutes apart, their records side by side show events in the wrong order. What happened first looks like it happened second.

That’s hard to diagnose, because every individual record is correct; only the stamp is wrong. So the first step in central logging isn’t the collector; it’s the time source. Without every device on one reference, logs are individually right and collectively wrong. The timeQuality element shown earlier is how an RFC 5424 sender reports whether it has that reference.

Syslog in the Field: How to Filter the Noise

You’ve set up a collector, connected devices, and logs are flowing. The real work starts now, because collecting isn’t reading.

Lab: How Much Does One Switch Say in a Minute?

The usual field answer is “a switch doesn’t say much; a port drops now and then.” I measured it.

I connected the lab switch to a freshly built collector and did nothing else: no config changes, no cables, no logins. After sixty seconds:

60 satır / 8.670 bayt

(Turkish for 60 lines / 8,670 bytes; the measurement summary was recorded in Turkish.) At that rate one switch produces about 11 MB a day, about 4.3 GB a year, while nothing is happening. Apply the PCI DSS window from the previous section and a single idle switch fills roughly 4 GB of mandatory retention on its own; multiply by your switch count before you size the collector’s disk.

The number isn’t the surprise. The content is. The 149 lines collected broke down like this:

The one meaningful record was seven thousandths of the volume. That 147-byte line:

<190> Aug 19 07:01:59 sercebilisimsw01-1 CLI_WEB[emWeb]: %% [CLI:ilker:192.168.1.115] User has succesfully logged in

Who logged into the switch as an administrator, when, and from where. In an incident or a security question, that’s the first line you’d look for, and it was buried under 148 others.

A Line Repeated Hundreds of Times Is a Fault Signal

The 148 lines of noise weren’t random. They were two messages alternating:

<187> DOT1S[dtlTask]: dot1s_txrx.c(306) %% dot1sBpduReceive(): Discarding the BPDU, since it is an invalid BPDU type
<189> DOT1S[dtlTask]: dot1s_txrx.c(1286) %% dot1sBpduReceive(): Invalid Forward Delay

Every two seconds, without pause. The switch was receiving messages from the protocol that prevents network loops (spanning tree) and discarding them because it couldn’t make sense of them.

The rule: a message repeating every second isn’t information, it’s a symptom. Repetition doesn’t make a record unimportant; it shows something unresolved is going on in the background. But the same rule says that message shouldn’t enter the archive as is: nearly all of those 4.3 GB a year are copies of two sentences.

What to Keep, What to Drop

Keeping every line forever is both pointless and expensive. Filtering happens at three stages:

1. Threshold on the sender. Set which level and above each device sends. Leaving debug on permanently is the biggest source of noise. Firewalls matter most here: a firewall can log every connection, so decide up front which rule sets are logged.
2. Separation on the collector. Write records to separate files by sending device and producing process. With DOT1S and CLI_WEB in one file, the second disappears; in separate files, the 147-byte file stands out.
3. Repeat suppression and retention. Collapse consecutive repeats of one message into a single line; compress and archive old records on a schedule your retention rules set.

Skip all three and the result is predictable: the disk fills, logging stops, and you find out on the day you need it.

Conclusion: Without a Clerk, the Hearing Never Happened

Syslog isn’t complicated. A device writes a line, packs two facts into the priority field, and sends it to port 514. The thing to learn isn’t the protocol but what it doesn’t guarantee: not delivery, not the sender’s identity, not that a record wasn’t altered, not the accuracy of the clock.

Each of those is a layer you build. The protocol only makes sure a transcript is kept; making it trustworthy is separate work. RFC 5424 helps at the edges, down to letting a sender state how reliable its clock is, but the collector still has to keep and check that statement.

And the measurement showed this: a switch with nothing happening still says sixty lines a minute. Ninety-nine percent may tell you nothing. The remaining seven thousandths are the only record of who logged in at 3 a.m.

If you’re not collecting that record, the event never happened.