Python Ops Scripts: 5 Single-File Tools Worth Building

If you do any kind of operations work, five single-file Python scripts are worth building: a log tailer with filters, a disk usage analyzer, a process monitor, a backup verifier, and a configuration file checker. Each one solves a recurring problem, requires only the Python standard library, and can be dropped onto any server without installing dependencies. This article explains what each tool does, why it earns its place, and how to design it so it stays useful for years.

Why Single-File Scripts Make Sense

Operations teams often reach for heavyweight monitoring stacks or configuration management tools when a single script would do the job. A single-file Python script has three concrete advantages: it is trivial to copy to a new machine (one file, no package install), it is easy to audit (you can read the whole thing in one sitting), and it has no hidden dependencies beyond the Python interpreter that most servers already have. The trade-off is that you must resist the urge to add features that would require third-party libraries or a second file.

These five tools are chosen because they cover the most common daily tasks: reading logs, checking disk space, watching processes, verifying backups, and validating configuration. Each can be written in under 200 lines and will save you from typing the same ad-hoc commands repeatedly.

Tool 1: Log Tailer with Filters

The first tool is a log tailer that reads a file continuously and prints lines that match a pattern. The standard tail -f shows everything; this script lets you filter by keyword, timestamp range, or regular expression. A practical implementation uses time.sleep() to poll the file, keeps track of the byte offset, and supports a case-insensitive search. For example, to watch only errors from a web server, you run python logtail.py /var/log/nginx/error.log --filter "crit" and it prints only lines containing that word.

Why build this instead of using grep? Because the script can remember its position across restarts (by saving the offset to a small state file), which is invaluable when you need to see what happened since the last check. It also lets you combine multiple filters with --and and --or logic, which is cumbersome with plain grep.

Tool 2: Disk Usage Analyzer with Threshold Alerts

Disk full is the most common cause of unexpected outages. A simple df -h tells you current usage, but it doesn’t tell you which directory is the culprit. The disk usage analyzer walks a given directory tree, sums file sizes per subdirectory, and prints the top N largest directories. It can also take a threshold argument and exit with a non-zero code if any directory exceeds it, making it suitable for cron jobs.

To avoid performance issues on huge trees, the script should use os.scandir() instead of os.listdir() and skip symbolic links to avoid infinite loops. A typical invocation is python disk_usage.py /var --top 10 --min-size 100M, which shows the ten largest subdirectories under /var that contain more than 100 MB.

Tool 3: Process Monitor with Resource Tracking

When a server becomes sluggish, you need to know which process is eating CPU or memory. The process monitor script reads /proc on Linux (or uses psutil if you allow one third-party dependency) and prints a sorted list of processes by CPU or memory usage. It can also watch a specific process name and alert if it disappears or restarts too often.

The standard-library-only version reads /proc/[pid]/stat and /proc/[pid]/status to get CPU time and memory. It should handle the case where a process exits between reads (catch FileNotFoundError). A useful feature is --watch nginx which polls every few seconds and prints a message if the process count changes, helping you detect crashes or fork bombs.

Tool 4: Backup Verifier

Backups are only useful if they can be restored. The backup verifier checks that a backup file is not corrupt and that its size matches expectations. For tar archives, it can run tar -tzf and count the number of entries; for SQL dumps, it can check that the file ends with the expected terminator (e.g., a newline and a semicolon). The script can also compare the backup size against a minimum threshold and alert if it’s suspiciously small.

This tool is worth building because it automates a task that is easy to skip. A cron job that runs the verifier after every backup and emails the result gives you confidence without manual effort. The script should return a non-zero exit code on failure so that your monitoring system can page you.

Tool 5: Configuration File Checker

Configuration errors are a leading cause of service outages. A config checker parses a file (JSON, YAML, or INI) and validates that required keys exist and values have the correct type. For JSON, use the built-in json module; for YAML, you would need PyYAML, so stick with JSON or INI to stay dependency-free. The script takes a schema (a simple Python dict) and reports missing keys, wrong types, and values outside allowed ranges.

For example, a web server config might require port to be an integer between 1 and 65535, and host to be a string. The checker prints a clear error message for each violation and exits with a non-zero status. This tool is especially useful in CI/CD pipelines to catch mistakes before deployment.

How to Choose Which Tools to Build First

Start with the tool that addresses your most frequent pain point. If you spend hours grepping logs, build the log tailer first. If you’ve had a disk-full incident recently, build the disk usage analyzer. The process monitor is valuable for any server that runs multiple services. The backup verifier is critical if you manage databases. The config checker is a nice-to-have if you deploy frequently.

Consider the environment where the script will run. If your servers are all Linux with Python 3.6+, you can use f-strings and pathlib. If you have older systems, stick to Python 2-compatible syntax (though that is increasingly rare). Keep each script self-contained and avoid importing any module outside the standard library unless absolutely necessary—this ensures it runs anywhere.

Common Pitfalls and How to Avoid Them

One common mistake is not handling file encoding. Logs may be in UTF-8 or Latin-1; always open files with encoding='utf-8', errors='replace' to avoid crashes on unexpected bytes. Another pitfall is using os.path.getsize() on a symlink, which gives the link size, not the target; use os.stat() with follow_symlinks=False if you want to skip links.

Resource leaks are another issue: when tailing a file, remember to close it periodically or use with blocks. For long-running monitors, add a --max-runtime option to prevent runaway processes. Finally, always test your script with a sample input that includes edge cases like empty files, missing directories, and permissions errors.

Frequently Asked Questions

Do I need to install any packages for these scripts?

No. All five tools can be built using only the Python standard library (os, sys, re, time, json, argparse, and similar). This is a deliberate choice so the scripts run on any server with Python installed, without needing pip or internet access.

Can these scripts replace monitoring tools like Nagios or Prometheus?

No. They are lightweight utilities for quick checks and ad-hoc troubleshooting. For continuous monitoring, alerting, and historical graphs, you need a dedicated monitoring system. These scripts complement such tools by providing on-demand, interactive inspection.

How do I schedule these scripts to run automatically?

Use cron on Unix-like systems or Task Scheduler on Windows. For example, to run the disk usage analyzer every hour, add a line like 0 * * * * python /path/to/disk_usage.py /var --threshold 90 to your crontab. Ensure the script logs its output to a file so you can review past runs.

What if my logs are in a non-standard format?

The log tailer can be adapted by changing the filter logic. Instead of a simple keyword, you can use a regular expression that matches your format. For structured logs (JSON), you can parse each line and filter on a specific field. The key is to keep the script generic and pass the pattern as an argument.

Are these scripts safe to run on production servers?

Yes, as long as you test them in a staging environment first and run them with appropriate permissions. They only read data (logs, directories, process info) and do not modify anything unless you add a feature to do so. Always review the code to ensure it doesn’t accidentally delete files or kill processes.

Can I combine these tools into one script?

You can, but it’s not recommended. Combining them increases complexity and makes it harder to debug. Keeping them separate allows you to run only what you need and to replace one without affecting the others. If you find yourself using two together often, you can create a wrapper script that calls both.

Related

• Best Android File Browsers: Top Picks & Guide
• GTA 5 Free PS5 Xbox Series X Upgrade for Last Gen Owners
• Load Calculator for Solar: How to Size Your System

in t | Log lines to show | lines | 50 | 0
in f | Filter keyword | - | error | 0
out n | Lines matched | lines | count | 0