grep, sed and awk: three commands to find problems in logs
Published on 2026-10-26 by frfrand
Useful examples with grep sed awk to investigate errors on servers
Your API generated thousands of log lines and you want to find only the 500 errors from this morning. No need to open the file and scroll for ten minutes: grep, sed and awk solve searches, substitutions and columns from the terminal.
I'll show you where the problem is, how to verify it without guessing, and what I'd do in an application that actually has users. You don't need to memorize an entire manual to solve a specific failure.
What grep, sed and awk mean in practice
grep selects lines by pattern, sed transforms text streams and awk works with fields and rules. They are distinct tools that you can combine, but first you need to know how the log you're going to read is structured.
A clarification before touching the server: if the project is already in production, save the state you found and check which user and machine you're going to run the commands on. Working as root without need and changing several things at once makes it harder to find the cause of an error.
Useful commands to get started
grep -n 'ERROR' /var/log/miapp/app.log | tail -20
# Ver un rango sin modificar el archivo
sed -n '100,120p' /var/log/miapp/app.log
# Ejemplo con un archivo de tres columnas separado por espacios
awk '{print $1, $3}' accesos.txt
# Para logs de systemd
journalctl -u miapp --since '1 hour ago'Paths, unit names and domains are examples. Adapt them to your service. If a command requires administrator permissions, check what changes and why. Diagnostic queries should come before modifications.
Step by step, with checks
- Identify if the log source is a text file or journalctl.
- Search for the keyword with
grep -nand verify the context around each match. - For a specific line, use
sed -n; without-i,seddoes not modify the file. - If you need fields, choose a correct delimiter with
awk -Fand test with a few lines. - Save frequent commands in an incident document without including log secrets.
After each step, verify an observable result: a status, a file, an HTTP response, or a log entry. If you find an unexpected message, save it for investigation instead of hiding it with repeated restarts.
Real example: an application that needs maintenance
On a booking platform, you search for all 500s from one hour. Then you cross-reference their timestamp with PostgreSQL errors. Finding the match between API and database usually tells you more than restarting Nginx.
At the end, test the full path: enter via domain, call the API, write a test data point, and verify that the information is still there after a controlled restart. A server that "starts up" is not always an application that works.
Mistakes worth avoiding
An awk '{print $2}' is not useful if the field contains spaces or the file is JSON. For structured JSON logs, jq is usually more appropriate. Be careful with sed -i: it does modify files.
It is also important that credentials do not end up in terminal history, logs, shared files, or screenshots. For users and services, use minimal permissions and document who can revoke access.
How ArduMaker fits into this scenario
When an application runs on an ArduMaker VPS, combine the terminal with service logs to separate backend, proxy, and database errors.
ArduMaker can help you manage VPSs, deploy repositories, and work with services, databases, and domains from the same platform. It does not replace what we just explained about Linux: precisely for that reason, it is worth understanding diagnostics and having a way to repeat them.
When it is worth automating
If the task repeats, document the manual procedure and its checks first. Then consider a script or a scheduled task with visible errors, logs, and limited permissions. Do not automate a command that you do not yet know how to recover when something goes wrong.
Frequently asked questions
Can I try it without affecting customers? In many cases, yes: a staging VPS or a separate test service allows you to validate the configuration before changing production.
How do I know if it went well? Check logs and a functional operation, not just that the command ended with exit code zero.
When do I need more resources? When metrics indicate CPU, RAM, disk, or connection saturation. A configuration failure is rarely fixed by contracting more memory.
References
In one sentence: first understand the error, then change one concrete thing and check its effect. That discipline saves you many hours of support.