Managing agile software deployment for cloud infrastructure can be challenging. Deployments should be automated whenever possible to ensure consistent version management. Nevertheless, it can happen that identical software versions are not deployed to all servers. Such imperfect version management is a potential time-bomb. Distributed systems and microservices often rely on the deployment of the exact same software version installed on every cluster node.

What are the essential things to monitor in your infrastructure? Sure, CPU utilization, memory usage, and IO throughput. However, once you notice a significant load somewhere in your infrastructure you want to know what is causing it, and that typically boils down to needing to find the process that’s using too much CPU or memory or that’s doing disk or network IO like there’s no tomorrow.

XDP or Express Data Path arises due to the pressing need for high-performance packet processing in the Linux kernel. Several kernel bypass techniques (DPDK being the most prominent one) aim to accelerate network operations by moving packet processing to user space.

As the first part of the three-part series on monitoring Apache Solr, this article explores which Solr metrics are important to monitor and why. The second part of the series covers Solr open source monitoring tools and identify the tools and techniques you need to help you monitor and administer Solr and SolrCloud in production.

As shown in Part 1 Solr Key Metrics to Monitor, the setup, tuning, and operations of Solr require deep insights into the performance metrics such as request rate and latency, JVM memory utilization, garbage collector work time and count and many more. Sematext provides an excellent alternative to other Solr monitoring tools.

Open source software adoption continues to grow. Tools like Kafka and Solr are widely used in small startups, ones that are using cloud ready tools from the start, but also in large enterprises, where legacy software is getting faster by incorporating new tools. In this second part of our Solr monitoring series (see the first part discussing Solr metrics to monitor), we will explore some of the open source tools available to monitor Solr nodes and clusters.

Node.js monitoring is a tricky task. There are certain challenges to look out for. Because Node.js is a dynamically typed programming language and single-threaded you give the interpreter and runtime a lot of freedom to make decisions. This can easily result in memory leaks and high CPU loads. Parallel execution is simulated in Node.js by using asynchronous execution of functions. But, if a single function blocks the thread or event queue, the application performance will take a huge hit.

Making Node.js applications quick and sturdy is a tricky task to get right. Nailing the performance just right with the V8 engine Node.js is built on is not at all as simple as one would think. JavaScript is a dynamically typed language, where you let the interpreter assign types to variables. If you’re not careful this can lead to memory leaks.

What is the most important feature your Node.js application can have? Do you think it’s having fancy fuzzy logic for your full-text search, or maybe using sockets for real-time chats? You tell me. What’s the fanciest, most amazing and sexy feature you can add to your Node.js application?