Why should I run this instead of renewing my Wavefront contract?
Launch HN: Opstrace (YC S19) – open-source Datadog
31–40 of 120 posts
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#32We 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.
Tip, if you happen to be using datadog, make sure datadog agent logs are disabled from being ingested into datadog. If you can disable them at the agent level and avoid the data out that would be even better. At a previous employer the defaults were quite literally half of our log volume, that we were paying for. I was doing a sanity check before renewing our datadog contract and was very not-pleased to discover that…
We’re about to release a Datadog compatible API so you can point your Datadog agent at Opstrace instead (stay tuned for the blog post). Our goal is to be able to tell you exactly how much data the agent is sending and how much that is costing you (and for example what services/containers are responsible for the bulk of the cost). Here’s a list of the PRs: https://github.com/opstrace/opstrace/pulls?q=is%3Apr+is%3Acl...
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#33Meanwhile, AWS getting the "AWS Opstrace Service" branding and marketing pages ready.
:-) I have talked about the subject in this comment thread: https://news.ycombinator.com/item?id=25991764
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#34Why should I run this instead of renewing my Wavefront contract?
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 model forms the wrong incentives. Charging by volume means a company is more incentivized to have their customers (you) send you more data, and less incentivized to help them get more value from that data. This is a fundamental change we want to bring to the market--we want our incentives to align with yours, we want to be paid for the value we bring to your company. We charge on a per-user basis. You should monitor your applications and infrastructure the right way, not afraid to send data because it might blow the budget.
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#35We 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.
Tip, if you happen to be using datadog, make sure datadog agent logs are disabled from being ingested into datadog. If you can disable them at the agent level and avoid the data out that would be even better. At a previous employer the defaults were quite literally half of our log volume, that we were paying for. I was doing a sanity check before renewing our datadog contract and was very not-pleased to discover that…
I even opened a support ticket for their stupid python agent logging its connection refused tracebacks on every metrics poll and was told "too bad"
They really don't give one whit about log discipline or allowing the user to influence the agent's log levels
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#36Earlier quoted context omitted.
Tip, if you happen to be using datadog, make sure datadog agent logs are disabled from being ingested into datadog. If you can disable them at the agent level and avoid the data out that would be even better. At a previous employer the defaults were quite literally half of our log volume, that we were paying for. I was doing a sanity check before renewing our datadog contract and was very not-pleased to discover that…
I even opened a support ticket for their stupid python agent logging its connection refused tracebacks on every metrics poll and was told "too bad" They really don't give one whit about log discipline or allowing the user to influence the agent's log levels
Perhaps on a related note, see this discussion about the power of incentives here: https://news.ycombinator.com/item?id=25994653
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#37Why should I run this instead of renewing my Wavefront contract?
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 we've screwed that up.
I can plug 100s of AWS accounts and 10s of payers into it and I don't have to think about that in terms of making self-hosted infrastructure available via PrivateLinks or some other such complication.
I pay mid six-figure sums annually for these things to "just work". If you folks believe I can achieve this functionality on a per-seat basis I'd be interested in saving those six figures.
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#38This 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…
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.
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#39Damn. That's one hell of a set of credentials for the founders.
I was the engineer who was heavily involved with monitoring at my last job and a lot of what this is doing aligns with what I would have done myself. At my new job, I work on different stuff but I can see we're going to run into monitoring issues soon too. I'm so, so, so glad this is an option because I do not want to rebuild that stuff all over again. Getting monitoring scalable and robust is HARD!
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#40Earlier quoted context omitted.
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 a…
Will you have a small(er) plan for homelabs?
I like supporting open source projects, and while SSO is pretty useless to me, I always like custom domains.