Today, web applications are often an integral part of any information system.
Whether for productivity (extranet, messaging, …) or business (SaaS CRM, e-commerce platform, cloud invoicing, …),application availability is often critical for users and their business.
It is therefore essential to monitor them, be they SaaS applications or locally hosted.
Choosing the right level
Two levels of monitoring are possible:
- Simple: All the associated hardware / system infrastructure that supported access to the URL.
- Complex: lower level monitoring to include application user scenarios, monitoring of their success and their execution time.
The choice of complex or simple monitoring for each web application, will be influenced by:
- The criticity of the application to the smooth running of your business
- What is the impact of any slowdown? …of a production halt? Is it an internal system or is it a customer site? Is this a test environment?
- The associated ticketing history
- Does this web application generate a lot of support tickets? If so, what is their general nature?
- HS login page -> simple monitoring is enough, with a test of URL.
- delays in file creation or searching -> scenario monitoring required.
- Available resources
- Creating and maintaining test scenarios is time consuming, as its necessary to ensure that they remain compatible with later versions of web applications.
We will begin, as always, by deconstructing the service and assessing its criticality.
- Service: CRM Website
- Hosting: on site
- 1 Windows VM: Web server
- 1 Windows VM: Sql Server Database
- Access URL: https: // someapp / login
- Used by the sales team and helpdesk + extranet part for end customer
- => Critical
- Types of historical tickets
- Stable and fast tool
- Sometimes the page is inaccessible when the application server disk is full
On this occasion we will choose simple monitoring because the URL test is considered sufficient and reliable.
To be added (manually or by discovery), using role-appropriate host / service templates:
- The application server
- For example, we will use the HTTP_HTTPS service template, which is used to test the accessibility of a URL, and the validity of an associated certificate.
- We will also make sure to monitor the IIS service via the MS-WIN-ServicesList-Started template.
- Particular attention should be paid to the disk capacity, since we know it can generate support calls and application unavailability, by using for example the MS-Win-DiskUsage template, and a warning threshold configured according to previously observed rates of disk filling.
- The database server
- We can monitor the SQL Server database with one of the many templates available in the ServiceNav catalog.
It is also possible to use other templates specific to Windows servers to monitor, for example: CPU, RAM, Disk I/O. For speedy, consistent deployment, these service templates are elements of the host template, ‘System Windows server ‘.
We can additionally choose to implement one or more application scenarios. The subject is further detailed in a dedicated blog post.
…and for a SaaS application?
In the case of a SaaS application, the checks undertaken for a traditional server are not appropriate; the hosts can be configured as ‘Not pingable’, with associated service checks of the different URLs used to access the application.
I any case, the general principles remain the same.
Finally, we will validate via both synthetic and traditional monitoring of our newly added application, through the construction of an IT Weather user service: