Show HN: Kerno.io – Developer-first monitoring that makes sense
kerno.ioHey HN!
Anibal, Sean, Vlad, Maxi and Karim here we're the co-founders of Kerno (https://www.kerno.io/).
We're building a zero-hassle tool to help developers monitor and troubleshoot their services in a way that makes sense. No complex rollouts, no custom infra, no tons of instrumentation, no sidecars… none of that! Just a minimum effort, out-of-the box, highly contextualized and interactive experience so you and your team can focus on shipping!
We basically scan your cluster resources, build usable abstractions on top of all the kubernetes craziness, identify monitor your service interactions and backtrace errors on demand to understand end-user impact and prioritise what to work on. We plug into your code versioning and CI to know who is who and who is working on what to give you back the time wasted in figuring that out (and we know that can take a while sometimes!).
We then ping who we think might have introduced the issue, who “owns” those systems, and who owns the systems being impacted by them. You get this through a desktop app in real-time and are quickly taken to a fully contextualized and correlated event and telemetry data down to the potential problematic lines of code.
As our platform gets smarter -and we need you for this!-, Kerno aims to bring to near-zero the time to figure out not only what’s happening in any given service, but who should be brought into the loop and what, who and how is it impacting your overall service.
Now, let’s talk about tech a bit
> Zero code instrumentation. Our agent runs as a DaemonSet leveraging eBPF.
> Hassle-free and almost instant. Deployments in sizable clusters take as little as 30 seconds. Two commands tops (no worries, scripts, and Helm charts are published on GitHub if you want to have a look, of course)
> As light as it can get. We are talking as little as 0.125 CPU and 64MiB per node depending on your nodes’ size! (currently running at < 5% CPU in our highly-stressed test environments).
> Low overhead, all across. We are minimalistic with data. We collect, process, and transmit data based on events of interest (from an error being detected to a user requesting N samples). We only transmit and store data in our cloud to provide a top user experience (it’s a hybrid approach).
> No billing surprises. Since we don’t base our business on charging for data ingestion and storage, pricing is quite predictable, allowing us to offer you flat pricing for the service. We price the service by unique workload, ignoring replication and associated resources (like configmaps or network services).
> Data is secure at all times. We capture and manage trace storage encrypted in your cluster. Relevant logs are transmitted to the user on-request through a blind encrypted tunnel to facilitate access to all features.
A few current limitations:
> We only officially support EKS & GKE for now, but we are working on support for other managed Kubernetes services and AWS ECS.
> TLS support is currently limited to common gateways (like Nginx). If you are using TLS or HTTP/2 for intra-cluster comms, no problem, we are getting there real soon!
> GitHub and GH actions bound for now, but we are working hard towards supporting other large Git and CI services!
So… that’s it for now.
We are really happy to put Kerno out there! And look very much forward to hearing from you all! Please let us know your thoughts and questions in the comments. > backtrace errors on demand to understand end-user impact and prioritise what to work on So you can work out what the issues on my deployment are, and then prioritize them? How does that work? Instead of capturing traces all of the time which has a CPU, memory and storage overhead that can be quite brutal, we "backtrace" errors. Think of it as following an exception bubbling-up a program execution stack... but through the network. That is then correlated to the services impacted all the way to your public API's. We are working on the PoC's for async processes too! (queues, pubsubs, fanouts, streams); and session/user-level impact metrics, coming out real soon! :) By the way... this will also be used to build better context in our discovery / knowledge application, because.... well... why wait until something goes wrong to understand the impact of what you are doing? :) This looks like something that could be useful. What is the reason that you use a desktop app for notifications? Most systems use integration with tools like Slack or Teams. Hi taubek! Everything we build is about streamlining the experiences we provide, from monitoring and troubleshooting to discovery (no need to wait for something to go wrong, right? ;)). We found such integrations (including native desktop notifications) to be lacking in terms of context presentation, interactivity and actionability. We know it's not the usual stuff... but that's kind of the point! Let us know your thoughts when you take it for a spin! :) Woah this seems really cool, I was wondering whether Kerno can be deployed to multiple clusters, and how that would look like in the app? Hey there! Anibal here, CTO @ Kerno!
We do support multi-cluster, multi-region and multi-account. We build abstractions of your components and workflows independently of the environment and help you keep things in check across the line :) ... versioning drift tools coming soon! :) I’m happy to have watched the Kerno team build to this point and am very excited to see how they continue to grow in this space! Thanks @The_DaveG! We'll continue to strive and do our best to "wow"! :) So where do you exactly store data inside the cluster, and can I send it to a self-hosted datastore like Clickhouse or S3? What’s the current roadmap regarding supported technologies and cloud providers ? Production-grade, we are currently supporting AWS EKS and GCP GKE is coming next week! But we will have AKS and others going strong before July ends! :) How do you exactly do sampling?