M46 - Logging & Event Analysis
Logging & Event Analysis
Use Event Viewer, Get-WinEvent, and journalctl to narrow system problems by time, severity, service, and recent activity.
- Use Event Viewer, Get-WinEvent, and journalctl to narrow system problems by time, severity, service, and recent activity.
Logs Matter Because Memory Is Incomplete
When something breaks, people usually remember symptoms, not sequence.
Logs help you answer more grounded questions:
- when did the issue start?
- which service or component reported trouble?
- was it an error, a warning, or just normal information?
- did the same pattern happen more than once?
The goal is not to read every line. The goal is to narrow the problem.
1. Windows: Event Viewer and Get-WinEvent
Windows stores many important logs in Event Viewer rather than in plain text files.
Where to start in Event Viewer
- System: drivers, boot, hardware, and operating system events
- Application: application-level failures or warnings
- Security: authentication and audit events
A practical first move is to filter by time and severity instead of scrolling through everything.
Get-WinEvent -FilterHashtable @{ LogName = ‘System’; Level = 1,2 } -MaxEvents 20 Get-WinEvent -FilterHashtable @{ LogName = ‘Application’; StartTime = (Get-Date).AddHours(-1) } -MaxEvents 20
Linux uses similar narrowing habits with journalctl.
Get-WinEvent becomes especially useful once you know what time window or log bucket you care about.
2. Linux: Journalctl for Recent and Filtered Logs
On modern Linux systems, journalctl gives you a central way to inspect many logs.
sudo journalctl -n 50 sudo journalctl -r sudo journalctl —since “1 hour ago” sudo journalctl -u ssh —since “1 hour ago” sudo journalctl -p 3
Useful patterns:
-n 50for the most recent lines-rto see newest events first--sincefor a time window-u servicefor one service-p 3for errors and higher priority events
You do not have to memorize every flag. You do need to learn how to narrow the scope quickly.
3. Live Troubleshooting vs Historical Troubleshooting
There are two common log-reading situations:
- Historical: something failed earlier and you need to reconstruct what happened
- Live: you are about to restart or retry something and want to watch what happens now
Get-Content C:\logs\app.log -Wait
sudo journalctl -f tail -f /var/log/syslog
Watching logs live is often the fastest way to link an action with its error message.
Start with Time, Then Narrow Further
If someone says “it broke around 2 PM,” use that first. A time window plus one service or severity filter is usually a much better first step than grepping the entire machine blindly.
4. A Practical Investigation Sequence
When you are unsure where to begin, try this order:
- identify the approximate time of the issue
- choose the likely source: system, application, or a specific service
- filter to errors or warnings if the log is noisy
- review the events immediately before and after the failure
That sequence keeps the investigation grounded in evidence instead of guesswork.
What You Just Learned
- Log analysis is about narrowing, not reading everything.
- On Windows, Event Viewer and
Get-WinEventhelp you filter by log source, time, and severity. - On Linux,
journalctlhelps you filter by time, service, priority, and recency. - Live log following is useful when you can reproduce the problem.
- Time window plus service or severity is often the best starting combination.
Next, you will connect logs to service management so you can inspect, restart, and verify system services more deliberately.