1. 17
  1.  

  2. 3

    Goof stuff. There’s also https://github.com/VictoriaMetrics/metrics lib that I suggest to people who want to add metrics exposition to their Go apps but don’t want to include a lot of dependencies from the official Prometheus client library.

    1. 3

      Strong -1 — everything written by that guy is sloppy and full of caveats. For example, the Histogram type in this package uses dynamic buckets, making any kind of aggregation — an average, a rate over any dimension, etc. — totally statistically invalid.

    2. 2

      I was just thinking the other day that Grafana is terrible for metric discovery. The explorer view autocompletion doesn’t work at $work because there are more than 10k series, so you need to use the stupid drop down. Which is very ergonomic with over 10k series. Why just just add a search? Also the lack of ability to create graph labels in that view sucks. I’ll definitely check this out.

      1. 2

        This is great!

        While I completely understand the sentiment of having that one tool that everyone uses and knows about I think that it comes at the prices of approaching problems in fewer ways, maybe from a technological point of view missing out. I don’t think that’s the case for Prometheus, but sometimes this also makes APIs specific to single client implementations.

        Having more than one option and therefor also more than one interest group can be very beneficial, so I really appreciate this project.

        That’s not to say that creating many Grafana clones is the right approach, but having some alternatives is certainly a good thing. Also this very much doesn’t seem to be a clone, as mentioned in the Readme.

        Really nice. I think this could also be very useful for projects that measures things that aren’t your server instances, but to be used in single instance applications, like SoCi projects, where one simply wants to visualize some time series, without user management, etc. I also really like the straight-forward minimalism on the server side.

        Just one nitpick, maybe it would make sense to specify the protocol as part of the source instead of enforcing HTTPS?

        1. 1

          Thank you, I’m glad you find this useful!

          I do like having more options, and I was pleasantly surprised that it is possible to implement these kinds of different frontends for complex projects with relative ease. There’s a definitive tradeoff with this project (being more lightweight and quicker to write a new board vs being feature complete and easier to use), but I think that’s a neat thing to exist.

          In that vein, we also wrote an alternative frontend to ElasticSearch with similar tradeoffs and design ideas in mind.

          Just one nitpick, maybe it would make sense to specify the protocol as part of the source instead of enforcing HTTPS?

          Good point! I created an issue to at least default to the protocol the frontend is using.

          1. 2

            relative ease

            And that it’s possible to write them in modern, plain Javascript. No need for ES6 compilers or too insane browserhacks.

        2. 2

          This is pretty cool! I’m building a similar tool as a desktop application, though it’s nowhere near as mature. My use-case is mostly around exploration as well, but I wanted to be able to do that outside of my browser. Perhaps there’s opportunity to collaborate?

          My project lives here: https://github.com/whereswaldon/binnacle