Your application isn’t finished when you’ve closed the last if block and you lined up all the brackets. There’s a whole other world of testing, debugging, and optimization that you haven’t even touched yet. To help you more safely step into that complex phase of making your application even better, we’ve just released a brand-new eBPF collector in v1.20 of Netdata.
Properly monitoring the health and performance of Docker containers is an essential skill for solo developers and large teams alike. As your infrastructure grows in complexity, it’s important to streamline every facet of the performance of your apps/services. Plus, it’s essential that the tools you use to make those performance decisions work across teams, and allow for complex scaling architectures.
Health monitoring and performance troubleshooting aren’t easy. That’s exactly why we’re building Netdata, to democratize monitoring and make it accessible to anyone interested in learning more about their systems and applications. Of course, teaching a complicated topic isn’t easy either. Until recently, the only resource to help new users after installation has been our getting started guide.
I wanted to follow up Ron Miller’s article in TechCrunch about Netdata’s Series A funding last month with the story of Netdata’s inception. It all started when I got… pissed off.
Network monitoring is complex, which is why we’re developing a monitoring tool that will drastically increase DevOps productivity. This release is all about improving Netdata’s day-in, day-out performance. We’re working hard to make deploy enhancements that help engineers make faster, smarter decisions about their systems.
Netdata is made up from agile teams who are deeply committed to improving the usability of our product. We want to respond to our users and introduce in-demand features. Working directly with our community is the best way to make Netdata better. But we face the same the dilemma as all agile teams: How do we do this safely?
As your infrastructure grows more complex, storing long-term metrics becomes difficult and costly to retain. Your team stars to limit the amount of historical data they archive, causing gaps in coverage. Anomalies start to slip through the cracks. Version 1.18 of Netdata aims to solve the monitoring metrics storage problem once and for all. Aside from 5 new collectors, 16 bug fixes, 27 improvements, and 20 documentation updates, here’s what you need to know.
The next version of Netdata has arrived! Aside from dozens of quality-of-life and papercut fixes, we’ve launched some new features we know you’ll be excited to use straight away. Let’s dive in.
We’ve built a lot of amazing things into the open-source Netdata monitoring system. But, no matter how far we’ve come, we’ll always be proud of how little RAM it uses. Right now, Netdata stores metrics in your system’s RAM using a ridiculously efficient database. It only saves or loads historical metrics from disk when you restart it. With this system, Netdata can be both low-resource and exhaustive in its collection of real-time metrics.
We’re excited to launch release v1.16.0 of the open-source Netdata monitoring agent, which delivers real-time health monitoring and performance troubleshooting to nearly any system or application. This release also contains 40 bug fixes, 31 improvements, and 20 documentation updates—if you’d like to see the full list, check out the full release notes.
