HTTP Endpoint Probe on Clustered Gateway

Application Version and Upgrade Details

Introduction

In the infrastructure monitoring ecosystem, the availability & performance of applications would be a KPI in terms of monitoring. One of the approaches is to measure endpoint availability, performance & reachability. The HTTP Endpoint Probe is a URL monitoring app that helps to monitor both HTTP and HTTPS URLs.

Key Use cases

• Identify outages of the target endpoint and help analyze the overall service performance.
• Identify performance bottlenecks that are impacting end-user experience.
  For example: Identify and measure page loading time and responsiveness of the endpoint. These can arise due to multiple factors (N/W delays, underlying infrastructure issues, and so on)
• Alert on connectivity and other network issues

Prerequisites

• Classic gateway version should be 14.0.0 and above.

• Nextgen gateway version should be 14.0.0 and above.

  Note: OpsRamp recommends using the latest Gateway version for full coverage of recent bug fixes, enhancements, etc.

Hierarchy of Http Endpoint Probe

Http Response probe is a single resource application.

Supported Metrics

Default Monitoring Configurations

HTTP Endpoint Probe has default Global Device Management Policies, Global Templates, Global Monitors and Global Metrics in OpsRamp. You can customize these default monitoring configurations as per your business use cases by cloning respective Global Templates and Global Device Management Policies. We recommend doing this activity before installing the application to avoid noise alerts and data.

1. Default Global Device Management Policies

   You can find the Device Management Policy for each Native Type at Setup > Resources > Device Management Policies. Search with suggested name in global scope. Each Device Management Policy follows below naming convention:

   {appName nativeType - version}

   Ex: http-endpoint-probe Web-endpoint - 2 (i.e, appName = http-endpoint-probe , nativeType = Web-endpoint , version = 2)

2. Default Global Templates

   You can find the Global Templates for each Native Type at Setup > Monitoring > Templates. Search with suggested names in global scope. Each template follows below naming convention:

   {appName nativeType 'Template' - version}

   Ex: http-endpoint-probe Web-endpoint Template - 2 (i.e, appName = http-endpoint-probe , nativeType = Web-endpoint, version = 2)

3. Default Global Monitors

   You can find the Global Monitors for each Native Type at Setup > Monitoring > Monitors. Search with suggested name in global scope. Each Monitors follows below naming convention:

   {monitorKey appName nativeType - version}

   Ex: Http Response Probe Endpoint Monitor http-endpoint-probe Web-endpoint 2 (i.e, monitorKey = Http Response Probe Endpoint Monitor, appName = http-endpoint-probe , nativeType = Web-endpoint , version = 2)

Configure and Install the HTTP Endpoint Probe Integration

1. From All Clients, select a client.
2. Navigate to Setup > Account.
3. Select the Integrations tab.
4. The Installed Integrations page, where all the installed integrations are displayed. Click + ADD on the Installed Integrations page.
5. If you do not have any installed applications, you will be navigated to the Available Integrations page. The Available Integrations page displays all the available applications along with the newly created application with the version.
   Note: Search for the application using the search option available. Alternatively, use the All Categories option to search.
6. Click ADD on the HTTP Endpoint Probe Series tile.
7. From the Configurations page, click + ADD. The Add Configuration page appears.
8. Enter the following BASIC INFORMATION:

Notes:

• Select the following:
  • App Failure Notifications: if turned on, you will be notified in case of an application failure that is, Connectivity Exception, Authentication Exception.
  • Sample payload:

    • URL to be monitored: https://reqres.in/api/users

    • Base URL : https://reqres.in/

              Additional Configuration:
              {
              "Method":"POST",
              "ResContentShouldContain":"",
              "ResContentShouldNotContain":"",
              "HttpHeaders":{"content-type":"application/json"},
              "HttpParams":{},
              "PostData":"{ \"name\": \"morpheus\", \"job\": \"zion resident\"}",
              "UrlPath":"api/users"}
              

9. Select the below mentioned Custom Attribute:

