Why a Counters Library?

Back to the Past

In 2022 (just around the corner), it might seem strange that we are still discussing how to design a better Counters library, especially considering we developed the first Metrics API, OpenCore, for the Java platform ten years ago. Why are we still talking about this? Unfortunately, OpenCore was a little bit ahead of its time, offering not just metrics but activity-based resource metering and many other observability instruments and models all under one roof.

With the Humainary initiative (OpenCore 2.0 for Observability, you could say), we are not just unifying instruments under a single umbrella project but rebuilding an observability library toolkit from the ground up with meaningfulness, micronization, and modularity present in all aspects of the design, documentation, development, delivery, and deployment of instruments.

Design Mistakes

Here are some of the items we consider as problematic with today’s open-source offerings in the observability space:
#1 Having to decide which numeric data type to use? Double? Long? Integer? Prometheus has a lot to answer for.
#2 Looking up a Counter using a simple string or multiple string arguments. Let’s then throw in tags, labels, etc.
#3 Needing to consider name collisions across different metric types maintained by a single registry.
#4 Counters that can be reset. Counters that go up and down (like a Gauge). We’re still confused by this.
#5 Counters that don’t count but are a measure of a counter managed elsewhere. Naming is still an engineering challenge.
#6 Counter builders in (Java) code. Who would have thought counter creation is so complex and now so cumbersome?
#7 Having the developer decide between Counter or Histogram. Library designers should not push decisions to the surface.
#8 A complete discard for the most salient aspect of a Counter – delta/change. Change is hard when fixed to the past.
#9 Counter instruments that could be replaced by a numeric data type. The dumber the instrument, the fatter the data pipelines.
#10 Confusing method names, such as add which might not increment. Apparently, inc was a bit too long a name to use.