Log monitoring: Nginx access logs and Windows event logs

Commands run on web01 unless stated, and items are created in the frontend at https://zbx01.lab on host web01. The agent must have active checks working (ServerActive pointing at zbx01, Lesson 4).

1Look at the Nginx log and its permissions

Run this on web01:

ls -l /var/log/nginx/
id zabbix
sudo -u zabbix head -1 /var/log/nginx/access.log

You should see this (your sizes, dates and user IDs will differ):

total 8
-rw-r----- 1 www-data adm 1595 Nov  8 10:12 access.log
-rw-r----- 1 www-data adm 1086 Nov  8 09:59 error.log
uid=113(zabbix) gid=113(zabbix) groups=113(zabbix)
head: cannot open '/var/log/nginx/access.log' for reading: Permission denied

Nginx logs belong to www-data with group adm and mode 640, and the zabbix user isn’t in adm. Any log item on this file would fail right now, and you’ll see the exact Zabbix error in the Break It section.

✅ Checkpoint: You can see the log is www-data:adm 640 and the zabbix user cannot read it yet.

2Give the zabbix user read access the right way

Run this on web01:

sudo usermod -aG adm zabbix
sudo systemctl restart zabbix-agent2
sudo -u zabbix head -1 /var/log/nginx/access.log

You should see one line in the combined log format (your client IP, time and URL will differ):

192.168.56.80 - - [08/Nov/2026:10:01:14 +0530] "GET / HTTP/1.1" 200 615 "-" "curl/8.18.0"

adm is Ubuntu’s standard group for reading logs, and logrotate keeps creating new files with group adm (create 0640 www-data adm in /etc/logrotate.d/nginx), so this survives rotation. The restart matters: a running process keeps the groups it started with.

✅ Checkpoint: sudo -u zabbix can read the first line of the access log.

3Create a log[] item for server errors

On web01 in the frontend, Items > Create item:

The pattern has spaces on both sides so it matches the status field (" 502 166) and not, say, a byte count containing 500. skip means the item starts at the end of the file, so you don’t import yesterday’s errors.

✅ Checkpoint: The item exists and, after a minute, shows no error icon.

4Generate errors and read them

Create a location that always fails and hit it, plus a few missing pages:

Run this on web01:

echo 'location = /broken { return 502; }' | sudo tee /etc/nginx/snippets/broken.conf >/dev/null
sudo sed -i 's|^\tserver_name _;|&\n\tinclude /etc/nginx/snippets/broken.conf;|' /etc/nginx/sites-available/default
sudo nginx -t && sudo systemctl reload nginx
for i in 1 2 3; do curl -s -o /dev/null http://127.0.0.1/broken; done
for i in 1 2 3 4 5; do curl -s -o /dev/null http://127.0.0.1/missing-$i.png; done
tail -3 /var/log/nginx/access.log

You should see:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
127.0.0.1 - - [08/Nov/2026:10:21:12 +0530] "GET /missing-3.png HTTP/1.1" 404 162 "-" "curl/8.18.0"
127.0.0.1 - - [08/Nov/2026:10:21:12 +0530] "GET /missing-4.png HTTP/1.1" 404 162 "-" "curl/8.18.0"
127.0.0.1 - - [08/Nov/2026:10:21:12 +0530] "GET /missing-5.png HTTP/1.1" 404 162 "-" "curl/8.18.0"

The sed line adds an include right after server_name _; in Ubuntu’s default site, so the /broken location lives inside that server block. Within a minute, open Monitoring > Latest data, find “Nginx: 5xx lines” and click History.

History lists the three lines, newest first. Local time stays empty because the item has no log time format:

Three 502 lines and none of the 404s, because only lines matching the pattern leave web01. When I ran the same item against a test log, the agent sent only the 502 and 504 lines and skipped the 404 and 200 lines in between.

✅ Checkpoint: History of Nginx: 5xx lines shows the three /broken lines with status 502.

5Count 404s with logrt.count

Create a second item, numeric this time:

The first parameter is now a regular expression for the file name, not a path pattern: it matches access.log and access.log.1 (the rotated copy before compression), and the dot is escaped. Run the 404 loop from step 4 again and look at Latest data.

In Latest data, the Last value column shows:

Each check sends the number of matching lines since the previous check; a minute with no 404s sends 0. That’s a number you can graph and put a threshold on.

✅ Checkpoint: Nginx: 404 per minute shows 5 after the loop and 0 a minute later.

6Turn log values into problems

Add two triggers on web01:

Using count(...,5m) instead of last() matters for log items: a log item has no value when nothing matches, so a trigger on last() would stay in problem forever after one bad line. With a time window, the problem clears once the window has no lines.

✅ Checkpoint: Running the /broken loop opens “Nginx 5xx on web01” with the log line in its name, and it closes about 5 minutes later.

7Optional: failed Windows logons on win01

If you built win01 in Lesson 5, create this on host win01 (the agent there must run as Local System, which can read the Security log). If you skipped win01, read along and look at the output below.

Then on win01 try a wrong password a few times (for example runas /user:win01\nosuch cmd in a command prompt and type anything).

In Monitoring > Latest data, click History for “Windows: failed logons”. Each failed logon is one row: Source Microsoft-Windows-Security-Auditing, Severity Failure Audit, Event ID 4625, and the whole event text as the value.

For the runas attempt the value starts like this (your Logon ID and Caller Process ID will differ):

An account failed to log on.

Subject:
	Security ID:		WIN01\Administrator
	Account Name:		Administrator
	Account Domain:		WIN01
	Logon ID:		0x4F1A2

Logon Type:			2

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		nosuch
	Account Domain:		win01

Failure Information:
	Failure Reason:		Unknown user name or bad password.
	Status:			0xC000006D
	Sub Status:		0xC0000064

Process Information:
	Caller Process ID:	0x8f4
	Caller Process Name:	C:\Windows\System32\svchost.exe

Network Information:
	Workstation Name:	WIN01
	Source Network Address:	::1
	Source Port:		0

Detailed Authentication Information:
	Logon Process:		seclogo
	Authentication Package:	Negotiate
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

Windows adds a few paragraphs after that last line explaining each field, and Zabbix keeps them in the value too. Logon Type 2 is an interactive logon. Status 0xC000006D means a bad user name or password, and Sub Status 0xC0000064 says the account name itself is wrong. Password guessing over the network shows Logon Type 3 instead, with the attacker’s IP address in Source Network Address.

A trigger like count(/win01/eventlog[Security,,,,^4625$,,skip],5m)>=5 catches password guessing. The Security log needs the “Audit logon events” policy on failure, which is on by default for Windows Server.

✅ Checkpoint: On win01, failed logons appear as event 4625 lines (or you have read through the output if you skipped win01).