Server log analysis: collection, parsing, monitoring, and troubleshooting

Windows records events in Windows Event Log, stored as .evtx files under %SystemRoot%\System32\winevt\Logs\ and viewable with Event Viewer (eventvwr.msc). The three classic channels are Security (authentication and audit events), System (services, drivers, kernel), and Application (software-level events). Server roles add their own channels under Applications and Services Logs — we covered the Remote Desktop channels in detail in our guide to RDP logging and monitoring.

These Security and System events deserve a permanent place on your watchlist:

Microsoft maintains a longer prioritized list in Appendix L: Events to Monitor. For a broader treatment of Windows security events, see our post on security event logs.

Linux servers split their logging between flat files and the systemd journal:

For deeper audit trails such as file access, syscalls, and identity changes, the Linux Audit framework (auditd) is the source of record. Our Linux Audit integration guide shows how to collect it. We also walk through a complete detection setup in Linux security monitoring with NXLog Platform.

Server log analysis doesn’t stop at the operating system. The services running on your servers keep their own records:

If IIS makes up a large share of your servers, we compared tooling approaches in our post on enterprise IIS log analysis.

Each server runs a collection agent that parses, filters, and forwards events straight to your SIEM or to NXLog Platform.

This is the simplest design and works well for flat networks and small-to-medium fleets. Its main strength is on-source processing: because filtering and normalization happen on the endpoint, your SIEM bill reflects signal rather than raw volume.

Segmented networks, DMZs, branch offices, and appliance-heavy environments usually need an intermediate tier. Edge agents ship to a relay; the relay buffers, enriches, and forwards upstream. Devices that can’t run an agent — switches, firewalls, storage arrays — send syslog to the same relay.

A few notes on the building blocks:

Whichever pattern you choose, keep one rule constant: the security-relevant events leave each server within seconds, encrypted, and land somewhere the server’s own administrator account can’t erase them.

The Event Log for Windows input module reads Windows Event Log natively. Filtering with a QueryXML block is more efficient than collecting everything and dropping events afterwards, because the subscription itself only returns matching events. This example collects the high-value Security events from the table above, plus new-service installations from the System channel:

im_msvistalog parses each event into structured fields ($EventID, $Channel, $TargetUserName, and so on) automatically. The Windows Event Log integration guide covers remote collection, custom channels, and more advanced query patterns.

On Linux, the File input module tails flat log files, and the Syslog extension module parses the syslog format into fields:

For servers where the systemd journal is the primary log store, the Systemd input module reads structured journal entries directly, and the Linux Audit System input module collects from the Linux Audit framework without requiring auditd. The Linux system logs integration guide compares the options.

This input tails an Apache access log in Combined Log Format and extracts every field, converting the timestamp and status code to proper types along the way:

The Apache HTTP Server integration guide extends this to error logs and alternative formats; there are matching guides for nginx and Microsoft IIS.

On-source filtering is the biggest lever you have against SIEM ingestion cost. But filtering security telemetry is a risk decision, not just a cost one: what you drop, you can’t investigate later. A defensible pattern is to keep authentication and audit events at full fidelity while trimming high-volume operational sources. For example, in a web pipeline where only errors feed detections:

Document every drop rule in your logging policy, and revisit it when your detection needs change. Our cost reduction page covers this trade-off in more depth.

This output converts records to JSON and ships them over TLS to NXLog Platform or any syslog/TLS-capable SIEM, then a route ties the pipeline together:

If your destination has a native protocol, swap the output module rather than forcing everything through syslog: NXLog Agent ships purpose-built output modules including Elasticsearch, Microsoft Sentinel, Google Security Operations, and Kafka, with step-by-step integration guides for Splunk, Microsoft Sentinel, and other SIEMs.

Whatever your analytics layer, these server-side signals earn real-time alerts. They map directly to attacker behavior cataloged in MITRE ATT&CK and to Microsoft’s events-to-monitor guidance:

For correlation logic that needs to run before events reach the SIEM — "alert if X happens more than N times within M seconds" — the agent-side Event Correlator processor module handles thresholds, suppression, and paired events. Once data lands in NXLog Platform, you can search it centrally and build dashboards; we showed how in visualizing telemetry data flow and volume with NXLog Platform.

A spike in 4625 events looks like a brute-force attempt until you read the Sub Status field: 0xC000006A means a wrong password, 0xC0000234 a locked account, 0xC0000072 a disabled one. The full code list is on the event 4625 reference page. A single service account with a stale password can generate thousands of failures that read as an attack. Parsing these codes into fields (as im_msvistalog does) lets you separate the misconfigured scheduled task from the actual password spray in one query.

Correlate three views on one timeline: Service Control Manager events (7031/7034) tell you when the service died, the application’s own log tells you what it was doing, and system-level logs tell you about the environment. For example, the Linux kernel logs out-of-memory killer activity to kern.log and the journal right before it terminates the largest process. When all three sources share one timestamped store, the sequence usually explains itself. If the misbehaving component is the collection agent itself, the NXLog Agent troubleshooting section covers its internal logs and common errors.

If events from two servers disagree about the order of things, check clocks before anything else. The ACSC/CISA joint guidance recommends consistent ISO 8601 timestamps with millisecond precision (for example, 2024-07-25T20:54:59.649Z) precisely because mixed formats and time zones wreck cross-system correlation. Standardize on UTC in the pipeline, keep NTP healthy on every server, and confirm your agents buffer during outages. With disk-backed buffering via the Buffer processor module, a network blip delays events instead of deleting them.