81–90 of 120 posts
> opstrace destroy PROVIDER CLUSTER_NAME
> opstrace list PROVIDER
I want to keep cluster config in source control, track deployment changes in code reviews, and automate deployments. Do you have any plans to add an 'apply' command to support this?
$ opstrace apply -c CONFIG_FILE_PATH [--dry-run] PROVIDER CLUSTER_NAME
Hi there, at TableCheck (www.tablecheck.com) we recently adopted Lightstep. 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.…
> is a royal pain in the neck.
It's fun to see how different people put the same unpleasant experience into words in this thread. Thanks for adding your personal touch. Every time we hear something like that, we're re-assured that we're on the right track.
> Even if `opstrace create` spawns them easily, the problem is running/maintaining them
Yes. You're right. While we can be proud of our setup/installation process already, we know that there's so much more to it. We don't underestimate that. Maybe also see https://news.ycombinator.com/item?id=25998587, where I just commented on the robustness topic.
> However, we are happy for you to be a custodian of that data.
Great.
> We want storage to be someone else's problem.
I share that perspective. We, of course, are happy to let S3/GCS do the actual job.
> We're happy for you to use a cloud platform like AWS/GCP and charge us a 50% markup.
That's great to hear, and I hope you can be enthusiastic about the fact that our markup is _not_ going to be relative to storage volume. It's going to be independent of that.
> Transparency, predictability of costs, open source --> all excellent.
Thanks for sharing. That's incredibly motivating.
Keep an eye on us, and we'd love to hear from you!
> opstrace create -c CONFIG_FILE_PATH PROVIDER CLUSTER_NAME > opstrace destroy PROVIDER CLUSTER_NAME > opstrace list PROVIDER I want to keep cluster config in source control, track deployment changes in code reviews, and automate deployments. Do you have any plans to add an 'apply' command to support this? $ opstrace apply -c CONFIG_FILE_PATH [--dry-run] PROVIDER CLUSTER_NAME
An `apply` command might look innocent on the surface. But. Upgrades (including config changes) are hard. Super hard. If it's helping a bit: the entire current Opstrace team has dealt with super challenging platform upgrade scenarios in the most demanding customer environments in the past years. We try to not underestimate this challenge :).
We're super fast moving right now and didn't want to bother with in-place config changes (as you can imagine, we wouldn't really be able to provide solid guarantees around that). We'll work on that and make it nice when the time is right, and when we feel like we can can actually provide guarantees.
Nicely designed site, great logo, but after clicking around a bit (and looking at GitHub) I’m confused by what this product actually is. DataDog has a UI. Does Opstrace? Or is it just a CLI/API based tool? If you actually have a UI element to your product you’re doing a huge disservice to yourself by not actually showing this anywhere... EDIT: I don’t mean to sound negative, I’m wondering if positioning this against…
The headline feels deliberately clickbait-y and disingenuous. I love and support the idea. Aspirationally, the founders may want to compete with Datadog, but OpsTrace overlaps some small percentage of Datadog’s feature set. I’m surprised the mods haven’t edited this title. Source: I’m an engineer that’s used, operated and hacked on a medium-sized prom+grafana; and used Datadog at a large, multi-region, global scale.
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.
It feels like the large monitoring applications should run aggregators in large cloud providers to reduce traffic for everyone.
More broadly, how are you contributing to the upstream projects?
[1] https://github.com/grafana/loki/issues?page=7&q=is%3Aissue+i...
You mentioned Loki in your post. I evaluated it for our company and was reasonably impressed with the simplicity of setup and efficient storage. Where it failed us was the difficulty searching by customer identifiers or other "high cardinality" labels, or full-text. There's a longstanding issue [1] on the Github for this. Are you doing anything to improve log search versus an Elasticsearch cluster, for instance? More…
> Are you doing anything to improve log search versus an Elasticsearch cluster, for instance?
No. You're right, Loki is not designed for building up an index for full-text search. The premise here is that you won't typically need that and that in exchange for not having to build up that index, you get other advantages (such as being able to rely on an object store for both payload and index data!). If, on the other hand, in special situations, you need to "grep-search" your logs, this is absolutely doable with Loki! Loki does not neglect this use case. The opposite is true; everyone is already excited about the performance characteristics that Loki already has today when it comes to ad-hoc processing full text. For example, see https://twitter.com/Kuqd/status/1336722211604996098 and definitely have a look at https://grafana.com/blog/2020/12/08/how-to-create-fast-queri.... I'm sure Cyril is happy to answer your questions, too!
> how are you contributing to the upstream projects?
We're reporting issues and try to contribute as much as we can! Of course, this effort has only started. So far, we've contributed to Loki's Fluentd plugin (https://github.com/grafana/loki/pulls?q=is%3Apr+author%3Ajge...), and our testing efforts have helped reveal edge cases; see for example https://github.com/grafana/loki/issues/2124 and https://github.com/grafana/loki/issues/3085.
We're excited to substantially contribute to both Loki and Cortex in the future!
Hi there, at TableCheck (www.tablecheck.com) we recently adopted Lightstep. 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.…
Jan-Philip from Opstrace here. This is lovely feedback! > is a royal pain in the neck. It's fun to see how different people put the same unpleasant experience into words in this thread. Thanks for adding your personal touch. Every time we hear something like that, we're re-assured that we're on the right track. > Even if `opstrace create` spawns them easily, the problem is running/maintaining them Yes. You're right.…
Earlier quoted context omitted.
Jan-Philip from Opstrace here. This is lovely feedback! > is a royal pain in the neck. It's fun to see how different people put the same unpleasant experience into words in this thread. Thanks for adding your personal touch. Every time we hear something like that, we're re-assured that we're on the right track. > Even if `opstrace create` spawns them easily, the problem is running/maintaining them Yes. You're right.…
This is an interesting perspective. Our current monitoring system charges by the amount of data ingested / stored so there is a perverse incentive to observe less men if we have detailed debug level logs available.
Why should someone choose Opstrace over purchasing from them directly?