Note: The custom attribute that you add here will be assigned to all the resources that are created by the integration. You can add a maximum of five custom attributes (key and value pair).

10. In the RESOURCE TYPE section, select:

    • ALL: All the existing and future resources will be discovered.
    • SELECT: You can select one or multiple resources to be discovered.

11. In the DISCOVERY SCHEDULE section, select Recurrence Pattern to add one of the following patterns:

    • Minutes
    • Hourly
    • Daily
    • Weekly
    • Monthly

12. Click ADD.

Now the configuration is saved and displayed on the configurations page after you save it.
Note: From the same page, you may Edit and Remove the created configuration.

13. Under the ADVANCED SETTINGS, Select the Bypass Resource Reconciliation option, if you wish to bypass resource reconciliation when encountering the same resources discovered by multiple applications.

    Note: If two different applications provide identical discovery attributes, two separate resources will be generated with those respective attributes from the individual discoveries.

14. Click NEXT.

15. (Optional) Click +ADD to create a new collector. You can either use the pre-populated name or give the name to your collector.

16. Select an existing registered profile.

17. Click FINISH.

The integration is installed and displayed on the INSTALLED INTEGRATION page. Use the search field to find the installed integration.

Modify the Configuration

• See Modify an Installed Integration or Application article.

  Note: Select HTTP Endpoint Probe.

View the HTTP Endpoint Probe Details

To discover resources for HTTP Endpoint Probe:

1. Navigate to Infrastructure > Search > NETWORK SERVCIES > HTTP Endpoint Probe. The HTTP Endpoint Probe page is displayed
2. Select the application on the HTTP Endpoint Probe page
3. The RESOURCE page appears from the right.
4. Click the ellipsis (…) on the top right and select View Details.

5. Navigate to the Attributes tab to view the discovery details.

6. Click the Metrics tab to view the metric details for HTTP Endpoint Probe.

View resource metrics

To confirm HTTP Endpoint Probe monitoring, review the following:

• Metric graphs: A graph is plotted for each metric that is enabled in the configuration.
• Alerts: Alerts are generated for metrics that are configured as defined for integration.

Resource Filter Input keys

HTTP EndpointProbe application Resources are filtered and discovered based on below keys:

Note: You can filter the resources with the discoverable keys only.

Supported Alert Custom Macros

Customise the alert subject and description with below macros then it will generate alert based on customisation.

Supported macros keys:

Risks, Limitations AND Assumptions

• No provision to add url credentials as optional. So not supporting URL credentials
• Monitoring support provided only for HTTP/HTTPs endpoint urls. Currently there is no support for IP addresses
• Encrypted end point URL is used as signature(MoId). Hence if user modified already provided URL, old resource will get deleted and new resource will be created with edited URL.
• As of now, using URL extracted Host name as Resource Host Name and using Profile name as Alias name As of now, using Native Resource Type as Metric instance
• HTTP Endpoint Probe application will send metric data to cloud only if it receives metric success flag as true from cpp executable. In case of any failures/errors OR when conditions(i.e, ResContentShouldContain/ResContentShouldNotContain etc..) given in configurations doesn’t match, SDK app will receive metric success flag as false from cpp executable which results in gaps in metric data.
• This application has dependency with Gateway OS. As of now, We are using Ubuntu 14 made cpp executable. Moving forward if gateway OS is upgraded, there might be chance of app will broke.
• As of now Supported Metrics : endpoint_url_response_Time, endpoint_url_response_LookUpTime, endpoint_url_response_PreTransferTime, endpoint_url_response_StartTransferTime, endpoint_url_response_ConnectTime, endpoint_url_response_RedirectTime. Support for synthetic.response.appconnecttime metric is not provided.
• We are publishing the metrics with the timestamp provided in the cpp executable Response.
• In additional configurations, Postdata field should be a valid data string with escape character.
• Base URL + UrlPath should be a valid endpoint URL.
• In additional configurations, Method should be a valid request methods(GET, POST, PUT, PATCH..). If you are given invalid then it takes by default as ‘GET’.