Application, Network, Cloud & DB Logs

1🏗️ Application & Web Server Logs

Enterprise applications maintain their own logs — Tomcat, JBoss/WildFly, WebSphere, WebLogic, IIS, Apache, Nginx, Java/.NET/Node.js/Python applications, SAP, Oracle applications, and authentication platforms all generate their own formats. An Apache access log entry looks like:

203.0.113.24 - - [30/Aug/2026:10:10:45 +0000]
"GET /login HTTP/1.1" 200 4821

Reading left to right: client IP, timestamp, HTTP method, requested resource, HTTP version, response status, response size — every field you'd need for a first pass at an investigation, in one line.

Nginx typically logs to /var/log/nginx/access.log and /var/log/nginx/error.log:

10.20.30.40 - - [30/Aug/2026:10:31:15 +0000]
"POST /api/login HTTP/1.1" 401 247

— the server returned 401 Unauthorized (Module 13, Lesson 2). IIS stores logs under directories like C:\inetpub\logs\LogFiles\, with configurable fields including date, time, client IP, username, server IP, HTTP method, URI, HTTP status, user agent, and processing time.

2☕ Java Logs & Stack Traces

Enterprise Java applications commonly use Log4j, Logback, java.util.logging, or SLF4J:

2026-08-30 11:21:11,821 ERROR
[AuthenticationService]
[requestId=f37a92]
Authentication provider timeout

Application errors sometimes produce stack traces:

java.lang.NullPointerException
    at com.company.auth.UserService.login(UserService.java:148)
    at com.company.web.LoginController.authenticate(LoginController.java:71)
    at ...

Beginners sometimes assume they need to understand every line. Start instead with the exception type, the error message, the first application-specific line, and any Caused by: section — e.g. Caused by: java.sql.SQLTimeoutException: Database query timed out. The Caused by section often reveals the actual underlying failure hiding beneath the surface exception.

3🌐 Network Device Logs

Firewalls, routers, switches, VPN gateways, load balancers, wireless controllers, proxies, and DNS/DHCP servers all produce important logs. A firewall log:

timestamp=2026-08-30T10:30:01Z
src=10.20.10.55
dst=172.16.5.20
src_port=52144
dst_port=443
protocol=TCP
action=ALLOW

action=ALLOW proves the firewall let that connection through — it does not prove the application on the other end actually processed it (Module 13, Lesson 5's gateway/WAF layering makes exactly this point).

DNS logs show client=10.20.30.14 query=login.company.com type=A response=203.0.113.20 — valuable during malware investigations for spotting communication with suspicious domains (Module 11, Lesson 4). DHCP logs matter because device IPs change: if an alert says 10.20.30.42 performed suspicious activity at 14:32, a DHCP record like 14:00 MAC=AA:BB:CC:11:22:33 IP=10.20.30.42 hostname=LAPTOP-JSMITH connects that IP to an actual device. Proxy logs record user, source IP, destination URL/domain, HTTP status, bytes transferred, user agent, and policy action — extremely useful for phishing and malware investigations.

4☁︑ Cloud & SaaS Logs

AWS: CloudTrail (API activity — CreateUser, DeleteBucket, AssumeRole, StopInstances, PutBucketPolicy), CloudWatch Logs, VPC Flow Logs, ELB access logs, S3 access logs, Route 53 logs, GuardDuty findings. Azure: Azure Activity Log, Azure Monitor, Log Analytics, Entra sign-in/audit logs, NSG flow logs, Defender for Cloud. Google Cloud: Cloud Logging, Cloud Audit Logs, VPC Flow Logs, Identity logs, Security Command Center.

SaaS logs matter just as much — Microsoft 365, Google Workspace, Salesforce, ServiceNow, Okta, GitHub, Slack, Zoom, Workday, SAP cloud services. Important events include user login, file download, role change, MFA modification, API access, application authorisation, email forwarding rule creation, and administrator action (the exact mailbox-forwarding-rule signal Module 8's BEC section and Module 11's SOC content both flag as high-value).

5📦 Container & Kubernetes Logs

Docker: docker logs <container>, or docker logs -f webapp01 to follow live. Containers are often short-lived, which is exactly why centralised logging (Lesson 5) becomes so important — the container itself might not exist anymore by the time you go looking.

Kubernetes adds another layer: kubectl logs <pod>, e.g. kubectl logs authentication-service-5f4d7b79cb-kd82x. An application may run across many replicas (authentication-service-pod1, pod2, pod3), so one user's requests can land on different pods across their session — correlation IDs (Lesson 1) become essential here, not optional, since no single pod's logs will show the whole story.

6🔗 Logs, APIs, HTTP Codes & Certificates

Module 13 covered API troubleshooting from the request/response side — logs are the other half. If POST /oauth/token returns 401 Unauthorized, the relevant server log might show client_id=customer_portal grant_type=client_credentials result=AUTHENTICATION_FAILED reason=INVALID_CLIENT_SECRET. The HTTP response tells you what (401); the server log tells you why.

You'll meet the same status codes across every log source: 200/201/204 success, 301/302 redirect, 400/401/403/404/408/429 client errors, 500/502/503/504 server errors (Module 13, Lesson 2). A 504 could originate at a CDN, WAF, load balancer, reverse proxy, API gateway, or the application itself — logs are what let you determine which component actually generated it, exactly the layered-troubleshooting point Module 13's Lesson 5 made.

TLS and certificate problems show up in logs too — SSLHandshakeException: PKIX path building failed, certificate has expired, or hostname verification failed typically point to an expired certificate, an untrusted CA, an incorrect hostname, a missing intermediate certificate, or a TLS version mismatch.

7💾 Database Logs

Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, MongoDB and DB2 all generate important events of their own: authentication failures, deadlocks, slow queries, connection exhaustion, storage failures, backup failures, replication issues, and permission errors. ERROR: remaining connection slots are reserved is a classic example — an application might report "authentication failed" to its own users when the real cause is that it simply couldn't get a database connection at all, nothing to do with credentials whatsoever.

Lesson Outcome

You should now be able to read Apache/Nginx/IIS access logs, use Java stack traces (starting from the exception type and any "Caused by" line) instead of every line, interpret firewall/DNS/DHCP/proxy logs and explain why a firewall ALLOW doesn't guarantee application success, name the major AWS/Azure/GCP and SaaS log sources, explain why correlation IDs matter even more in Kubernetes, and connect an HTTP status code back to the log entry that explains it. Lesson 5 covers how all these sources actually get collected, managed and searched at scale.