4 ms·

We are building ContainIQ (https://www.containiq.com/ https://www.containiq.com/)! We provide Kubernetes native monitoring instantly with pre-built dashboards a

We are building ContainIQ (https://www.containiq.com/ 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.

sidcool 5y ago
Congrats on launching! One question about containiq though which I could not figure out with the skimming of the link. How it compares to (istio + prometheus + grafana)?
- NWMatherson 5y ago
  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.
  - sidcool 5y ago
    Thanks for the reply. Is it available to self host? Or self manage in public cloud?
    - NWMatherson 5y ago
      Currently no, not yet at least.
  - debarshri 5y ago
    Half broken setup is a people problem. Prometheus and grafana is integrations is actually pretty solid and quite simple if you follow the docs [1]. If you are out there to replace existing monitoring stack like ELK, Prometheus-grafana, victoria metrics, i think it will be an uphill battle proving your value because there is high switching cost. Also, In most of the organisations, core resources that people care about are well monitored. Just my 2 cents. [1] https://grafana.com/grafana/plugins/grafana-kubernetes-app/ https://grafana.com/grafana/plugins/grafana-kubernetes-app/
theptip 5y ago
Sounds interesting! I’m on GKE. How does this compare against Cilium and the new Dataplane V2? https://cloud.google.com/blog/products/containers-kubernetes/bringing-ebpf-and-cilium-to-google-kubernetes-engine https://cloud.google.com/blog/products/containers-kubernetes... Sounds like you have more work curating dashboards at the least. And maybe this bolts on to the standard kube-proxy dataplane so folks don’t need to change that?
- NWMatherson 5y ago
  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.
bogomipz 5y ago
Congrats on your launch. Your site was a little light on details. Could you say how your product compares to Pixie which is also Kubernetes-native and uses eBPF? https://pixielabs.ai/ https://pixielabs.ai/
- NWMatherson 5y ago
  Thanks so much! 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).
gregwebs 5y ago
How does this compare to using metadata (eBPF bases metrics).
- NWMatherson 5y ago
  Could you expand on what you mean a little? We’re a full service platform that collects, stores and visualizes the data for you.
  - gregwebs 5y ago
    Sorry got autocorrected on my phone. Netdata
orf 5y ago
Why choose Containq over Datadog?
- NWMatherson 5y ago
  Good question. - 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.
lxe 5y ago
Nice! Would be cool to see a demo dashboard without "booking a demo"
- NWMatherson 5y ago
  You are right! We are looking into launching a live demo version that users can play around with.

sidcool 5y ago

Congrats on launching! One question about containiq though which I could not figure out with the skimming of the link. How it compares to (istio + prometheus + grafana)?

NWMatherson 5y ago
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.
- sidcool 5y ago
  Thanks for the reply. Is it available to self host? Or self manage in public cloud?
  - NWMatherson 5y ago
    Currently no, not yet at least.
- debarshri 5y ago
  Half broken setup is a people problem. Prometheus and grafana is integrations is actually pretty solid and quite simple if you follow the docs [1]. If you are out there to replace existing monitoring stack like ELK, Prometheus-grafana, victoria metrics, i think it will be an uphill battle proving your value because there is high switching cost. Also, In most of the organisations, core resources that people care about are well monitored. Just my 2 cents. [1] https://grafana.com/grafana/plugins/grafana-kubernetes-app/ https://grafana.com/grafana/plugins/grafana-kubernetes-app/

theptip 5y ago

Sounds interesting! I’m on GKE. How does this compare against Cilium and the new Dataplane V2? https://cloud.google.com/blog/products/containers-kubernetes/bringing-ebpf-and-cilium-to-google-kubernetes-engine https://cloud.google.com/blog/products/containers-kubernetes... Sounds like you have more work curating dashboards at the least. And maybe this bolts on to the standard kube-proxy dataplane so folks don’t need to change that?

NWMatherson 5y ago
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.

bogomipz 5y ago

Congrats on your launch. Your site was a little light on details. Could you say how your product compares to Pixie which is also Kubernetes-native and uses eBPF? https://pixielabs.ai/ https://pixielabs.ai/

NWMatherson 5y ago
Thanks so much! 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).

gregwebs 5y ago

How does this compare to using metadata (eBPF bases metrics).

NWMatherson 5y ago
Could you expand on what you mean a little? We’re a full service platform that collects, stores and visualizes the data for you.
- gregwebs 5y ago
  Sorry got autocorrected on my phone. Netdata

orf 5y ago

Why choose Containq over Datadog?

NWMatherson 5y ago
Good question. - 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.

lxe 5y ago

Nice! Would be cool to see a demo dashboard without "booking a demo"

NWMatherson 5y ago
You are right! We are looking into launching a live demo version that users can play around with.