Tweet
Bí quyết Troubleshooting Syslog trên Cisco IOS, Windows và Linux
Syslog là một trong những công cụ quan trọng nhất trong vận hành hệ thống và mạng. Khi mọi thứ hoạt động bình thường, syslog chỉ đơn giản là nơi ghi nhận sự kiện. Nhưng khi sự cố xảy ra, syslog lại trở thành “hộp đen” giúp kỹ sư lần ngược nguyên nhân.
Thực tế, rất nhiều tình huống troubleshooting kéo dài không phải vì lỗi quá phức tạp, mà vì log không đến nơi, log bị thiếu, timestamp sai, hoặc mức severity cấu hình không đúng.
Bài này sẽ hướng dẫn cách troubleshooting syslog theo tư duy thực chiến trên ba nền tảng phổ biến: Cisco IOS, Windows Server và Linux.
Bước 1: Luôn kiểm tra câu hỏi cơ bản nhất — Syslog có thực sự đang chạy không?
Nghe có vẻ hiển nhiên, nhưng đây là lỗi phổ biến nhất.
Rất nhiều kỹ sư lao ngay vào phân tích firewall, routing hay application, trong khi thực tế logging chưa được bật.
Troubleshooting Syslog trên Cisco IOS
Kiểm tra trạng thái logging
Lệnh đầu tiên:
show logging
Ví dụ output:
R1# show logging
Syslog logging: enabled
Console logging: level informational
Monitor logging: level informational
Buffer logging: level debugging
Trap logging: level warnings
Logging to 10.1.100.100 (udp port 514)
Điều cần đọc trong output này:
Syslog logging: enabled
Nếu thấy disabled thì syslog chưa chạy.
Kiểm tra severity level
Đây là lỗi số 1 khi “không thấy log”.
Cisco syslog dùng severity từ 0 đến 7:
Ví dụ:
logging trap warnings
Điều này có nghĩa chỉ gửi log mức 0–4 lên syslog server.
Nếu bạn đang debug routing:
debug ip ospf events
thì log debug severity 7 sẽ KHÔNG được gửi.
Muốn gửi debug:
logging trap debugging
Đây là lỗi rất thường gặp trong doanh nghiệp.
Kỹ sư bật debug nhưng syslog server không nhận gì rồi tưởng firewall chặn.
Kiểm tra syslog server IP
Ví dụ:
logging host 10.1.100.100
Kiểm tra reachability:
ping 10.1.100.100
Nếu ping fail:
Không có kết nối layer 3 thì syslog không thể hoạt động.
Kiểm tra UDP 514 có bị chặn không
Syslog truyền thống dùng:
UDP 514
Kiểm tra ACL:
show access-lists
Hoặc interface ACL:
show run interface
Ví dụ lỗi:
deny udp any host 10.1.100.100 eq 514
Firewall nội bộ cũng có thể block.
Kiểm tra source interface
Router nhiều interface thường gặp lỗi này.
Ví dụ syslog server chỉ cho phép subnet management:
10.10.10.0/24
Nhưng router lại gửi log từ interface khác:
192.168.1.1
Fix:
logging source-interface Loopback0
Hoặc:
logging source-interface GigabitEthernet0/0
Kiểm tra buffer đầy
Cisco buffer mặc định:
8192 bytes
Quá nhỏ trong môi trường debug.
Output:
Log Buffer (8192 bytes)
Nếu log bị mất:
logging buffered 65536 debugging
SSH/Telnet không thấy log?
Rất nhiều người gặp trường hợp này.
SSH vào router:
ssh admin@router
Bật debug:
debug ip packet
Không thấy gì.
Nguyên nhân:
terminal monitor
chưa bật.
Fix:
terminal monitor
Timestamp sai
Log không có thời gian = ác mộng troubleshooting.
Bật timestamp:
service timestamps log datetime msec
service timestamps debug datetime msec
Dùng NTP:
ntp server 192.168.1.10
Kiểm tra:
show ntp status
Nếu clock sai, correlation giữa firewall / switch / SIEM sẽ rất khó.
Troubleshooting Syslog trên Windows Server
Windows không dùng syslog native theo kiểu Unix.
Thay vào đó dùng:
Nếu dùng Kiwi Syslog, NXLog, Syslog-ng agent hoặc Splunk forwarder thì troubleshooting như sau.
Kiểm tra service có chạy không
PowerShell:
Get-Service | findstr -i syslog
Hoặc:
Get-Service nxlog
Nếu stopped:
Start-Service nxlog
Kiểm tra port listening
Syslog receiver thường dùng:
UDP 514
TCP 514
Check:
netstat -ano | findstr 514
Ví dụ:
UDP 0.0.0.0:514
Nếu không có listener thì agent chưa chạy.
Windows Firewall block
Kiểm tra:
Get-NetFirewallRule
Hoặc nhanh:
wf.msc
Cho phép:
Ví dụ:
New-NetFirewallRule -DisplayName "Syslog UDP" `
-Direction Inbound `
-Protocol UDP `
-LocalPort 514 `
-Action Allow
Kiểm tra Event Viewer
Nếu app báo lỗi nhưng syslog không có:
eventvwr.msc
Xem:
Nếu Windows event có nhưng syslog server không có → lỗi ở forwarding layer.
Test connectivity
Test-NetConnection 10.1.100.100 -Port 514
Nếu fail:
Kiểm tra cấu hình agent
Ví dụ NXLog:
C:\Program Files\nxlog\conf\nxlog.conf
Lỗi thường gặp:
Sai destination:
Host 10.1.100.200
thay vì:
10.1.100.100
Sai protocol:
TCP vs UDP mismatch.
Troubleshooting Syslog trên Linux
Linux là môi trường syslog “chuẩn”.
Thường dùng:
Kiểm tra service
Rsyslog:
systemctl status rsyslog
Khởi động:
sudo systemctl start rsyslog
Enable boot:
sudo systemctl enable rsyslog
Kiểm tra port listening
ss -lunp | grep 514
hoặc:
netstat -ulnp | grep 514
Nếu không thấy:
service chưa bind.
Kiểm tra config
Rsyslog:
/etc/rsyslog.conf
hoặc:
/etc/rsyslog.d/
Ví dụ enable UDP:
module(load="imudp")
input(type="imudp" port="514")
TCP:
module(load="imtcp")
input(type="imtcp" port="514")
Reload:
systemctl restart rsyslog
Firewall block
Ubuntu:
ufw status
Allow:
ufw allow 514/udp
RHEL/CentOS:
firewall-cmd --list-all
Allow:
firewall-cmd --add-port=514/udp --permanent
firewall-cmd --reload
SELinux block
RHEL thường dính lỗi này.
Check:
getenforce
Nếu:
Enforcing
thì có thể SELinux đang block syslog binding.
Check audit:
ausearch -m avc
Test gửi log thủ công
Cực kỳ hữu ích.
logger "Test syslog message"
Remote:
logger -n 10.1.100.100 -P 514 "Remote syslog test"
Nếu test thành công nhưng app log không tới → lỗi ở application.
Theo dõi realtime
tail -f /var/log/syslog
hoặc:
journalctl -f
Tư duy troubleshooting thực chiến
Khi syslog lỗi, đi theo flow:
1. Service có chạy không?
Nếu không, sửa service.
2. Port có listen không?
Nếu không, cấu hình receiver.
3. Có network reachability không?
Ping / traceroute.
4. Firewall / ACL có block không?
UDP 514 là nghi phạm hàng đầu.
5. Severity đúng chưa?
Rất nhiều log “mất tích” vì filter level.
6. Timestamp đúng chưa?
Correlation trong SIEM phụ thuộc vào thời gian chính xác.
7. Source IP đúng chưa?
Đặc biệt trên router/firewall nhiều interface.
Kết luận cho bài Syslog
Syslog troubleshooting không khó nếu đi đúng quy trình.
Phần lớn sự cố rơi vào vài nhóm quen thuộc:
Trong SOC, NOC, hoặc hạ tầng enterprise, một hệ thống logging không ổn định gần như đồng nghĩa với việc “bay mù”.
Không có log, troubleshooting chỉ là phỏng đoán.
Syslog là một trong những công cụ quan trọng nhất trong vận hành hệ thống và mạng. Khi mọi thứ hoạt động bình thường, syslog chỉ đơn giản là nơi ghi nhận sự kiện. Nhưng khi sự cố xảy ra, syslog lại trở thành “hộp đen” giúp kỹ sư lần ngược nguyên nhân.
Thực tế, rất nhiều tình huống troubleshooting kéo dài không phải vì lỗi quá phức tạp, mà vì log không đến nơi, log bị thiếu, timestamp sai, hoặc mức severity cấu hình không đúng.
Bài này sẽ hướng dẫn cách troubleshooting syslog theo tư duy thực chiến trên ba nền tảng phổ biến: Cisco IOS, Windows Server và Linux.
Bước 1: Luôn kiểm tra câu hỏi cơ bản nhất — Syslog có thực sự đang chạy không?
Nghe có vẻ hiển nhiên, nhưng đây là lỗi phổ biến nhất.
Rất nhiều kỹ sư lao ngay vào phân tích firewall, routing hay application, trong khi thực tế logging chưa được bật.
Troubleshooting Syslog trên Cisco IOS
Kiểm tra trạng thái logging
Lệnh đầu tiên:
show logging
Ví dụ output:
R1# show logging
Syslog logging: enabled
Console logging: level informational
Monitor logging: level informational
Buffer logging: level debugging
Trap logging: level warnings
Logging to 10.1.100.100 (udp port 514)
Điều cần đọc trong output này:
Syslog logging: enabled
Nếu thấy disabled thì syslog chưa chạy.
Kiểm tra severity level
Đây là lỗi số 1 khi “không thấy log”.
Cisco syslog dùng severity từ 0 đến 7:
- 0 Emergency
- 1 Alert
- 2 Critical
- 3 Error
- 4 Warning
- 5 Notification
- 6 Informational
- 7 Debugging
Ví dụ:
logging trap warnings
Điều này có nghĩa chỉ gửi log mức 0–4 lên syslog server.
Nếu bạn đang debug routing:
debug ip ospf events
thì log debug severity 7 sẽ KHÔNG được gửi.
Muốn gửi debug:
logging trap debugging
Đây là lỗi rất thường gặp trong doanh nghiệp.
Kỹ sư bật debug nhưng syslog server không nhận gì rồi tưởng firewall chặn.
Kiểm tra syslog server IP
Ví dụ:
logging host 10.1.100.100
Kiểm tra reachability:
ping 10.1.100.100
Nếu ping fail:
- routing issue
- default gateway sai
- VLAN sai
- interface down
Không có kết nối layer 3 thì syslog không thể hoạt động.
Kiểm tra UDP 514 có bị chặn không
Syslog truyền thống dùng:
UDP 514
Kiểm tra ACL:
show access-lists
Hoặc interface ACL:
show run interface
Ví dụ lỗi:
deny udp any host 10.1.100.100 eq 514
Firewall nội bộ cũng có thể block.
Kiểm tra source interface
Router nhiều interface thường gặp lỗi này.
Ví dụ syslog server chỉ cho phép subnet management:
10.10.10.0/24
Nhưng router lại gửi log từ interface khác:
192.168.1.1
Fix:
logging source-interface Loopback0
Hoặc:
logging source-interface GigabitEthernet0/0
Kiểm tra buffer đầy
Cisco buffer mặc định:
8192 bytes
Quá nhỏ trong môi trường debug.
Output:
Log Buffer (8192 bytes)
Nếu log bị mất:
logging buffered 65536 debugging
SSH/Telnet không thấy log?
Rất nhiều người gặp trường hợp này.
SSH vào router:
ssh admin@router
Bật debug:
debug ip packet
Không thấy gì.
Nguyên nhân:
terminal monitor
chưa bật.
Fix:
terminal monitor
Timestamp sai
Log không có thời gian = ác mộng troubleshooting.
Bật timestamp:
service timestamps log datetime msec
service timestamps debug datetime msec
Dùng NTP:
ntp server 192.168.1.10
Kiểm tra:
show ntp status
Nếu clock sai, correlation giữa firewall / switch / SIEM sẽ rất khó.
Troubleshooting Syslog trên Windows Server
Windows không dùng syslog native theo kiểu Unix.
Thay vào đó dùng:
- Event Viewer
- Windows Event Forwarding
- Syslog Agent
- SIEM connector
Nếu dùng Kiwi Syslog, NXLog, Syslog-ng agent hoặc Splunk forwarder thì troubleshooting như sau.
Kiểm tra service có chạy không
PowerShell:
Get-Service | findstr -i syslog
Hoặc:
Get-Service nxlog
Nếu stopped:
Start-Service nxlog
Kiểm tra port listening
Syslog receiver thường dùng:
UDP 514
TCP 514
Check:
netstat -ano | findstr 514
Ví dụ:
UDP 0.0.0.0:514
Nếu không có listener thì agent chưa chạy.
Windows Firewall block
Kiểm tra:
Get-NetFirewallRule
Hoặc nhanh:
wf.msc
Cho phép:
- UDP 514
- TCP 514
Ví dụ:
New-NetFirewallRule -DisplayName "Syslog UDP" `
-Direction Inbound `
-Protocol UDP `
-LocalPort 514 `
-Action Allow
Kiểm tra Event Viewer
Nếu app báo lỗi nhưng syslog không có:
eventvwr.msc
Xem:
- System
- Application
- Security
Nếu Windows event có nhưng syslog server không có → lỗi ở forwarding layer.
Test connectivity
Test-NetConnection 10.1.100.100 -Port 514
Nếu fail:
- firewall
- routing
- server unreachable
Kiểm tra cấu hình agent
Ví dụ NXLog:
C:\Program Files\nxlog\conf\nxlog.conf
Lỗi thường gặp:
Sai destination:
Host 10.1.100.200
thay vì:
10.1.100.100
Sai protocol:
TCP vs UDP mismatch.
Troubleshooting Syslog trên Linux
Linux là môi trường syslog “chuẩn”.
Thường dùng:
- rsyslog
- syslog-ng
- journald
Kiểm tra service
Rsyslog:
systemctl status rsyslog
Khởi động:
sudo systemctl start rsyslog
Enable boot:
sudo systemctl enable rsyslog
Kiểm tra port listening
ss -lunp | grep 514
hoặc:
netstat -ulnp | grep 514
Nếu không thấy:
service chưa bind.
Kiểm tra config
Rsyslog:
/etc/rsyslog.conf
hoặc:
/etc/rsyslog.d/
Ví dụ enable UDP:
module(load="imudp")
input(type="imudp" port="514")
TCP:
module(load="imtcp")
input(type="imtcp" port="514")
Reload:
systemctl restart rsyslog
Firewall block
Ubuntu:
ufw status
Allow:
ufw allow 514/udp
RHEL/CentOS:
firewall-cmd --list-all
Allow:
firewall-cmd --add-port=514/udp --permanent
firewall-cmd --reload
SELinux block
RHEL thường dính lỗi này.
Check:
getenforce
Nếu:
Enforcing
thì có thể SELinux đang block syslog binding.
Check audit:
ausearch -m avc
Test gửi log thủ công
Cực kỳ hữu ích.
logger "Test syslog message"
Remote:
logger -n 10.1.100.100 -P 514 "Remote syslog test"
Nếu test thành công nhưng app log không tới → lỗi ở application.
Theo dõi realtime
tail -f /var/log/syslog
hoặc:
journalctl -f
Tư duy troubleshooting thực chiến
Khi syslog lỗi, đi theo flow:
1. Service có chạy không?
Nếu không, sửa service.
2. Port có listen không?
Nếu không, cấu hình receiver.
3. Có network reachability không?
Ping / traceroute.
4. Firewall / ACL có block không?
UDP 514 là nghi phạm hàng đầu.
5. Severity đúng chưa?
Rất nhiều log “mất tích” vì filter level.
6. Timestamp đúng chưa?
Correlation trong SIEM phụ thuộc vào thời gian chính xác.
7. Source IP đúng chưa?
Đặc biệt trên router/firewall nhiều interface.
Kết luận cho bài Syslog
Syslog troubleshooting không khó nếu đi đúng quy trình.
Phần lớn sự cố rơi vào vài nhóm quen thuộc:
- logging chưa bật
- severity sai
- UDP 514 bị chặn
- source interface sai
- service receiver không chạy
- firewall/SELinux block
- timestamp lệch
Trong SOC, NOC, hoặc hạ tầng enterprise, một hệ thống logging không ổn định gần như đồng nghĩa với việc “bay mù”.
Không có log, troubleshooting chỉ là phỏng đoán.