Live data from Hacker News

Launch HN: Opstrace (YC S19) – open-source Datadog

news.ycombinator.com

11–20 of 120 posts

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#13

1. It would be great if you can integrate with https://vector.dev/ . Also saves you the effort of integrating with many sources 2. When opstrace is setup in AWS/GCP, what is the typical fixed cost?

Great questions!

(1) As it stands today, you can already use https://vector.dev/docs/reference/sinks/prometheus_remote_wr... to write metrics directly to our Prometheus API. You can also use https://vector.dev/docs/reference/sinks/loki/ to send your logs to our Loki API. Vector is very cool in our opinion and we’d love to see if there is more we can do with it. What are your thoughts?

(2) As for cost, our super early experiments (https://opstrace.com/blog/pulling-cost-curtain-back) indicate that ingesting 1M active series with 18-month retention is less than $30 per day. It is a very important topic and we've already spent quite a bit of time on exploring this. Our goal is to be super transparent (something you don’t get with SaaS vendors like Datadog) by adding a system cost tab in the UI. Clearly, the cost depends on the specific configuration and use case, i.e. on parameters such as load profile, redundancy, and retention. A credible general answer would come in the shape of some kind of formula, involving some of these parameters -- and empirically derived from real-world observations (testing, testing, testing!). For now, it's fair to say that we're in the observation phase -- from here, we'll certainly do many optimizations specifically towards reducing cost, and we'll also focus on providing good recommendations (because as we all know cost is just one dimension in a trade-off space). We're definitely excited about the idea of providing users useful, direct insight into the cost (say, daily cost) of their specific, current Opstrace setup (observation is key!). We've talked a lot about "total cost of ownership" (TCO) in the team.

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#14
post #4

Very exciting! Question: your homepage says it’ll always be Apache 2 but what will you do if someone like AWS rebrands your work (looking over at Elastic here)?

Mat here (Seb's Cofounder). Great question. We are not only building a piece of infrastructure but a complete product with its own UI and features, rather than a standalone API. Our customer is the end-user more than the person wanting to build on top of it. GitLab and others have shown that when you do that the probability of being forked or just resold goes down drastically.

Gitlab is open-core, so that gives them a lot of closed source features to sell. Do you plan to be open-core like Gitlab?

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#15

Your mascot is almost exactly identical to https://scylladb.com/ 's mascot. Is there any connection; or a happy accident?

Chris here, from the Opstrace team. As it turns out, it’s just a happy coincidence. When we discovered theirs we fell in love with it as well. They have many different versions of their monster (https://www.scylladb.com/media-kit/)... similarly you’ll see several new versions of our mascot, Tracy the Octopus, over time!

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#16

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.

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#17
Hey, I think this might be the coolest product intro I've read.

My two points - right now docs are clearly targeting users familiar with the competition but for someone like me who does not know similar products, a 'how it works' section with examples would be awesome.

Fingers crossed!

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#18
post #16

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…

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.

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#19

Hey, I think this might be the coolest product intro I've read. My two points - right now docs are clearly targeting users familiar with the competition but for someone like me who does not know similar products, a 'how it works' section with examples would be awesome. Fingers crossed!

Jan-Philip here, from the Opstrace team. Thanks for these kind words! For sure, you’re right, we can do a much better job at describing how things work. Providing great documentation is one of our top priorities :-)!

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#20

Earlier quoted context omitted.

Mat here (Seb's Cofounder). Great question. We are not only building a piece of infrastructure but a complete product with its own UI and features, rather than a standalone API. Our customer is the end-user more than the person wanting to build on top of it. GitLab and others have shown that when you do that the probability of being forked or just resold goes down drastically.

Gitlab is open-core, so that gives them a lot of closed source features to sell. Do you plan to be open-core like Gitlab?

Yes! We will be having features that you have to pay a subscription for. It starts with the usual suspects: custom SSO, custom domains, and authorization - things that we would be hosting as an ongoing service for customers. Most features will be open when we create them -- this is near and dear to our hearts -- it’s important our users can be successful with the OSS version. Over time, the commercial features will also flow into the open as we release new proprietary ones. Our commercial features will be public in our repo, under a commercial license.

We will also have a managed version where we deploy and maintain it for the customer in a cloud account they provide us.

Post reply on HN