22 Nov, 2022 | 3 min read

Monitoring Asgardeo using Site24x7

  • Janeth Fernando
  • Software Engineer - WSO2

Asgardeo is a SaaS-based customer identity and access management (CIAM) solution that allows users to quickly integrate authentication and authorization into an application. The benefit of Asgardeo is that no time is wasted reinventing the wheel by implementing authentication and authorization flows in the application. You may visit the official WSO2 Asgardeo website for further information on Asgardeo.

In this article, we are going to talk about the monitoring and alerting aspects of Asgardeo. Monitoring is a very important aspect of any business-critical application. Monitoring is used to identify whether the application performs as expected without any outages. The trends of the application can also be understood by using monitoring. Capacity planning can be done using system metrics, which are also part of monitoring. Moreover, the main purpose of monitoring is to notify the relevant parties immediately if the application is not performing as expected.

Asgardeo uses various monitoring techniques to achieve the factors mentioned above. Asgardeo uses two third-party monitoring vendors, which are Site24x7 and Azure. Azure is used for log-based monitoring, dashboard creation, and infrastructure metrics monitoring in Asgardeo. Site24x7 is used to monitor the application’s backend functionality,user flows,latency, SSL certificate expiration, and uptime. In this article, we are going to focus on how Asgardeo uses Site24x7 for monitoring and alerting.

What is Site24x7?

Site24x7 is a third-party vendor that provides a range of monitoring and alerting solutions. Some solutions include REST and SOAP API monitoring, DNS monitoring, website availability monitoring, internal network monitoring, etc. Using Site 24x7 solutions, it is possible to monitor the individual components of our application to validate its functionality. A check frequency can be added to test the functionality of the application component at a predefined interval. For example, we can schedule a monitor to run every five minutes. This frequency number is defined according to the importance of the component. As a result, the monitor will continue to send requests based on frequency. Site24x7 has a number of polling locations (servers in different geographical areas) to send requests to the components. Latency thresholds can be defined for API calls. When the latency threshold is reached, or if a component is not functioning as expected, Site24x7 will notify the relevant parties according to the notification policy.

How Site24x7 is used in Asgardeo?

Asgardeo uses rest API monitoring, rest API transaction monitoring, uptime monitoring, and SSL certificate monitoring features from Site24x7. In this article, we will be going through each of the monitoring types one by one. Before configuring the above-mentioned monitors, there are some pre-configurations that need to be completed. The following are the pre-configurations.

1. Setting up location profiles: A location profile is a setting that we include to mention the primary location and the secondary locations that we want to initiate requests to the application. Asgardeo has one primary location and several secondary locations. The primary location is the closest location to the Asgardeo deployment. From the primary location, the latency is minimal. As the secondary locations, a wide spread of regions can be selected.

2. Setting up threshold profiles: A threshold profile is used to set warnings and critical thresholds for monitors. If these thresholds are reached, the monitors will send notifications. With this profile, it is possible to set thresholds for the primary and secondary locations independently.Selecting the threshold numbers are done according to the performance tests that are carried out against the deployment. According to the thresholds, the monitor status will be changed to down, critical, or trouble.

3. Setting up notification profiles: A notification profile is used to configure the methods to send out alerts/notifications to the relevant parties according to the monitor statuses. This setting also permits configuring email templates. In Asgardeo, PagerDuty integration is used to notify the appropriate parties via a phone call and an SMS, in the event of a monitor failure status.Along with the PagerDuty call, Site24x7 sends an auto-generated error report.

In the Asgardeo application’s staging and production environments, there are two separate tenants created just for monitoring purposes. Furthermore, Asgardeo has two separate Managed Service Provider (MSP) accounts in Site24x7 for the stage and production environments.

Site24x7 authenticates the Asgardeo tenants by using the web token configuration. The Asgardeo account’s credentials are passed to this configuration and can be authenticated to the account. Site24x7 will automatically refresh the Asgardeo account’s access token by using this configuration. This is another configuration that needs to be done prior to setting up the monitors.

The type of Site24x7 monitors used in Asgardeo 

Rest API monitors: These types of monitors are used to send a single API call that we define. From this kind of monitor, we can get an understanding that our application API calls perform the expected behavior. In the monitor configuration, the endpoint, the parameters, the request method, the accepted status codes, the request timeout interval, and the frequency can be defined. Other than these configurations, the pre-configurations that were added before need to be selected from the prompted list. The monitor will perform the API call from the selected locations (location profile) at the configured frequency. The monitor will match the configured accepted status code with the status code that the monitor received from the API call. The monitor will validate the latency thresholds (using the threshold profile) that we have pre-configured. If the monitor has reached the thresholds in the threshold profile or if the monitor is incapable of receiving the accepted status codes, it will retry the call instantly. If the retry was also unsuccessful, then the monitor will trigger a notification according to the notification profile.

Rest API transaction monitors: These types of monitors send a set of API calls in sequential order. We can add the set of API calls that a user performs to get a task done. The API calls are defined as steps. The advantage of this kind of monitor is that the response from one API call can be used in the next API call (the next step). The response status codes of each API call can be individually validated. If any of the API calls (steps) fail to provide the expected response, the monitor’s status will be changed accordingly. For example, this type of monitor is used in the Asgardeo application creation workflow. To create the application, one step (an API call) is available. Once the application is created, the application ID will be used to check if the application was properly created with the required data. Then, another step is taken to change the Asgardeo application’s configuration, like adding a federated IDP. Then finally, there is another step to delete the application that was created. If these steps are working fine, the monitor status will be passed.

Website monitors: Website monitors are used to monitor the availability of the deployment’s public endpoints. e.g., to check if web pages are getting loaded. For these kinds of monitors, authentication is not required from the application. The content of the response can be checked to make sure that the webpage is successfully loading. The monitor check frequency is very important as we need to maintain a perfect SLA for the public-facing endpoints.

SSL certificate monitors: These types of monitors are used to check if the public SSL certificates are valid. It is also being used to check the expiration of the SSL certificate. The public-facing SSL certificates are rotated automatically by Asgardeo. But if there is an issue when rotating the certificate, this monitor will notify you days prior to the expiration date of the certificate. 

Site24x7 also offers a customized status dashboard. The Asgardeo status dashboard can be viewed here. Site 24x7 provides a set of APIs that we can use to create a custom dashboard of our choice.

I hope you now have a better understanding of how Asgardeo uses Site24x7 for monitoring. Site24x7 ensures that Asgardeo is continuously monitored to ensure high availability. This type of monitoring fosters customer trust in Asgardeo. It gives customers the impression that Asgardeo is allocating a significant amount of resources to ensure the application's high availability.

The WSO2 SRE team is responsible for implementing processes and best practices that enable  Asgardeo, our IDaaS solution; Choreo, our next generation iPaaS for cloud native engineering; and other cloud-based offerings to run in a reliable, scalable, and secure manner. For more information, visit the WSO2  homepageevents page or  blog.