Standardise prometheus metrics #1177
Conversation
…ite /proc entries
|
Why are we using |
|
Because |
|
I think at this point all the globals should be wrapped up into an actual class or split out into a separate module (or both) |
| with open("/proc/self/stat") as s: | ||
| line = s.read() | ||
| # line is PID (command) more stats go here ... | ||
| stats = line.split(") ", 1)[1].split(" ") |
There was a problem hiding this comment.
Can we parse the stats here, rather than requiring the users of stat to know the magic numbers?
Yes, perhaps I'll pull the lot out into a separate |
|
Depends on the size really, if it gets a bit big then moving to a separate file would probably be sensible, but if it small then leaving it there is probably fine. |
|
Actually turned out that moving it into a new file was easier/neater than into a separate class within the same file. |
|
Three Jenkins failures appear unrelated. A single flakey test looks like: |
|
LGTM |
When I originally wrote the process-wide metric collection, I wasn't aware that there are standard names and semantics for the set of metrics you're supposed to export. Namely:
https://prometheus.io/docs/instrumenting/writing_clientlibs/#standard-and-runtime-collectors
This PR attempts to address this by:
process_cpu_*_seconds_total,process_open_fds)process_*_memory_bytes,process_start_time_seconds,process_max_fds)The intention is that once there's about a week of data in the new format logged by prometheus, I'll update grafana graphs to use those standard metric names instead, then make another commit to remove the "old" variable names.