The dashboard configuration issue was actually one of the pain points we targeted initially. It was an issue we experienced too. And we talked to a lot of our friends who had spent significant time setting these dashboards up in Datadog. One of our initial goals has been to try to automate to get you 95% of the way there without any configuration on your end. We've also tried to make alerting really easy and are working to automate the process of setting smart alerts. Would love to chat more about your experience if you are open to it. My email is nate (at) containiq (dot) com
OpsTrace took an interesting approach (and was a YC company too, recently acquired by GitLab). We are a managed solution, whereas OpsTrace was a self hosted open source solution. And we are not building on top of other open source tools. With ContainIQ, you can get metrics natively and other features that you wouldn't otherwise be able to get (ex p95 latency by endpoint) with OpsTrace and its integrations.
Pixie is definitely similar in their eBPF based approach. I believe there are differences in the types of data they collect and correlate with. For example we collect logs and state information (node status, node conditions, pod scheduled ect) along side our eBPF based metrics like latency. I'm sure there are things they collect that we don’t as well.
I agree. We are planning to launch a free edition with limited size and data retention. For users to try / play with before paying. It is in the works and we hope to have this out in the next few months.
The initial version of ContainIQ is in a similar space to what pixie has built, but our eventual vision has a few differentiators. I believe Pixie was built using BCC (an assumption based on the 2GB requirement and their BPF trace tooling) which requires llvm and the kernel headers to be installed on every node. This ends up requiring a lot of ephemeral storage. Since Kubernetes is most commonly used for stateless applications this ends up being a problem, because the default node storage allocatable is relatively low. We’re in the process of migrating out from BCC to libbpf which should alleviate a lot of the issues associated with the larger storage/memory footprint of BCC. We also have a few unique features in the pipeline that I believe are unique to our product (EX: P95, P99 http latency by microservice endpoint).
- ContainIQ just works. Comes pre-configured and you don't need a degree from DD University to know how to use it.
- We are only focused on K8s.
- We have differentiated features, easier setup and we take less time to maintain (ex our latency features like service latency and latency by URL path don't need to be instrumented on each application)
- transparent pricing. We are a flat rate of $250 per month up to 50 / nodes. You don't have to worry about insane bill spikes.
Cilium has traditionally focused more on the security and performance side of Kubernetes networking. Cilium’s Hubble product more closely aligns with what we are trying to achieve, but with ContainIQ we simplify visualization, setup and host the data for you. Hubble currently sends the data to Prometheus, but we wanted to remove the headache of managing your own monitoring platform.
Exactly we bolt on to the standard kube-proxy setup. We put a lot of effort into ensuring that everything works right out the box.
Thanks for reading! Our goal was to create an out of the box solution that didn't require on-going maintenance. Another goal was to make something that all engineers on the team would know how to use.
The amount of 1/2 broken prometheus/grafana setups we see is crazy.
From a feature perspective there is some overlap (ex pod/node CPU and memory). But we have features that you can't get from the solutions you mentioned (ex service latency, latency by URL path (coming soon!). And have a lot more in the roadmap too. :)
We are also housing and managing the data for our users.
We are building ContainIQ (https://www.containiq.com/)! We provide Kubernetes native monitoring instantly with pre-built dashboards and easy to create monitors. A one-line install that takes 5 minutes to set up and it just works. By using eBPF we’re able to correlate kernel-level metrics with Kubernetes objects. Our current users are using our product to track and get alerted on things like p95/p99 latencies, Kubernetes jobs failing, pod evictions, among other things.