This looks very promising, thank you and congrats!
Also, please don't forget about people (like me) who don't run on $MAJOR_CLOUD_PROVIDER. I'd be curious to try this e.g. on self-operated Docker w/ Minio.
Hi, this is Nick Parker from the Opstrace team. I personally have my own on-prem arm64/amd64 K3s cluster, including a basic 4-node Minio deployment, so I’m very interested in getting local deployment up and running myself. We’re a small team and we’ve been focusing on getting a couple well-defined use-cases in order before adding support for running Opstrace in custom and on-prem environments. It turns into a bit of a combinatorial explosion in terms of supporting all the possibilities. But we definitely want to support deploying to custom infrastructure eventually.
This looks like an interesting product. We're figuring out our monitoring stack - but have also found Loki/Grafana - and we're looking at Victoria Metrics rather than Cortex. Our hope is that the combination will turn out to be able to scale down as well as up, and be possible to fit in with Docker swarm/compose on-prem and at digital ocean. Also looks like vector might be a good option for collecting data.
Will keep an eye out, to see if optrace might be a fit for us.
Mostly the promise that they do mostly the same, but vm uses less resources. I believe vm has slightly less resolution/fidelity - but not so much that we expect it to matter for our use-case.
But we're still implementing it - so we might still run into surprises.
Jan-Philip from Opstrace here, good morning. Would love to hear more, after all, when you know more :-). By the way, we had been asked about VictoriaMetrics before, here: https://github.com/opstrace/opstrace/discussions/98.
Good to know, and thanks for confirming. I totally get that supporting all combinations can be a real challenge. I guess containerization helps, but that's becoming it's own smorgasbord of almost-compatible bits.
Yeah, anytime I hear "on-prem" deployment I think of my previous experience with getting a product deployed across a lot of different K8s environments. At the surface there are ostensibly common APIs, but the underlying components (networking, storage) are not necessarily interchangeable. There may also be custom policies around e.g. labels, SecurityContexts, or NetworkPolicies. In my own K3s cluster I generally just manage the YAML specs for the deployments by hand, since I’ll often need to e.g. specify the arch constraint to run against, or ensure that it’s running a multi-arch image. It’s a really interesting problem though, and it’s something that we’re targeting.