If you had asked me a few years ago, I too, would have easily assumed that systems couldn’t “lie” when reporting metrics or counters. The most difficult part of getting information was usually the process of collecting it. Whether that data was accurate never seemed to be a doubt. Like many reflections, it’s easy to look back and see how incorrect a view really was. Systems don’t always tell the truth and it’s not their fault.
One of the primary focuses of Ayetier is to provide high quality metrics & counters. We found out early on that simply passing on what a system reported for a given metric was problematic. For example, systems often reset their counters after a certain threshold – let’s use 100 for our example.
A IO counter tracks IO requests for a system. The counter resets at 100. To track IO, we take the difference in the counter at time2 from time1.
At t1, IO = 30. Next collection (10secs later: t2), IO = 80. For the period, t2-t1, the system did 50 IO.
Seems straightforward. The issue could come on the next collection. If we collect again (t3), and IO = 10, then t3 – t2 = -70 IO. There’s no way the system performed a -70 IO.
Often, there’s no documentation when a counter will reset, or that a counter did reset. Logic is crucial in handling these cases. Additionally, as counters are aggregated and trends are calculated, incorrect entries can result in wildly skewed data.
Ayetier’s goal is to provide our customers with high quality access to system metrics and counters. Because metric and counter collection itself can impact systems, minimizing the amount of collectors is critical for System Administrators. Ayetier also offers multiple methods for consuming metrics beyond our application – platforms like InfluxDB, Grafana, etc. to make sure that data is available when, and where, it’s needed.
If you’re interested in learning more about Ayetier and how we’re making storage data more manageable and providing high quality access to system metrics, schedule a quick call with one of our engineers.