Look at Grafana Loki. They have single binary which serves many different roles. You can launch it with different flags for scalable setup, so each instance would serve a different role. Yet you can just launch one instance and it'll do it all by default. I'm using it with this approach and it works just fine for my log volume. And I have the way to scale if I would hit limits. May be it's not elegant to have multiple services in the one binary, but disk space is cheap and code does not take much amount.
> I think you're referring to the "Securing your services"[0] section right? These are all stored as env vars - perhaps that's not clear from the docs?
I'm talking about docker/volumes/logs/vector.yml. There's "api_key=your-super-secret-and-long-logflare-key" which is supposedly should be replaced by the actual logflare api key value. The guide does not instruct to change LOGFLARE_API_KEY but I guessed this key is there for a reason and should be changed.
> I'm talking about docker/volumes/logs/vector.yml
I've flagged this to the Logs team to fix immediately
> Look at Grafana Loki
I'll check it out thanks. My gut is that running Postgres + 4/5 other services (many different languages) is a harder beast than Loki, but understand the sentiment and we'll see what we can do here
thanks for flagging this. If anyone else spots things like this please feel free to open a GH issue so we can amend it asap - given enough eyeballs, all bugs are shallow
> I think you're referring to the "Securing your services"[0] section right? These are all stored as env vars - perhaps that's not clear from the docs?
I'm talking about docker/volumes/logs/vector.yml. There's "api_key=your-super-secret-and-long-logflare-key" which is supposedly should be replaced by the actual logflare api key value. The guide does not instruct to change LOGFLARE_API_KEY but I guessed this key is there for a reason and should be changed.