The URL Genie Management Pack provides a fast and easy way to implement monitoring for a large numbers of URL instances from only a few instances up to many thousands! In addition there are some special features which allow monitoring sites which require client certificates in addition to pages that use forms-based authentication. With URLGenie you can easily configure monitoring for thousands of standard URL instances in less than a minute.
Read More...
Overview
The URL instances and their respective monitoring criteria get instantiated on any number of “watcher” nodes from one or more XML configuration files. Any managed Windows computer can be activated as a watcher node with a simple Console task during which the watcher nodes get configured with a path to where it should look for configuration files. There can exist any number of configuration files, each with any number of requests defined within. Typically the configuration files will be centrally located in a single shared network folder. A decent place for the shared configuration folder is on management server or the data warehouse server with all watcher nodes configured with the same shared folder path. This is the most simple and scalable configuration.
There are standard monitors which target the http and https class types. Each individual monitor will alert with plenty of alert specific context information. This is significantly different than the Operations Manager standard Web Availability or Synthetic Transaction monitoring which will only alert on the rollup and contain no specific or useful alert context information.
The standard monitors all support the various types of http authentication: None, Basic, NTLM, Digest, and Negotiate. In addition, there are special monitor types which can be enabled for URLs that require a client certificate or even for web sites that use forms-based authentication, a first for SCOM (to my knowledge)!
Setup Overview: (from the URLGenie Management Pack Guide)
- Import Management Pack
- Decide where you want to store your configuration files. URL instances get discovered from one or more configuration files. You can store files locally on each watcher node but my suggestion is to create a shared folder on your management server, data warehouse server, or other file server where you can read/write your configuration files. This way any URL instances that you define in your configuration files can be discovered by any/all watcher nodes depending on how you configure the <watchers> tags. See Parameters and Instance Properties section of the MP Guide.
- Activate 1 or more Watcher nodes. See "URLGenie EnableWatcherNode" task section of the MP Guide. Use the path from step 2 above.
- Create one or more configuration files. See Configuration File Examples section of the MP Guide. Once you activate 1 or more Watcher nodes, the instance discovery (http) will run on the activated Watcher node(s). The discovery will attempt to gather instance info from the config files (if the <watchers> tag matches the server name), then create the URL instances which will become automatically monitored within a few minutes after the group population workflows complete. Https discovery will occur once the initial http instances have been discovered.
Monitors
- URL Request Dependency Monitor
- URLGenie CA Untrusted Monitor
- URLGenie Certificate Expired Monitor
- URLGenie Content Monitor
- URLGenie DNS Resolution Failure Monitor
- URLGenie Error Code Monitor
- URLGenie Status Code Monitor
- URLGenie Reachable Monitor
- URLGenie Response Time Monitor
URLGenie Client Certificate Scripted Monitor
- URLGenie URLGrab Scripted Monitor
- URLGenie URLGrab IE Login Scripted Monitor
Rules
- URLGenie ResponseTime Collection PerfRule
- URLGenie URLGrab IE Login ResponseTime Collection Scripted PerfRule
URLGenie URLGrab Client Certificate ResponseTime Collection Scripted PerfRule
- URLGenie URLGrab ResponseTime Collection Scripted PerfRule
- URLGenie WatcherNode ConfigFile Path Test Alert Rule
Tasks
- URLGenie Test Path
- URLGenie Generate Config From List
- URLGenie PingServer
- URLGenie Get Certificate Info
- URLGenie DisableWatcherNode
- URLGenie EnableWatcherNode
Screenshots
Load test with 6000 URL instances on one watcher node (a management server). Configured in minutes. (see MP guide for more detail)
Enable Watcher Node
1) Execute EnableWatcherNode task
2) Watcher node activation success
The output is verbose but we are looking for the success and verification of the config file path as shown below.
3) Watcher node is discovered. Health rollup for the watcher is disabled by default.
Generate Configuration File
1) Start with a basic text file of URLs/addresses
2) Run the task to generate the config file from this basic list.
3) Config file is created successfully
4) The configuratoin file is created with default parameters. Feel free to modify the settings as needed.
Notice the <watchers> tag contains "MS02". Any watcher nodes that contain "ms02" (not case sensitive) in their name (FQDN) will be able to discover these instances.
URL Instances
Health Explorer
Critical Context Info
Alert View
Get Certificate Info Task (for https instances)
Site Login Test
To configure the IE Login Scripted Monitor you will need to find the HTML IDs of the elements designated below. You can find the element IDs by enabling “developer mode” ( Internet Explorer: F12, Chrome: CTRL+SHFT+I ) and selecting the objects to find the section of source code that defines the element properties. See the management pack guide for full tutorial.
Example of a forced critical condition by overriding content parameter
By setting the ContentMatch to something unlikely, I have created a false error condition for the monitor and can now examine the context data to validate that the login is occurring correctly. By looking at the InnerText data retrieved from the web page after logging in, I see text that appears on the expected account page after successfully logging into the target site. This is shown in the state change context data area in Health Explorer and also on the Alert Context tab and Description field of the resulting alert.
IE Login Test ContentMatch Failure Alert
The alert description indicates that the login test was successful but did not find the content match as intended.
IE Login Monitor Healthy
After the ContentMatch field is set to a value that is expected to appear on the target page, the monitor returns to healthy and you can see the expected site text in the context area of Health Explorer.