FWIW, I was able to play with a preview and found it straightforward to set up and it kinda just did what I expected. I'm happy to see them taking next steps here. Good luck opstrace!
Launch HN: Opstrace (YC S19) – open-source Datadog
21–30 of 120 posts
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#22We 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.
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#23We 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.
Yes that is frustrating indeed. On top of paying your external vendor, you are punished by the egress cost you have to pay to your infrastructure cloud provider. This is one of the problems we wanted to solve. Feel free to contact me seb@opstrace.com.
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#24Earlier 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…
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.
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#25This looks super cool!
We just moved away from Datadog because their log storage pricing is too high for us. We moved to BigQuery instead. But the interface kind of sucks.
Would love to get this up and running. A couple of questions:
1. Is it possible to setup outside of AWS/GCP? I would like to set this up on a dedicated server.
2. If not - then do you have a pricing comparison page where you give some example figures? e.g. to ingest 1 billion log lines from Apache per month it will cost you roughly $X in AWS hosting fees and $Y per seat to use Opstrace
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#26hi! 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
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#27We 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.
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#28This looks super cool! We just moved away from Datadog because their log storage pricing is too high for us. We moved to BigQuery instead. But the interface kind of sucks. Would love to get this up and running. A couple of questions: 1. Is it possible to setup outside of AWS/GCP? I would like to set this up on a dedicated server. 2. If not - then do you have a pricing comparison page where you give some example figur…
Currently you can only deploy to AWS and GCP, but we do intend to extend support to on-prem/dedicated servers in due course (see https://news.ycombinator.com/item?id=25992237). Until now we’ve been focussing completely on building a scalable, reliable product by standing on the shoulders of these cloud providers where we can take advantage of services like S3, RDS, and elastic compute.
We've done a deep dive into the cost model for metrics and posted more about it here: https://opstrace.com/blog/pulling-cost-curtain-back. We are still working on a full cost analysis for logs - I'd be happy to send it to you once we have it (feel free to email me mat@opstrace.com to chat about your use case). Our goal is to be super transparent (see https://news.ycombinator.com/item?id=25992081) with cost and to have a page on our website that helps someone determine what to expect (probably some sort of calculator with live data). Our UI will also show you exactly what your system is currently costing you with some breakdown for teams or services so you know who/what is driving your monitoring cost. We're doing user testing on our to-be-released UI now and would love to have people like yourself give us early feedback (since you mentioned the BigQuery interface).
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#29hi! 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!
Re: Launch HN: Opstrace (YC S19) – open-source Datadog
#30hi! 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
Just to answer the question about what metrics are included, you can write and read any kind of custom metrics and log data from your applications, and have to build useful dashboards yourself. When first deployed, the user tenants (you can create any number of tenants to partition your data) are empty (you start with a clean slate) and ready for you to send any metrics/logs to it. You also have to add your own dashboards to interpret the data you've sent.
Opstrace does ship with a "system" tenant designed for monitoring the Opstrace system itself. This tenant has built-in dashboards that we've designed to show you the health of the Opstrace system.
Incidentally, having sharable "dashboards" across people/teams/organizations is something we are also working on, so people don't have to re-invent dashboards all the time.
We also have some guidelines for you to ingest metrics from Kubernetes clusters (https://opstrace.com/docs/guides/user/instrumenting-a-k8s-cl...) and are building native cloud metrics collection. Feel free to follow along in GitHub: https://github.com/opstrace/opstrace/issues/310.