71–80 of 120 posts
Man, I was hoping someone would do this. Thanks very much. Please please please, care about the design. I don't know why open source projects always have bad design. Wish you all the best. and Congratulations!
Thank you! Yes, design is very near and dear to our hearts! If you’re interested in giving me some early feedback on our UX, email me mat@opstrace.com.
hi! Some quick perspective - my thoughts looking into this are "ok cool what metrics do i get for free? cpu load? disk usage? the hard to find memory usage?" and i just get lost in your home page without any examples of what the dashboard looks like
We totally agree our website is way too wordy and we are working on explaining our vision through various ways. Screenshots of course, but also things like short videos. We actually just did one of our quickstart https://youtu.be/XkVxYaHsDyY . It’s not perfect but we will get there:-) Thanks for the feedback, we appreciate it!
It's from this page: https://opstrace.com/docs/quickstart
Earlier quoted context omitted.
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…
Curious to learn more about the tradeoffs you’ve found between Cortex and Victoria Metrics and why you could be drawn to one more than the other?
But we're still implementing it - so we might still run into surprises.
Earlier quoted context omitted.
Curious to learn more about the tradeoffs you’ve found between Cortex and Victoria Metrics and why you could be drawn to one more than the other?
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.
Earlier quoted context omitted.
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…
Happy to hear you're now with the old Mesosphere gang at Opstrace Nick!
We use [insert very large application performance monitoring tool here] for workloads running in [insert very, very large cloud provider here] and after examining our deployments, concluded that we were spending nearly $13k/mo for data transfer out expenditures because the monitoring agents have crazy aggressive defaults. Seems like running our own (which may be worthwhile) would alleviate anything like that.
Earlier quoted context omitted.
Wavefront brings a number of things to the table that aren't core competencies we wish to maintain in-house. I know it can scale to massive volumes without interaction from us. I know it'll be available when our infrastructure isn't. By being a third party we can be confident that any action on our part (such as rolling an SCP out to an AWS org, despite unit tests) won't impact the observability we rely on to tell us…
We’re building Opstrace to be as simple as a provider like Wavefront -- we’ve failed if you need additional competencies to manage it. That being said, we’re early in our journey and still have a ways to go. As mentioned in the original post here, at the core of Opstrace is Cortex ( https://cortexproject.io ). We know that Cortex scales well to hundreds of millions of unique active metrics, so depending on the exact…
In a nutshell, running all these various components (Grafana, etc) is a royal pain in the neck. Even if `opstrace create` spawns them easily, the problem is running/maintaining them. We want someone to run these for us as a SaaS/PaaS and we're happy to pay them.
Re: your principles:
(1) The customer should always own their data --> we agree. However, we are happy for you to be a custodian of that data.
(2) We don’t want to be a storage vendor --> neither do we. We want storage to be someone else's problem. We're happy for you to use a cloud platform like AWS/GCP and charge us a 50% markup.
(3/4) Transparency, predictability of costs, open source --> all excellent.
Earlier quoted context omitted.
It's hard to answer that concretely without knowing a little bit more about your use cases. Care to share a bit more? One thing comes to mind: we don't bill by data volume. Wavefront is charging you for the volume of data your applications produce. This can lead to negative outcomes, such as surprise bills from a newly deployed service and a subsequent scramble to find and limit the offenders. We think this pricing m…
Wavefront brings a number of things to the table that aren't core competencies we wish to maintain in-house. I know it can scale to massive volumes without interaction from us. I know it'll be available when our infrastructure isn't. By being a third party we can be confident that any action on our part (such as rolling an SCP out to an AWS org, despite unit tests) won't impact the observability we rely on to tell us…
Thanks for sharing this perspective, stressing the relative value of predictability.
Of course, when things go pear-shaped the last thing you want to discover is that your monitoring pipeline doesn't work as expected. We feel you.
Your skepticism is justified and I'm super happy to see that here. We know that our future users are (and should be) quite demanding with respect to robustness of the platform.
We're not naively assuming that it's easy to build a platform that is highly available, auto-scaling, and generally worry-free.
In fact, based on our experience, we really know that we'll have to invest an incredible amount of engineering effort in order to make things super reliable and predictable. On the other hand, by making some smart decisions we can get far with little effort. We have super strong building blocks that we can rely on (such as using a cloud-provided database for storing critical configuration state).
> If you folks believe I can achieve this functionality on a per-seat basis I'd be interested in saving those six figures.
The bet is on, but of course we need a bit of time :)
Earlier quoted context omitted.
We’re building Opstrace to be as simple as a provider like Wavefront -- we’ve failed if you need additional competencies to manage it. That being said, we’re early in our journey and still have a ways to go. As mentioned in the original post here, at the core of Opstrace is Cortex ( https://cortexproject.io ). We know that Cortex scales well to hundreds of millions of unique active metrics, so depending on the exact…
As a heads up, I think you meant to link https://cortexmetrics.io/