In the present age of cloud-native everything, it can be easy to forget that some applications still run on-premises. But they do and managing the performance of on-premises apps is just as important as monitoring those that run in the cloud.
With that reality in mind, here’s a primer on how to approach on-premises application performance monitoring as part of a broader cloud-native performance optimization strategy.
In many ways, performance monitoring and management are the same regardless of where your applications are hosted. A log is still a log, and a trace is still a trace, no matter whether the application runs. You’re working with the same types of data sources and the same general metrics in both cases.
Nonetheless, there are some critical differences between on-premises apps and cloud-based apps that have important ramifications for monitoring strategies:
With on-premises apps, you usually have full control over the hosting environment. This can make the instrumentation of monitoring tools easier in many ways because you can install an agent wherever and however you need it to run within your on-premises environment. But it may also be more complicated than it would be in a cloud service where the service automatically feeds monitoring data to a monitoring tool.
In the cloud, it’s easy to replicate workloads across different data centers or regions, or to spin up a backup environment when your production environment fails. You typically can’t do these things on-prem, where you get just one environment to work with. The lack of easy failover solutions on-prem increases the importance of detecting problems with on-premises applications early, before they turn into critical disruptions.
Arguably, monitoring to reveal resource utilization is less important on-prem than it is in the cloud. You’ll still want to collect monitoring data that shows whether your on-premises applications are over-provisioned, but you are probably not as worried about that as you would be in the cloud.
On-premises application architectures tend to be simpler than those in the cloud. Although it’s certainly possible to run things like containers and serverless functions on-prem, doing so is less common than it is in the cloud. It’s more likely that your on-prem software consists of legacy applications that run on virtual machines or bare metal and use straightforward block storage and relational databases.
There are a variety of steps that you can take to build a monitoring strategy that works for on-premises apps, even if you are also managing the performance of other applications that run in the cloud.
One basic best practice is to use monitoring and performance management tools that work with both cloud-based and on-premises apps. This will require branching out from public cloud monitoring tools (like CloudWatch) that only work in the cloud. Third-party solutions that can ingest data from any type of environment provide more flexibility for building an end-to-end performance management strategy.
Because it’s especially important in the case of on-premises applications to catch performance issues early in the development cycle, synthetic monitoring – which allows you to test application performance before you even deploy – can be particularly useful in this context. You should monitor real-user transactions in production, too, but synthetic monitoring may provide the early warnings to ensure that you avoid the types of catastrophic application failures that are harder to work through on-prem than in the cloud.
(Compare synthetic monitoring to real-using monitoring, aka RUM.)
Because on-premises apps give you full control over – and therefore full visibility into – your hosting environment, there are no limits on how much data you can collect. This is different from the cloud, where you may not be able to collect logs from the operating system that hosts your serverless functions, for example, and where you almost never have access to bare-metal hosting environments.
Take advantage of this fact by collecting as much monitoring data as possible from all layers of your on-premises application stack. From bare-metal servers, to hypervisors, to virtual machines and individual applications, you should monitor, correlate, and analyze every metric available to you.
(Use the four golden signals of monitoring.)
It can be easy to overlook the importance of network monitoring, especially if you’re accustomed to working with cloud environments where the network is managed for you by the cloud provider. For on-prem apps, however, network problems can quickly lead to application failures. Remember to pull data from network devices and analyze it alongside other data sources in order to achieve the greatest possible level of visibility into your on-premises applications.
Although performance optimization is similar in some ways in both contexts, on-premises application performance management has some special requirements. Start with a holistic approach with Splunk Observability Cloud that cuts through all the blind spots and reduces your mean-time-to-resolution.
See an error or have a suggestion? Please let us know by emailing ssg-blogs@splunk.com.
This posting does not necessarily represent Splunk's position, strategies or opinion.
The Splunk platform removes the barriers between data and action, empowering observability, IT and security teams to ensure their organizations are secure, resilient and innovative.
Founded in 2003, Splunk is a global company — with over 7,500 employees, Splunkers have received over 1,020 patents to date and availability in 21 regions around the world — and offers an open, extensible data platform that supports shared data across any environment so that all teams in an organization can get end-to-end visibility, with context, for every interaction and business process. Build a strong data foundation with Splunk.