Still a little spiky.
That was my review of a new monitoring graph I sent to the team.
I was watching errors from one of the application logs. The earlier view was hard to read. This version used a smaller sample and looked more reasonable to me, although reasonable was not the same thing as finished.
Each point on the graph came from the most recent chunk of the log. The script pulled the timestamps from the first and last entries, measured how much time had passed, and turned the sample into an errors-per-minute rate.
The sample was the last 1,000 entries. That made the graph react to what the application was doing now instead of dragging a much larger history behind it.
I had started by pulling over an old Nagios log-check script and hacking on it. Halfway through, I tried the sampling approach instead. The script itself was tiny. Read the tail of the log. Pull the times. Calculate the rate. Print one number for the monitoring system.
For fun, I also tried to write a user story for it. That was not normal language for a shell script, but it forced the point: the graph needed to make a problem easier to see while we were watching it.
The smaller data set looked better to me. I thought it would be easier to detect an issue as it happened. I did not call it done.
I sent the graph, the calculation, and the little script to two teammates and asked what they thought.
The graph looked better, but I was not calling it finished. I wanted two other sets of eyes on it before I trusted the change. My conclusion stayed exactly where it started.
Still a little spiky.