eduTrain

Lesson 7 / الدرس 7

Logs you can actually answer questions with / سجلات تستطيع الإجابة بها فعلًا

The PHP course covered what to log. This is about the log as an object on a server: where it lives, why it eventually fills the disk and stops the site, and what makes the difference between a file you grep and a file you give up on.

غطّت دورة PHP ما يُسجَّل. وهذا عن السجل بوصفه شيئًا على خادم: أين يعيش، ولماذا يملأ القرص في النهاية فيوقف الموقع، وما الفرق بين ملف تبحث فيه وملف تستسلم أمامه.

A server has more than one log and they answer different questions. The access log says what was requested; the error log says what went wrong; your application log says what your code decided. Most investigations need two of the three, and the skill is knowing which.

The disk fills, and then nothing works

A log grows forever unless something stops it. A full disk is one of the worst failures a server has, because everything breaks at once and none of it says "disk full" — the database refuses writes, sessions cannot be saved, uploads fail, and the log that would tell you why cannot be written to either. 

# /etc/logrotate.d/mysite — rotation is not optional, it is the
# difference between a log and a slow outage.

/home/site/storage/logs/*.log {
    daily
    rotate 14          # keep two weeks, then delete
    compress           # old ones shrink by roughly 90%
    missingok          # do not fail if there is nothing yet
    notifempty
    create 0640 site site
}

# And check, occasionally, before it matters:
$ df -h                          # how full is the disk
$ du -sh /home/site/storage/*    # what is using it
Fourteen days is a decision, not a default. Keep long enough that a problem reported on Monday about last Wednesday is still investigable, and short enough that you are not storing months of personal data you never intended to keep — which is a question about the law as much as about disk space.

Reading one when you need an answer 

# What is failing right now, as it happens
$ tail -f storage/logs/php.log

# The commonest errors, most frequent first — this is the one that
# turns a wall of text into a list of things to fix
$ grep -o 'PHP [A-Za-z ]*error[^:]*' php.log | sort | uniq -c | sort -rn | head

# Everything that happened around a specific moment
$ grep '2026-08-18 14:2' php.log

# Which URLs are returning 500, and how often
$ awk '$9 == 500 {print $7}' access.log | sort | uniq -c | sort -rn

# Is one address doing something unusual
$ awk '{print $1}' access.log | sort | uniq -c | sort -rn | head
These are the terminal course's pipes doing real work. The sort | uniq -c | sort -rn pattern is the one worth memorising — it turns any log into "the most common thing, then the next", which is almost always the question you actually had.

Check yourself / اختبر نفسك

1. Why is a full disk one of the worst server failures?

2. How long should logs be kept?

3. What does sort | uniq -c | sort -rn give you from a log?