15 Linux Log Commands Every DevOps Engineer Should Know

somewhere in the logs is usually a clue that explains what happened

I’ve seen engineers open multi-gigabyte log files in a text editor and wait minutes for them to load, only for the editor to freeze.

Knowing a few Linux commands can save hours during an incident.

Here, we’ll talk about some Linux commands and techniques that make log analysis faster, simpler, and more effective in production environments.

1. less

The safest and most useful command for viewing log files.

less /var/log/syslog

Example:

less /var/log/nginx/error.log

Useful shortcuts:

Space   Next page
b       Previous page
/word   Search
n       Next match
N       Previous match
g       Start of file
G       End of file
q       Quit

Unlike a text editor, less does not load the entire file into memory.

That means you can safely inspect files that are hundreds of megabytes or even several gigabytes in size.

Use it when:

• Investigating incidents
• Reviewing historical logs
• Searching through large files

For most engineers, this should be the default command for opening log files.

2. tail

Shows the most recent log entries.

tail /var/log/syslog

Default output:

Last 10 lines

Show more lines:

tail -n 50 app.log

Example:

tail -n 100 /var/log/nginx/error.log

Most troubleshooting starts with recent events.

If users report a problem right now, the last few log entries often contain useful clues.

Use it when:

• Checking recent errors
• Investigating outages
• Reviewing deployment activity

3. tail -F

One of the most valuable commands in production.

tail -F app.log

Many engineers use:

tail -f app.log

However, production systems rotate logs.

When rotation happens, tail -f may continue watching the old file.

tail -F automatically follows the new file after rotation.

Use it for:

• Monitoring applications
• Watching deployments
• Following active incidents

If you’re working in production, prefer -F over -f.

4. head

Shows the beginning of a file.

head app.log

Show first 20 lines:

head -n 20 app.log

The first few lines often reveal:

• Log format
• Timestamp structure
• Application startup information
• Headers and metadata

Useful when examining an unfamiliar log.

5. grep

Searches logs for patterns.

Find errors:

grep ERROR app.log

Case-insensitive search:

grep -i error app.log

Count matches:

grep -c ERROR app.log

Find failed SSH logins:

grep "Failed password" /var/log/auth.log

Most investigations begin with a search.

Instead of reading thousands of lines manually, grep helps you jump directly to relevant events.

6. grep with Context

Errors rarely exist in isolation.

Often the most useful information appears immediately before or after an error.

Show lines after a match:

grep -A 5 ERROR app.log

Show lines before:

grep -B 5 ERROR app.log

Show both:

grep -C 5 ERROR app.log

Example:

grep -C 10 "Connection refused" app.log

This frequently reveals the actual root cause.

7. Recursive grep

Search across multiple log files at once.

grep -Ri timeout /var/log/myapp

Find all errors:

grep -R ERROR /var/log/myapp

Applications often split logs across multiple files.

Searching one file at a time wastes valuable investigation time.

8. awk

One of the most powerful Linux text-processing tools.

Extract IP addresses:

awk '{print $1}' access.log

Find the most active IPs:

awk '{print $1}' access.log | sort | uniq -c | sort -nr

Example output:

1200 10.0.0.5
950 10.0.0.8

Logs are often structured.

Awk allows you to extract and analyze specific fields without writing scripts.

This is especially useful for:

• Traffic analysis
• Request counting
• Identifying suspicious activity

9. sort

Sorts log output.

Example:

sort errors.log

Sort request counts:

awk '{print $1}' access.log | sort

Sorted data is easier to analyze and summarize.

Many useful log-analysis pipelines depend on sorting.

10. uniq

Removes duplicates and counts occurrences.

sort errors.log | uniq

Count duplicates:

sort errors.log | uniq -c

Example output:

35 Database timeout
12 Connection refused

It helps identify recurring issues quickly.

Instead of seeing hundreds of repeated messages, you immediately see the most common problems.

11. journalctl

The standard logging interface on systemd-based Linux systems.

View logs:

journalctl

Recent entries:

journalctl -n 50

Follow logs live:

journalctl -f

Logs for a service:

journalctl -u nginx

Errors only:

journalctl -p err

Last hour:

journalctl --since "1 hour ago"

Follow service logs:

journalctl -u docker -f

Many modern Linux systems rely heavily on systemd journals.

Learning journalctl dramatically improves troubleshooting efficiency.

12. zgrep

Search compressed log archives without extracting them.

Search archived logs:

zgrep ERROR app.log.1.gz

Count matches:

zgrep -c ERROR app.log.1.gz

Find HTTP 500 errors:

zgrep " 500 " access.log.2.gz

Important clues are often hidden in yesterday’s logs.

Many incidents span multiple days, making archived logs essential.

13. jq

Modern applications increasingly produce JSON logs.

Example log:

{"level":"ERROR","service":"api","message":"Database timeout"}

Filter errors:

jq 'select(.level=="ERROR")' app.log

Extract messages:

jq -r '.message' app.log

JSON logs are now common in cloud-native environments.

Trying to analyze them with grep alone can be painful.

jq makes JSON logs easy to query.

14. ripgrep (rg)

A faster and more modern alternative to grep.

Search for errors:

rg ERROR

Search recursively:

rg timeout /var/log

ripgrep is significantly faster than grep on large directory trees.

Many engineers now use it as their default search tool.

15. kubectl logs

If you work with Kubernetes, this command is essential.

View pod logs:

kubectl logs pod-name

Follow logs:

kubectl logs -f pod-name

Deployment logs:

kubectl logs -f deployment/api

Previous container logs:

kubectl logs --previous pod-name

Many modern applications never write directly to traditional log files.

Instead, logs are streamed through containers and Kubernetes.

Knowing how to retrieve them quickly is critical.

Let’s see some examples

Find Top IP Addresses

awk '{print $1}' access.log \
| sort \
| uniq -c \
| sort -nr \
| head

Output:

1200 10.0.0.5
950 10.0.0.8
800 10.0.0.10

Useful for:

• Traffic analysis
• Abuse detection
• Capacity planning

Find Most Common Errors

grep ERROR app.log \
| sort \
| uniq -c \
| sort -nr

Useful for quickly identifying recurring failures.

Monitor Errors During Deployment

tail -F app.log | grep --line-buffered ERROR

This continuously displays new error entries as they appear.

Follow Docker Service Logs

journalctl -u docker -f

Useful during:

• Container startup failures
• Image pull issues
• Runtime errors

Now, let’s see some Mistakes

Opening Huge Logs in an Editor

Avoid:

cat app.log

or large text editors.

Prefer:

less app.log

Ignoring Archived Logs Always check compressed logs.

Use:

zgrep

instead of manually extracting archives.

Searching Without Context Avoid:

grep ERROR app.log

Prefer:

grep -C 5 ERROR app.log

The surrounding lines often contain the real explanation.

[embed]10 Bash one-liners for quick file ops (copy, move, find, replace) bulk renaming, searching, safe deletes, remote copies, quick archives, and in-place text replacementsmedium.com

[embed]9 SSH Performance Tweaks Every DevOps Engineer Should Know Ciphers, Compression, and Keepalives that actually make a differenceblog.devops.dev