Part 5: Watching Over the Blog — Logging and Understanding Problems

The Problem: When Something Breaks, How Do You Know?

Imagine you're flying an airplane. You can't see everything that's happening — engines, fuel, instruments. But you have a black box recorder that logs everything. If something goes wrong, investigators replay the logs and find the problem.

Websites have the same problem. Thousands of things happen every second. If something breaks, you need to know what happened. That's what logging does.

What Is Logging?

Logging is keeping a record of everything that happens on your website. For example:

2026-02-20 10:45:23 - User john@example.com logged in successfully
2026-02-20 10:45:45 - User john@example.com created post: "My First Blog"
2026-02-20 10:46:12 - Image uploaded: thumbnail.jpg (250 KB)
2026-02-20 10:46:15 - Post published: "My First Blog"
2026-02-20 10:46:18 - User sarah@example.com viewed post
2026-02-20 10:47:03 - Database query took 1.2 seconds (slow!)

Every action gets recorded with a timestamp. It's like a security camera for your website — you can watch what happened.

Why This Matters

If someone complains: "My post didn't publish!" — I can check the logs and see:

• Did they actually log in? (yes/no)
• Did they try to publish? (yes/no)
• Did the database save it? (yes/no)
• What error did we get? (specific error message)

Without logs, I'd just be guessing.

The Three Types of Logs

1. Info Logs (Everything's Normal)

User logged in successfully
Post was published
Image was uploaded
Connection pool has 5 connections ready

These are normal events. They're useful for understanding the flow of what happened.

2. Warning Logs (Something's Odd)

Rate limit triggered for IP 192.168.1.1 (5 attempts in 1 minute)
Database query took 3 seconds (slower than usual)
User tried to access a post they don't have permission to view

Warnings are "not wrong, but noteworthy." Something might need attention.

3. Error Logs (Something Broke)

Database connection failed
User registration failed: email already exists
Image upload failed: file too large
Password hashing took 10 seconds (too slow!)

Errors mean something didn't work as expected.

What AllBengal Logs

1. Authentication Events

User john@example.com logged in from IP 203.0.113.45
User sarah@example.com logged out
User attempted login with wrong password (rate limit: 3/5 attempts)
User logged in via Google OAuth

This helps me:

• Spot if someone is hacking an account
• See if there are suspicious login patterns
• Know when legitimate users need to reset passwords

2. API Requests

POST /api/blog/posts - User 123 - Response time: 245ms
GET /api/blog/posts/my-first-post - User anonymous - Response time: 89ms
DELETE /api/blog/posts/456 - User 789 - Success

This helps me:

• Understand traffic patterns
• Find slow endpoints
• See if anyone is making unusual requests

3. Security Events

Suspicious HTML detected in post: removed 1 script tag
Rate limit triggered for IP 192.168.1.1
CORS request rejected from unknown origin

This helps me:

• Catch attempted attacks
• Understand security threats
• Improve protection

4. Database Operations

Query took 234ms: SELECT * FROM posts WHERE status='published'
Connection acquired from pool
Database connection pool is 8/10 connections used

This helps me:

• Find slow database queries
• Plan for growth
• Debug performance issues

5. Business Events

Post published: "My First Blog" by user_id=123
Post deleted: "Old Thoughts" by user_id=123
Tag created: "Technology"
User registered

This helps me:

• Understand what's actually happening on the platform
• See what's popular
• Track growth

How Logs Are Structured

AllBengal uses "structured logging," meaning each log entry is not just text, but data:

Old way (unstructured):

"User john@example.com logged in at 2026-02-20 10:45:23"

Hard to search and analyze.

New way (structured):

This is like a spreadsheet — I can sort, filter, and analyze it easily.

What I DON'T Log

For privacy and security, I never log:

I log enough to solve problems, but not so much that I'm a security risk.

Reading the Logs

When something goes wrong, I read logs like this:

User complaint: "My post disappeared!"

1. Find their login logs

2026-02-20 15:32:01 - User 456 logged in
2026-02-20 15:32:45 - User 456 created post: "My Thoughts"
2026-02-20 15:33:12 - Post saved to database: ID=789
2026-02-20 15:33:13 - Post published

2. Check their view logs

2026-02-20 16:00:01 - User 456 requested /api/blog/posts/my-thoughts
2026-02-20 16:00:02 - 404 Error: Post not found

3. Check database logs

2026-02-20 16:00:02 - SELECT * FROM posts WHERE id=789 - 0 rows returned

Diagnosis: Something deleted the post. Check who has delete permission... Found it! A bug in the delete function that shouldn't have been triggered.