Follow-up to my earlier post on Prometheus + Multiprocess Apps ...

 

A few days in, I noticed the metrics directory was ballooning in memory 🎈

 

Digging in, I realized the Prometheus Python client (in multiprocess mode) writes separate files per metric per process. By default, those files are named things like counter_12345.db, where 12345 is the PID.

 

So when a uWSGI worker dies and gets replaced — totally normal behavior — the new process gets its own set of metric files. But the old files? They just stay there.

 

Since the client doesn’t automatically clean up stale files, the directory just keeps growing.

 

✅ Fix: I configured a cleanup step to remove metrics for dead processes.

 

💡 Takeaway: In multiprocess mode, the metrics client tracks data per PID. Without cleanup, these files accumulate and quietly consume memory — especially in environments with frequent process restarts.

Today I learned how much I enjoy using uv scripts for quick, one-off tasks.

 

You can define dependencies right at the top of the script, and when you run it with uv, it spins up a temporary virtual environment automatically. Once the script finishes, the environment is destroyed — super clean 🧹

 

This is perfect for things like initial tasks when starting a container, or scripts that import data, run a migration, or do any kind of setup that isn't needed once the main app is running.

 

💡 Takeaway: uv scripts give you a disposable, isolated environment without any manual setup — ideal for clean, repeatable scripting without leaving a mess behind.

I recently deployed an API using uWSGI with multiple workers. I exposed a /metrics endpoint for Prometheus scraping — all looked good.

 

Until I realized… the metrics were off 🫠

 

Turns out, when you're using multiple uWSGI workers, Prometheus' Python client needs multiprocess mode enabled to aggregate metrics across all worker processes. Without it, each process exposes its own separate metrics — so counters, for example, appear to jump up and down instead of increasing cumulatively across all workers.

 

✅ Fix: Configured multiprocess mode, so all workers write metrics to a shared directory.

 

💡 Takeaway: With multiple workers per replica, Prometheus scrapes the /metrics endpoint from only one worker per replica at random — so without multiprocess mode, your Prometheus metrics won't reflect the true state of your API — making it impossible to accurately track what's really happening.