I have been working as a performance tester over 15 years now. We all know performance monitoring assists in finding potential performance issues, if any. In this blog article, I will examine the evolvement of performance monitoring tools that I have encountered.
Performance Monitoring in the Servers
At the start of our career, we used to capture performance metrics by two ways. First, by connecting the windows boxes and then using system monitoring programme performance (Performance Monitor). Secondly, by connecting the Linux based boxes like Solaris, AIX with tools for example Putty and then using different Linux performance monitoring commands like top, sar, vmstat, iostat, netstat, ping etc. Or alternatively by using nmon command (Nigel’s Monitor) for Linux , AIX based boxes.
Traditional Performance Monitoring
Then comes the traditional performance testing tools like Tivoli, Introscope, SiteScope and many more. Many individual tools came at this stage to pinpoint the performance issues with many performance counters. Collecting different performance counters while executing different types of performance testing was our main objective. As many performance counters are available, we need to check different performance counters and then correlate. Flexibility to add many performance counters for different types of servers directly with performance testing tools were also available with these traditional performance testing tools. Generally, we used to capture performance testing metrics a few hours before and a few hours after the performance test execution to understand the server resource utilisations before, while and after. Even then, we used to notify well in advance for not sending any request in performance servers while conducting performance testing to avoid any potential impact.
APM-Application Performance Monitoring
The evolution is application performance monitoring or APM tools. These tools are a integrated platform with flexibility to capture many things and having contextual details. Initially these tools are mainly used for production due to cost and in a few cases, they are used even for performance testing environment. Later, application performance monitoring tools are widely used both in production and performance testing environment. This is mainly because of two reasons of software deliveries- first with shift-left performance testing in agile methodologies and secondly with both shift-left and shift-right performance testing in devops methodologies.
Cloud based APM-Application Performance Monitoring
When organisations started moving towards cloud due to its many benefits like cost savings, high security, more flexibility, mobility etc. Cloud based APM-application performance monitoring tools gained popularity. The reason is even if the application is deployed in the cloud, the application performance monitoring is still crucial with cloud monitoring tools (for example Amazon CloudWatch, Azure Application Insights and Google Cloud’s operations suite (formerly Stackdriver)) for overall business success. Overall, objective of all Cloud based APM tools are the same as typical APM tool. However these tools have the addition of benefitting from contextual and intelligence details. These tools support both on-premises as well as in cloud (all types of cloud i.e. public, private and hybrid). Like typical APM tools, it helps performance testers proactively identify the performance issues and resolve immediately even if application is deployed in cloud.
DEM-Digital Experience Monitoring
The next stage is DEM-Digital Experience Monitoring. Digital Experience Monitoring is a comprehensive experience monitoring of both digital agents i.e. human and machine. DEM is an extended version of Application Performance Monitoring (APM) and End User Experience Monitoring (EUEM). It supports both Real User Monitoring (RUM) and Synthetic Monitoring (SM). DEM gives visibility towards totality of the User Experience whereas APM tools provides application or network resources granular level visibility.
While RUM is a passive monitoring technology that captures all end-user interactions to identify if they are being serviced speedily and without any performance issues. SM is an active monitoring technology which is like scripted for business-critical scenarios. Together, RUM and SM can provide deeper visibility into an E2E application’s performance, regardless of where they are running.
Full Stack Observability
Today we have reached the stage where we are beyond monitoring. With monitoring, we are also ensuring that data is made available for monitoring. That means, we are now in the observability stage. Observability, monitoring and followed by automated or manual analysis with actionable intelligence are the basics of today’s full stack observability tools.
With the improvement of Containers, Kubernetes and with open source projects like Prometheus, Grafana, Fluentd, Kibana have influenced to create these full stack observability tools. These full stack observability tools are used for end to end entire application traceability. These tools are first collecting 4 main data types i.e. metrics, events, logs, and traces for full application traceability. And then, understand the relationship among those data points for identifying and solving any specific problems (performance and others) quickly. With full stack observability, we can easily visualize, analyse, and troubleshoot entire software stack in one connected experience. This is like everything at a single place.
Conclusion
Overall, performance monitoring tools in my experience has evolved a lot in the light of accelerated agile/devops methodologies, continuous technical advancements. It assists either by avoiding any potential performance issue in Production or by proactively identifying the potential performance issue and resolve immediately, if any in Production for overall business success and end-user happiness.
Check out all the software testing webinars and eBooks here on EuroSTARHuddle.com
