Cloud and microservices

Cloud native application monitoring – AI powered, full stack, automated

Show all categories

Network in the Cloud is No Free Lunch

If you have your applications running on AWS or a similar cloud-based solution, you’ve effectively “outsourced” your networking to the cloud as well. Of course, this can be of great value. Most significantly because it frees you from maintaining physical network infrastructure. Not having physical access to your network doesn’t, however, mean that you’re free from taking care of your network. Let’s see why you need network monitoring in… read more

Forget freemium: You’re building a business!

tl;dr Selling your startup’s product using a freemium model can be an enticing option early on, seemingly offering you the best chance to get as many new customers on board using your product as possible. Be aware however that going with a freemium model may distract you from your real goals, and ultimately harm your business. So you’re new to the market and need to convince inven/estors that your product… read more

Beyond the IPO Hype – Why we decided to become a private company again

An IPO and a billion dollar valuation sounds like your company made it. Trust me, building a company from scratch and eventually selling it for a good deal of money, feels great. However, it also changes the game completely. We became a public company and after successfully growing and evolving our vision for how we could best continue to reshape the future of application performance, we decided to come full-circle… read more

Newsletter: “Microservices”

Hi all, Today’s newsletter focuses on….Tadaaa!  Microservices! Microservices, SOA, and ruxit – A Cheat Sheet  Why the heck are microservices the business of an APM tool you ask? Read this blog post to find out. Microservices Digest We are proud to present our new microservices digest. This digest provides an overview of good resources that are well worth reading. We’ll be updating this page as new… read more

Disk access problems in VMware environments

If your VMware-hosted application struggles with poor performance, be aware that application performance depends not only on available CPU and memory resources, but also on disk I/O performance and network communication health. How do I figure out the causes of poor performance? Many tools facilitate the exploration of performance problems with respect to applications themselves. These tools typically monitor the performance of a single component, such as a database… read more

Why your pagespeed score matters less than you think

You’ve put a lot of effort into the optimization of your website and you’ve finally earned a decent Google PageSpeed Insights score. You pride yourself on your optimized database queries, fast code, and slick well-designed frontend, but do you really know what kind of experience your customers are having with your site? To investigate, let’s check out how well two of the top-listed websites on Alexa.com perform under real world… read more

Newsletter: “Events, Errors and Performance”

Hi everybody, This is our last update before the holiday season! Introducing the Ruxit leadership team We’ve just published our leadership bios page, so now you can see a few of the faces behind Ruxit. Stop by and say hello. Release update: Smart auto-analysis of JavaScript errors The challenging thing about JavaScript errors is that they occur in customers’ browsers and there are often so many of them that it… read more

Monitor Your Network Like a Professional

This post is about the impact of network issues on services and applications. We will introduce all the relevant metrics like the number of retransmissions, etc. Of course, we will also show how to monitor those numbers easily and what that means for your environment. Application Performance Monitoring is not just about measuring response times of services and applications. For being able to correlate and evaluate all of the collected… read more

FDI analytics of network performance problems

In my previous post, I discussed network communication monitoring basics and the Ruxit value proposition related to that. We have mentioned that Ruxit can tell you which processes experience network degradation problems. If network link or segment is overloaded and under-performing it will start dropping packets. It is due to overloaded queues on network equipment that get purged in case of excessive traffic or lack of hardware resources. read more

A Ruxit Success Story

The following is a response we received to one of our newsletters. If you want to share your own ruxit success story, we would love to hear about it. Enjoy! Hi Martin,   there is no email address on the ruxit.com webpage, so your email-address from the periodic newsletter is the only one I have.   I run a small software developing company with less than 10 developers in Linz/Austria. The server being monitored offers e-commerce services to approximately 30 customers and hosts a quite heterogeneous collection of software services. Here in Austria we have a saying “Aus jedem Dorf einen Hund” (editor's note: freely interpreted as "a little bit of everything"), technically speaking the machine is running IIS, Apache, Tomcat, Elasticsearch (ES), Logstash, MongoDB, PervasiveSQL, some “mature” web applications implemented in vanilla ASP and currently 12 tomcat instances. OS is Windows Server with 32 GB of RAM.   When we installed ruxit a few weeks ago, it immediately complained about Elasticsearch having too high GC times – we simply ignored it. The primary reason for ignoring the information was that ruxit was very new and we’ve used ES for eight months without any problems. The other reason might have been that we’ve been doing our business for more than 10 years, all the services including ES performed – so no reason to think something could be wrong.   One day, my developer informed me, that the Elasticsearch did not respond anymore and he strongly disadvised to perform the scheduled deployment because without Elasticsearch we would not be able to monitor the health of our applications and their log statements in realtime.   Fortunately it was a Friday – so I had the whole weekend to deal with the issue. Saturday morning was dedicated to Elasticsearch. I tried to find out what’s wrong with this service. What I’ve learned the last years is that if you cannot solve a problem within 2 hours, you won’t solve it the next 10 hours unless you change your approach. So I remembered the ruxit message regarding the GC times. The rest was easy. GC is mostly related to low memory – so after optimizing the memory configuration of the system and re-enabling the functionality of our monitoring software we noticed less memory consumption, less CPU usage and ES was working again.   Good job ruxit.   Regards   Paul     read more