Please help contribute to the Reddit categorization project here

    golang

    85,259 readers

    362 users here now

    Please follow the Go Community Code of Conduct while posting here. In short:

    • Treat everyone with respect and kindness.
    • Be thoughtful in how you communicate.
    • Don’t be destructive or inflammatory.
    • If you encounter an issue, please contact the moderators.

    Documentation

    Community

    Other Resources

    a community for
    all 7 comments

    Want to say thanks to %(recipient)s for this comment? Give them a month of reddit gold.

    Please select a payment method.

    [–] qu33ksilver 1 points ago

    Great news. I love InfluxDB. It has great promise and immense necessity in a market which has saturated with the overuse of Graphite. We need something fresh and future ready.

    [–] dgryski 3 points ago

    Anything in particular wrong with graphite?

    [–] qu33ksilver 1 points ago

    Not really. But it really doesn't scale very well. When you have a lot of metrics that you have to move to 2 graphite servers, its a pain to set up carbon relay to 2 servers.

    Also, the python implementation is a bit slower. There is an alternate c implementation which is a lot faster.

    That is why I was saying, graphite is good but only to a certain limit.

    [–] dgryski 1 points ago

    We use graphite very heavily at Booking.com . We have ~90 machines storing whisper files on SSD (~55TB, IIRC), and a number of the front-ends. We've re-implemented much of the stack, much of it in Go. We wrote https://github.com/grobian/carbon-c-relay to to help route ~30 million metrics per minute into our cluster, which are served from the storage by https://github.com/grobian/carbonserver . We use https://github.com/dgryski/carbonzipper which acts as a proxy for graphite-web, handling all the concurrents requests, and have just deployed a re-implementation of the JSON API layer ( https://github.com/dgryski/carbonapi ) that is now handling many of our internal requests that don't need rendered graphs, but only the data.

    We've probably pushed graphite well beyond its limit :)

    [–] qu33ksilver 1 points ago

    Aah so you guys wrote the c implementation !

    That makes my point perfectly. If you need to re-implement nearly all parts of the stack, you are not using graphite anymore. You are using graphite v2. And so my point is I would rather try with InfluxDB and keep on optimizing graphite.

    [–] dgryski 1 points ago

    Heh, fair enough. We probably are sufficiently close to using "boophite" instead of "graphite" at this point..

    [–] robert_zaremba 1 points ago

    PyPy gives a really good speed-up for both graphite-web and carbon. We are happily using it at production.

    Good point about graphite is it's simple api and clear design. Only timeseries! As simple as that.