Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF

#11

Post by brancz »

outgame wrote: post #6
kolanos wrote: post #5

How does this compare to Pixie? [0] [0]: https://github.com/pixie-io/pixie

Polar signals develops Parca [0] which is another eBPF observability tool, and Isovalent develops Cilium [1] which is built on eBPF as well. Genuinely curious if there are differences, or if eBPF only allows for specific observability functionality and each tool has it all. [0]: https://github.com/parca-dev/parca [1]: https://github.com/cilium/cilium

Polar Signals founder and one of the creators of Parca here. From what I can tell ContainIQ is distinct from Parca and Polar Signals as we only concern ourselves with continuous profiling, which is complementary to metrics, logs and traces. From our experience, while eBPF is certainly limited and it can be painful to work with the verifier at times, it hits a sweet spot for observability collection because of low overhead and you really only read some structs from memory somewhere for which the limitations of eBPF tend to be plentiful.

Definitely excited to see more eBPF tooling appear in the observability space.

Re: Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF

#12

Post by NWMatherson »

brancz wrote: post #11
outgame wrote: post #6

Earlier quoted context omitted.

Polar signals develops Parca [0] which is another eBPF observability tool, and Isovalent develops Cilium [1] which is built on eBPF as well. Genuinely curious if there are differences, or if eBPF only allows for specific observability functionality and each tool has it all. [0]: https://github.com/parca-dev/parca [1]: https://github.com/cilium/cilium

Polar Signals founder and one of the creators of Parca here. From what I can tell ContainIQ is distinct from Parca and Polar Signals as we only concern ourselves with continuous profiling, which is complementary to metrics, logs and traces. From our experience, while eBPF is certainly limited and it can be painful to work with the verifier at times, it hits a sweet spot for observability collection because of low ove…

Well said, we are excited to see more eBPF tooling appear as well.

Re: Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF

#13

Post by nodesocket »

Hello. I own and run a DevOps consulting company and use DataDog exclusively for clients. DD works pretty well as it integrates with cloud providers (such as AWS), physical servers (agent), and Kubernetes (helm chart). The pain point is still creating all the custom dashboards, alerts, and DataDog integrations and configuration. Managing the DataDog account can almost be a full-time job for somebody. Especially with clients who have lots of independent k8s clusters all in a single DD account (lots of filtering on tags and labels).

What does ContainIQ offer in terms of benefits over well established players like DataDog? I will say, the Traefik DataDog integration is horrible and hasn't been updated in years so that's something I wish was better. DataDog does support Kubernetes events (into the feed), and their logging offering is quite good (though very expensive).

Re: Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF

#14

Post by NWMatherson »

nodesocket wrote: post #13

Hello. I own and run a DevOps consulting company and use DataDog exclusively for clients. DD works pretty well as it integrates with cloud providers (such as AWS), physical servers (agent), and Kubernetes (helm chart). The pain point is still creating all the custom dashboards, alerts, and DataDog integrations and configuration. Managing the DataDog account can almost be a full-time job for somebody. Especially with…

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

Re: Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF

#15

Post by rlyshw »

I recently had an issue where my UDP service worked fine exposed directly as a NodePort type, but not through an nginx UDP ingress. I _think_ the issue was that the ingress controller forwarding operation was just too slow for the service's needs, but I had no way of really knowing.

Now if I had this kernel level network monitoring system, I probably could have had a clearer picture as to what is going on.

Really one of the hardest problems I've had with learning/deploying in k8s is trying to trace down the multiple levels of networking, from external TLS termination to LoadBalancers, through ingress controllers, all the way down to application-level networking, I've found more often than not the easiest path is to just get rid of those layers of complexity completely.

In the end I just exposed my server on NodePort, forwarded my NAT to it, and called it done. But it sounds like something like ContainIQ can really add to a k8s admin's toolset for troubleshooting these complex network issues. I also agree with other comments here that a limited, personal-use/community tier would be great for wider adoption and home-lab users like me :)

Re: Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF

#16

Post by nyellin »

permalac wrote: post #4
gigatexal wrote: post #2

A community edition/non-paid would be quite nice to be able to trial this out before paying. This is how an old employer adopted CockroachDB because we trialed the non-enterprise version and then ultimatley bought a license.

Agreed. Our employer does not invest on this kind of tools, so when a free version does not exist for us the tool does not exist. We would be happy to provide usage metrics and reports, our company is full open source and open data, and we work/invest time on open projects when possible.

Not the OP, but I develop a different open source tool for Kubernetes and would love to talk! (Email is in my profile)

Re: Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF

#18

Post by HatchedLake721 »

permalac wrote: post #4
gigatexal wrote: post #2

A community edition/non-paid would be quite nice to be able to trial this out before paying. This is how an old employer adopted CockroachDB because we trialed the non-enterprise version and then ultimatley bought a license.

Agreed. Our employer does not invest on this kind of tools, so when a free version does not exist for us the tool does not exist. We would be happy to provide usage metrics and reports, our company is full open source and open data, and we work/invest time on open projects when possible.

Does your company use paid versions of the open source tools or pay support?

Re: Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF

#19

Post by NWMatherson »

rlyshw wrote: post #15

I recently had an issue where my UDP service worked fine exposed directly as a NodePort type, but not through an nginx UDP ingress. I _think_ the issue was that the ingress controller forwarding operation was just too slow for the service's needs, but I had no way of really knowing. Now if I had this kernel level network monitoring system, I probably could have had a clearer picture as to what is going on. Really one…

Appreciate this insight and I agree with you.

And I can definitely circle back here when our limited use tier goes live. Agree on that too.

Post reply on HN