--- title: "WEB-MON" description: "" url: "https://docs.itrsgroup.com/docs/geneos/7.11.0/collection/webmon/index.html" --- ## Introduction Geneos WEB-MON Plug-In checks a WEB Server's ability to supply pages/files by requesting a series of pre-set pages/files on a regular basis. Page/file availability, response time, data size and any HTTP headers are displayed and rules can be set to alert when a page/file becomes unavailable or when the response times are unacceptable. This is particularly useful when WEB Servers are managed by an Application Service Provider (ASP) or Internet Service Provider (ISP), where this could be the only facility to ensure the quality of the service. Additionally, you can use this plugin to: - Check if a website is up and validate its content. - Get QoS information for logging or SLA purposes. - Check website security. - Validate responses from different users. - Pass content to the extractor plugin for further content processing. All HTTP Web Server types are supported. Where servers publish their type, this information is displayed for reference. Each WEB-MON instance monitors a single web server. Multiple instances may be configured if more than one server is to be monitored. **Note** The cURL library used by WEB-MON plug-in cannot utilise JavaScript. Refer to [ITRS Synthetic Monitoring User Guide](https://docs.itrsgroup.com/docs/geneos/7.11.0/collection/synthetic-monitoring/index.html) for more information. ## Intended Audience This user guide is intended for experienced Geneos users who want to monitor web pages. As a user, you should be familiar with the HTTP protocol, cURL library, proxy connection, and protocols like NTLM and Kerberos if authentication will be used. ## Scenarios and Stages The configuration of the WEB-MON plug-in is broken down into a number of scenarios. Each scenario allows a series of stages (web pages or files) to be requested in sequence, in the same way that a user would do. Scenarios themselves are run in parallel. Stages have a set of success criteria associated with them, such as a response code or time to complete. If the criteria are not met then the stage and the overall scenario will fail. If the website is simple then a number of scenarios may exist, each of which may be composed of a single stage. These could then check that a number of key pages are available. If the website is more complex then more stages may be needed in the scenarios. An example scenario might be to log in with a username and password, and then request a page that is unavailable without a login. Another scenario may be to deliberately enter an incorrect username and password, and verify that the request for the protected page fails. The [Examples](https://docs.itrsgroup.com/docs/geneos/7.11.0/collection/webmon/index.html#examples) section of this document describes possible uses in more detail. ## Views The WEB-MON plugin produces one view which can be displayed in `Summary` or `Summary and Details` mode. WEB-MON plugin in `Summary` mode: ![Summary mode](https://docscdn.itrsgroup.com/geneos/images/plug-ins/webmon-summary-dataview.png) WEB-MON plugin in `Summary and Details` mode: ![Summary and Details mode](https://docscdn.itrsgroup.com/geneos/images/plug-ins/webmon-summary-and-details-dataview.png) The `samplingStatus` will show `OK` if the sampling takes longer than the initial sample period to complete a scenario, or `FAILED` if the setup is incorrect. **Headline Legend** The headlines are shown above the main table and provide an overview of the state of the server.

Name	Description
serverName	The name of the server, as specified in the setup. This is what is sent as the Host header in the request.
ipAddress	The IP address that has been resolved from the server name or proxy name.
serverURL	If present, the ipAddress, serverType and serverState fields are populated as a result of making a request for this URL (relative to serverName). Otherwise, the mentioned fields are populated as a result of making a request for "/" (which is typically the default server webpage).
portNumber	The port being used. This will typically be 80.
serverType	If the server publishes a type (Server header) then this will be displayed here. If a proxy server has responded with an error then this will be the proxy server type.
serverState	This will be one of: UP - The server is responding to requests UNAVAILABLE - The server name cannot be resolved or the web server is not running. TIMEDOUT - The server is running, but has taken too long to reply. UNKNOWN - Another type of error has occurred. If a proxy server is used this will show the state of the proxy server, not the destination server.
scenariosFailed	A count of the number of scenarios that have failed.
scenariosInError	A count of the number of scenarios that have errors.
scenariosTimedOut	A count of the number of scenarios that have taken too long to run.
protocol	Whether http or https is being used.
proxy	Server name and port of proxy server being used, if any.

The ipAddress, serverType and serverState columns are populated as a result of making a request for the default server webpage (/). **Table Legend** The columns in the table are broken up into two parts: The first set of columns show status information about the stages and scenarios; The second set of columns show more details about the requests and responses. For scenarios, the second set of columns will show the details of the last stage to run. For successful scenarios, this will be the last stage. For unsuccessful scenarios this will be the stage that failed.

Name	Description
name	Scenario Name or Scenario Name # Stage No. # Stage Name
status	For scenarios, the status can be: OK - Every stage of the scenario ran successfully. TIMEDOUT - The scenario took too long to run. ERROR (stage name) - An error occurred on the specified stage during retrieval. FAILED (stage name) - The page for the specified stage did not meet the relevant success criteria. This includes the page taking too long to retrieve. IDLE - Nothing is happening. Probably because no stages have been configured. For stages, the status can be: OK - The page was downloaded correctly and met all the criteria DOWNLOADING - The page is currently being downloaded. TIMEDOUT - The stage took too long to run. ERROR - There was a problem getting a response from the server. FAILED - The success criteria have not been met. CANCELLED - The scenario cancelled this request. This could happen if the scenario took too long to run. SKIPPED - A previous stage in this scenario did not complete successfully, so this stage was not run.
detail	If the status is not OK then this column provides more information about what went wrong.
duration	For stages this will be the time taken to resolve the hostname, make the request and get the page back. For scenarios this will be the time taken to run each stage, check the success criteria, and set up the next stage. The time will therefore sometimes be fractionally greater than the sum of the stage times.

Name	Description
url	The URL of the request
responseCode	The HTTP response code. This will be, for example, 200 for OK or 404 for Not Found. The full set of possible response codes can be found in RFC2616 References.
responseText	A textual description of the response code, as sent by the server.
downloaded	The number of bytes downloaded as the body of the page. If a Transfer-Encoding is used by the server then this will not necessarily be the same as the length of the content.
(additional headers)	Additional response headers may be configured, and these will be shown as extra columns in the view.

## Plug-In Configuration Each WEB-MON instance monitors a single web server. Multiple instances may be configured if more than one server is to be monitored. Scenarios are configured with a number of stages in each. Stages can have additional data sent as part of the request, such as query variables and headers. They also specify a set of success criteria that, if breached, will cause a FAILED state to occur. In addition to the configurable success criteria, if the server sends a Content-Length header and the amount of data downloaded does not match this then the stage will fail. It is possible to configure connection details at the scenario or stage level in addition to the top level. This allows connections to other servers if, for example, authentication is required from a central location. It also allows monitoring of multiple domains that are served from the same physical web server, or checking both secure and non secure versions of a site. Although setting different connection details would also allow multiple physical servers to be monitored from the same WEB-MON instance, this is not recommended, and the headline variables will only show the status of the main server being monitored. The configuration parameters are listed below: #### host The full name of the server to monitor. This should be entered as it is entered in a web browser, and might not be the same as the physical hostname of the server if virtual hosting is being used. For example, a server serv1 might be hosting and . The host should be set to or rather than serv1. Mandatory: Yes #### port The port of the server to monitor. Mandatory: No Default: 80 (http) or 443 (https) #### serverURL If specified, the ipAddress, serverType and serverState headline fields are populated as a result of making a request for this URL (relative to host). Otherwise, the mentioned fields are populated as a result of making a request for "/" (which is typically the default server webpage). For example: if host is set to and serverUrl is set to sample1, the request would be made for . If this field is not set, request would be sent for for instead. Mandatory: No Default: 80 (http) or 443 (https) #### protocol Whether to use http (unencrypted) or https (SSL encrypted). When using SSL connections, the server certificate can also be *verified*. Mandatory: No Default: http ##### protocol > https > certificate Certificate to use for the SSL authentication.

Setting	Description
Verify	Whether to check the server certificate.
Client Certificate	Certificate that will be sent to a web server that requires SSL client authentication. Must be in PEM format. Required for client authentication.
Client Key	Private key corresponding to the client certificate. Must be in PEM format. Required for client authentication.
Client Key Passphrase	Passphrase used to encrypt the private key. Needs to be specified only if private key is passphrase-protected.

Mandatory: No Default: No ##### protocol > https > certificate > verify What to check within the certificate.

Setting	Description
None	Will succeed as long as any certificate is present.
Against authority	Checks the certificate to ensure it has been signed by a Certificate Authority (CA) that is trusted, but doesn't check that the hostname matches.
Against authority and hostname	Checks that the certificate has been signed by a trusted CA and that the hostname matches

When checking the certificate against a Certificate Authority then a CA Bundle in PEM format must be used. This file specifies the CAs that are to be trusted. If the operating system has not come with a CA or it is out of date then a CA Bundle should be specified. This can either be constructed (if, for example, you wish to add your own trusted authorities when self-signing) or downloaded. If you wish to generate your own then please search online for 'Creating a PEM CA bundle'. If you just wish to download an existing one then you can do so from the cURL page describing how to extract CA certificates from Mozilla: **Note** On Linux in Geneos 7.2.0 and earlier versions, the Netprobe searches for the default CA bundle at `/etc/pki/tls/certs/ca-bundle.crt`. However, in Ubuntu and SLES platforms, the default CA bundle is not located at this path. For these platforms, you can either specify a path in the CA Bundle setting or create a symbolic link at `/etc/pki/tls/certs/ca-bundle.crt` to the platform's default CA bundle. - For Ubuntu: The default CA bundle is at `/etc/ssl/certs/ca-certificates.crt`. - For SLES: The default CA bundle is at `/var/lib/ca-certificates/ca-bundle.pem`. Mandatory: No Default: none ##### protocol > https > tlsVersions > minTLSVersion Minimum TLS Protocol version to be used. Mandatory: No Default: none ##### protocol > https > tlsVersions > maxTLSVersion Maximum TLS Protocol version to be used. Mandatory: No Default: none #### proxy Settings for making connections via proxy servers. **Note** If a proxy is specified at the top level then this changes the behaviour of some headline variables.

Name	Description
serverName	Unchanged
serverURL	Unchanged
ipAddress	This will be the IP address of the proxy.
portNumber	Unchanged
serverType	In the event that the proxy server responds with an error then this will be the proxy server type, otherwise it will be unchanged.
serverState	The state of the proxy server. The state of the destination server is invisible to the netprobe. If the destination server is unavailable the proxy will likely respond with an http error code, however this could equally have come from the destination server. There is no way to tell. The server type should give a clue as to whether the request reached the destination or got no further than the proxy.
scenariosFailed	Unchanged.
scenariosInError	Unchanged.
scenariosTimedOut	Unchanged.
protocol	Unchanged.
proxy	Configured proxy connection settings.

Mandatory: No Default: none ##### proxy > none Explicitly disable proxy. ##### proxy > proxyServer > host Hostname of proxy server. Mandatory: Yes ##### proxy > proxyServer > port Port number of proxy server. Mandatory: Yes ##### proxy > proxyServer > type The type of proxy to use. Six types are currently supported. Mandatory: Yes

HTTP	Http 1.1.
HTTP 1.0	Http 1.0.
SOCKS 4	Socks 4.
SOCKS 4A	Socks 4a.
SOCKS 5	Socks 5 but resolve the hostname locally.
SOCKS 5 Hostname	Socks 5 and let the proxy resolve the hostname.

##### proxy > proxyServer > authentication Authentication settings for proxy. Mandatory: No Default: None ##### proxy > proxyServer > authentication > password Allows username/password combinations to be sent to proxy servers. ##### proxy > proxyServer > authentication > password > loginCredentials Contains details of the username and optional password. The password may be encoded in the setup file so that it is not easily visible if required. Kerberos authentication (GSS-Negotiate) does not require this setting as it relies on Kerberos tickets to authenticate with the web server. See [*Authenticating with Kerberos*](#authenticating) for more details. ##### proxy > proxyServer > authentication > password > method Allows various HTTP authentication methods to be selected. These are all enabled by default but only one method should be selected by the user. Disabling other methods may speed up the request and prevent usage of incorrect methods (depending on which methods are employed) so disabling other methods is highly recommended. For example, if the user wants to use NTLM authentication, and the host is known to have both NTLM and Kerberos (GSS-Negotiate) authentication, it is highly recommended to enable NTLM authentication, and disable both Basic and Kerberos authentication. Kerberos authentication requires additional configuration prior to use. See [*Authenticating with Kerberos*](#additional-configuration-information) for more details. Mandatory: No Default: All methods are enabled #### authentication Allows authentication information to be sent along with requests using various methods. When usernames and passwords are entered into webpage forms then query vars should be used instead. See the [Checking Secured Pages](#checking-secured-pages) example for more details. Mandatory: No ##### authentication > httpAuthentication Allows HTTP level authentication to be set ##### authentication > httpAuthentication > password Allows username/password combinations to be sent to servers. When using a web browser, this authentication method is typically seen by a pop-up dialog box. ##### authentication > httpAuthentication > password > loginCredentials Contains details of the username and optional password. To set an encrypted password, click on the "Set Password" button, then enter and confirm the password to be used. Kerberos authentication (GSS-Negotiate) does not require this setting as it relies on Kerberos tickets to authenticate with the web server. See [*Authenticating with Kerberos*](#authenticating-with-kerberos) for more details. ##### authentication > httpAuthentication > password > method Allows various HTTP authentication methods to be selected. These are all enabled by default but only one method should be selected by the user. Disabling other methods may speed up the request and prevent usage of incorrect methods (depending on which methods are employed) so disabling other methods is highly recommended. For example, if the user wants to use NTLM authentication, and the host is known to have both NTLM and Kerberos (GSS-Negotiate) authentication, it is highly recommended to enable NTLM authentication, and disable both Basic and Kerberos authentication. Kerberos authentication requires additional configuration prior to use. See [*Authenticating with Kerberos*](#authenticating-with-kerberos) for more details. Mandatory: No Default: All methods are enabled #### display Contains a number of settings to control how the information is displayed. ##### display > displayMode The display mode will be one of: Mandatory: No Default: SUMMARY

Setting	Description
SUMMARY	Just display the Scenarios
SUMMARY+DETAILS	Display the Scenarios, and also display each of the Stages under each Scenario.

##### display > displayURL You can display URLs in one of the following ways: You may not wish the query part of the URL to be shown in the view if it contains sensitive information, however if you use the 'encoded' query variables option then it will be shown as name=[encoded] so that it is not visible in Geneos. Even with all these measures in place, this will not prevent the information showing up in any server logs. Mandatory: No Default: PATH

Setting	Example Result
PATH	/path/to/file.html
PATH+QUERY	/path/to/file.html?name=value&name=value
FULL	http://www.example.com/path/to/file.html
FULL+QUERY	http://www.example.com/path/to/file.html?name=value&name=value

##### display > displayHeaders If you wish to see additional HTTP headers then they can be specified here. Each one will appear as a new column in the view. This is particularly useful if your web application writes out custom headers. A full list of standard headers can be found in RFC2616 [References](#references). Examples of potentially useful headers are: Content-Length, Last-Modified, X-Powered-By. Mandatory: No Default: No additional headers #### maxInitialSample When each sample starts it will check the status of the downloads every 0.1 seconds for an initial period. If it hasn't finished after that time then it will leave the downloads in the background and relinquish control to other samplers. It will then check the status again while other samplers aren't sampling, until all the scenarios are complete. The minimum time between these additional checks is 1 second. Mandatory: No Units: Seconds Default: 5 #### maxServerDuration This setting allows the maximum amount of time to wait for the main server status - the settings which allow the headline variables to be populated. Mandatory: No Units: Seconds Default: 60 #### GSS-Negotiate **Note** Kerberos authentication for the Web-Mon plugin is only supported on Linux platforms. Beginning Geneos 5.6.x, you can set a Kerberos principal and keytab on Web-Mon samplers running on Linux x64 platforms. This facilitates automatic Kerberos ticket renewal.

Option	Description
Principal	Unique identity to which Kerberos can assign tickets.
Keytab	File path to the keytab for the specified principal.

Once the principal and keytab are defined, the sampler will generate the Kerberos ticket inside the current working directory. #### scenarios Contains the list of scenarios. If no scenarios are configured then only the default server webpage (/), or the serverUrl(if provided), will be monitored and the results shown in the headline variables. ##### scenarios > scenario A scenario is a named object that consists of a number of requests to the same web server ([scenarios > scenario > stages](#scenarios--scenario--stages)). Cookies are maintained within a scenario but not between scenarios. ##### scenarios > scenario > name Specifies the name of a scenario. Each scenario should have a unique name within this sampler. The scenario mode will be displayed as the row name in the dataview, and will also form the first part of the row names when SUMMARY+DETAILS is selected as the [display > displayMode](#display--displaymode). ##### scenarios > scenario > connection This allows the connection details to be overridden. See the following sections for more details: - [*host*](#host) - [*port*](#port) - [*protocol*](#protocol) - [*authentication*](#authentication) - [*proxy*](#proxy) ##### scenarios > scenario > successCriteria Allows success criteria to be specified for the whole scenario. Each stage also has its own, more extensive, [*success criteria*](#scenarios-and-stages). ##### scenarios > scenario > successCriteria > maxDuration This specifies the maximum amount of time the scenario is allowed to run for. If this time is exceeded then the scenario will be marked as TIMEDOUT, the current stage will be CANCELLED and any remaining stages will be SKIPPED. Mandatory: No Units: Seconds Default: 60 #### scenarios > scenario > stages Contains the list of stages. A stage is a single request to a web server. Requests in a scenario are made in the order they are declared in the setup. ##### scenarios > scenario > stages > stage A stage is a named step inside a scenario. A stage is a single request to a web server. ##### scenarios > scenario > stages > stage name Specifies the name of the stage. This should be unique within the scenario. It will be seen in the scenario line if this particular stage fails. It will also form the second part of the row names when SUMMARY+DETAILS is selected as the [display > displayMode](#display--displaymode). ##### scenarios > scenario > stages > stage > connection This allows the connection details to be overridden. See the following sections for more details: - [*host*](#host) - [*port*](#port) - [*protocol*](#protocol) - [*authentication*](#authentication) - [*proxy*](#proxy) ##### scenarios > scenario > stages > stage > url Specifies the URL (relative to the server root) of the page to request. Example: ``` /path/to/file.html ``` It is possible to specify the query string as part of the URL, but it must be properly encoded. This may be used in addition or as an alternative to the queryVars table. The queryVars table is preferred as any name/value pairs in this table will be encoded by the plugin, and hiding of sensitive information is also supported. Example: ``` /path/to/file.html?name=value&name=value ``` Mandatory: Yes #### scenarios > scenario > stages > stage > requestData This configuration allows the request to be altered ##### scenarios > scenario > stages > stage > requestData > method Sets the request method to GET or POST. GET is the normal option for standard page requests, and POST is the normal option when submitting information to forms, particularly if a lot of data is to be sent, or if sensitive information needs to be transferred so that it won't show up in server logs and proxies as part of the request URL. Although it is possible that either method can be used in either case, sometimes when forms are involved the server will insist on one method or another so it is worth checking the page source to see which is used. See the [Checking Secured Pages](https://docs.itrsgroup.com/docs/geneos/7.11.0/collection/webmon/index.html#Checking-Secured-Pages) example for more details. Mandatory: No Default: GET ##### scenarios > scenario > stages > stage > requestData > method > get > queryVars The query variables are appended to the URL as name/value pairs. They will be URL encoded automatically so there is no need to encode them before entering them. It is also possible to perform Geneos-level encoding of the values for when sensitive information such as passwords is used. This information will not show up in the setup file, and if the PATH+QUERY or FULL+QUERY displayURL option is selected then this data will show up as [encoded] in the dataview. For example: ``` /login.php?username=myname&password=[encoded] ``` Mandatory: No Default: No additional variables ##### scenarios > scenario > stages > stage > requestData > method > post > body > queryVars The query variables to be sent as the body of the POST request. Each name value pair is url encoded and then passed to the server with the Content-Type: x-www-form-urlencoded unless overridden in the requestHeaders configuration. For example: - Geneos: Netprobe - Gateway: Webmon would be encoded as: ``` geneos=netprobe&gateway=webmon ``` Mandatory: No Default: Empty Post Request ##### scenarios > scenario > stages > stage > requestData > method > post > body > rawData The body of the post request to be sent to the server, as a string. This allows Webmon to post any type of string data to the server, for example SOAP requests. **Note** You should also add the Content-Type to the requestHeaders configuration to indicate to the server the mime-type of the raw data that Webmon will send. For example a SOAP request would have a Content-Type of `application/soap+xml`. If this header is not specified the type will default to `x-www-form-urlencoded`. Mandatory: No Default: Empty Post Request ##### scenarios > scenario > stages > stage > requestData > queryVars *Deprecated: use queryVars under the GET or POST elements* The query variables are appended to the URL as name/value pairs. They will be URL encoded automatically so there is no need to encode them before entering them. It is also possible to perform Geneos-level encoding of the values for when sensitive information such as passwords is used. This information will not show up in the setup file, and if the PATH+QUERY or FULL+QUERY displayURL option is selected then this data will show up as [encoded] in the dataview. For example: ``` /login.php?username=myname&password=[encoded] ``` Mandatory: No Default: No additional variables ##### scenarios > scenario > stages > stage > requestData > requestHeaders The request headers allow additional headers to be sent to the server as part of the request. An example of use might be to change the User-Agent header for applications that serve different pages depending on the web browser being used. A full list of standard headers can be found in RFC2616 [*[1]*](#references). An example of use may be seen in the [Changing Request Headers](#changing-request-headers) example. Mandatory: No Default: No additional headers #### scenarios > scenario > stages > stage > successCriteria This configuration section allows the response to be checked against a set of criteria. This will determine whether the scenario and stage show as OK or FAILED in the dataview. ##### scenarios > scenario > stages > stage > successCriteria > responseCodes The response codes specify the acceptable responses given by the server. These are all three digit codes. The first digit specifies the type of response, and the other two digits provide more detail. 4xx codes are problems with the request, such as specifying a URL for a file that doesn't exist. 5xx codes are server errors, when a problem occurred trying to fulfil the request. A full list of the response codes and their meanings can be found in RFC2616 [References](#references). Mandatory: No Default: All codes in the 100 to 399 range ##### scenarios > scenario > stages > stage > successCriteria > maxDuration This specifies the maximum amount of time the stage is allowed to run for. If this time is exceeded then the stage will be TIMEDOUT and any remaining stages in the scenario will be SKIPPED. The scenario will then show FAILED. Mandatory: No Units: Seconds Default: Unlimited ##### scenarios > scenario > stages > stage > successCriteria > response Can check the response from the server for various different conditions ##### scenarios > scenario > stages > stage > successCriteria > response > expression The expression defines, using Boolean and/or/not logic, which of the conditions need to be met in order for the server response to be valid. For example, you may define a page content condition called 'failed' which matches against the text 'login failed please try again' and then the expression would be: not "failed" Right clicking on the expression editor will bring up a menu that gives access to the available operators, and also provides some common templates for expressions that may be used. ##### scenarios > scenario > stages > stage > > successCriteria > response > conditions Allows the various different conditions to be specified. These can then be used in the expression above to define the criteria under which the response matches. ##### scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent The page content checks look at the actual page - the text that would be seen in a browser's 'Show Page Content' or 'View Page Source' options. ##### scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > string Checks the page content against an exact piece of text. ##### scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > string > text The actual text to match against Mandatory: Yes ##### scenarios > scenario > stages > stage successCriteria > response > conditions > condition > type > pageContent > match > string > caseSensitive Whether to perform a case sensitive comparison. Case sensitive comparisons will be slightly quicker, so if the case of the text you are looking for is not going to change then this is the best option. Mandatory: No Default: true ##### scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex **Geneos PCRE2 upgrade** Beginning with version 7.3.x, Geneos now uses `PCRE2 10.44` by default, upgrading from `PCRE 8.44` for improved handling of regular expressions. Please be aware that this may introduce breaking changes to your implementation. For more information about the differences, refer to the [PCRE2 documentation](https://www.pcre.org/current/doc/html/pcre2compat.html). Checks the page content against a regular expression. ##### scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex > data > regex **Geneos PCRE2 upgrade** Beginning with version 7.3.x, Geneos now uses `PCRE2 10.44` by default, upgrading from `PCRE 8.44` for improved handling of regular expressions. Please be aware that this may introduce breaking changes to your implementation. For more information about the differences, refer to the [PCRE2 documentation](https://www.pcre.org/current/doc/html/pcre2compat.html). The perl-compatible regular expression to use. Example: ``` a.\*b ``` Mandatory: Yes ##### scenarios > scenario > stages > stage > successCriteria > response > conditions > condition > type > pageContent > match > regex > data > flags This a set of zero or more regex flags which can affect how the regex is applied to the contents of the web page. For example if 'i' is specified then the web page contents is considered in a case-insensitive manner when the regex is being applied to it. Any of the following flags may be specified:

Setting	Description
i	Case insensitive
s	A dot should match all characters when applying the regex. This is required if the expression will span several rows since a dot will not match newline characters by default.

Mandatory: No Default: All flags are false #### scenarios > scenario > stages > stage > dataTransfer If a page downloads correctly and passes all the success criteria then the content may be exported for other samplers to read, such as EXTRACTOR. The purpose of the web-mon plugin itself is to allow the server/app to be checked to ensure that it is returning pages. In contrast, the data transfer may be used, for example, to display the page content in a separate dataview so that the figures displayed can be monitored by Geneos. The name selected does not have to match anything else in the web-mon plugin, however: - The name must match the name used in the sampler reading the data. - It must be unique on any particular Netprobe - if multiple instances of the same web-mon sampler are used on the same Netprobe (through use of different Managed Entities or Types) then variables must be used to make it unique. If web-mon is only present to provide other samplers with information and you do not wish to see the status of the pages being retrieved, then once it has been set up you can prevent it being shown by setting the 'Publish' option to false in the Visibility tab of the Sampler configuration section. Mandatory: No Default: The page content is not exported. ## Additional Configuration Information This section provides additional configuration information needed to use certain features of this plug-in. #### Authenticating with Kerberos **Note** Kerberos authentication for the Web-Mon plugin is only supported on Linux platforms. Before setting the plugin to use Kerberos authentication to connect to a web server, the client machine must first acquire a Kerberos ticket-granting ticket from that web server. The following guidelines describe how to acquire the Kerberos ticket: ##### Verify the Kerberos realm Verify that the Kerberos realm of the web server is defined in the Kerberos configuration of the client. The configuration file is located in `/etc/krb5.conf`. Below is an example of the realms section of the configuration file: Example realms definition in krb5.conf ``` [realms] EXAMPLE.COM = { kdc = kerberos.example.com:88 admin_server = kerberos.example.com:749 default_domain = example.com } ``` Check that the realm of the web server is defined with the corresponding names of the `kdc`, `admin_server`, and `default_domain`. After verifying the Kerberos realm, you can follow any of the options below to set up the Kerberos ticket generation: - [Generate the Kerberos ticket-granting ticket for an authorized user](#generate-the-kerberos-ticket-granting-ticket-for-an-authorized-user) - [Set up the Kerberos principal and keytab on the sampler](#set-up-the-kerberos-principal-and-keytab-on-the-sampler) ##### Generate the Kerberos ticket-granting ticket for an authorized user 1. Generate the Kerberos ticket-granting ticket for an authorized user and store it in the default location. This can be done by running `kinit ` on the command line. Enter the password when prompted: ``` # kinit user@example.com ``` 2. Run `klist` on the command line to view the generated ticket. Verify that ticket is stored in the default location, `/tmp/krb5cc_0`: ``` # klist ``` When using this method, consider the following limitations: - The ticket has a finite lifetime and the client machine will need to regenerate it once it expires. The lifetime of a ticket is controlled by the Kerberos Key Distribution Center (KDC) of the web server, which issues the tickets. The default expiration is typically set to 8 or 10 hours, but can be configured to a longer duration in the KDC. Ticket renewal polices can also be set between the web server and client. Consult your web server administrator on how to configure ticket lifetime and renewal. - The plugin requires that the client machine generate the Kerberos ticket-granting ticket from the corresponding web server and store it using the default file setting. The plugin does not generate the ticket on its own and only looks for it in the default location when performing the authentication. ##### Set up the Kerberos principal and keytab on the sampler Beginning Geneos 5.6.x, you can set a Kerberos principal and keytab on Web-Mon samplers running on Linux x64 platforms. This facilitates automatic Kerberos ticket renewal. If you have a Kerberos principal, you can set it up on the sampler for Kerberos authentication. The Kerberos options can be found in the **Advanced tab > GSS-Negotiate**. For more information, see [GSS-Negotiate](#gss-negotiate). ## Examples This section provides more detailed examples possible uses of this plug-in. ### Simple Server Status Monitoring If the requirement is just to check that a particular server is up, then no scenarios need to be configured. The plug-in will make requests for the default server page ( / ), or the serverUrl (if provided), and use this to decide on the server status. ### Checking Simple Pages If there are pages that need to be available on the server, these may be configured as single stage scenarios. One scenario would be written for each page, as the requests do not have to happen in any particular order. The plug-in would try and access all these pages simultaneously to minimise the time taken to perform a sample. Since each scenario only has one stage, the display should probably be set to SUMMARY. ### Checking Secured Pages If a login is required to view pages, scenarios may be configured with the login page as the first stage, and the page to check as the second stage. Query variables can then be used to pass the username and password to the login page. To find out the query variables that need to be used, it is necessary to look at the source of the login page. This would look something like this: ``` ... ... ``` In this case, the URL should be set to **/site/login.php**, and the query variables needed are **username** and **passwd**. Depending on how the login was written, it may require other name/value pairs to be set. It may require hidden variables, like this: ``` ``` or the submit button, like this: ``` ``` It is also worth checking the request method, which will also be part of the form definition: ```

``` The method (either GET or POST) can be set as part of the request data for the stage. ## Checking Security of Pages It is also possible to ensure that it is **not** possible to access pages that have been secured behind a login. In this case, a single stage is needed that accesses the secured page. The acceptable responseCode should then be set to 403 (Forbidden). The scenario will then be successful if it is not possible to view the page. Another similar test would be to visit the login page first, but deliberately enter in an invalid username/password. ### Changing Request Headers It is possible to change the headers that get sent as part of the request. One possible use would be to change the User-Agent if the same URL is used to serve pages for different browsers, or for a browser and a PDA. In this case scenarios could be set up with a User-Agent requestHeader of: ``` Mozilla/4.0 (compatible; MSIE 6.0; Win32) ``` and another with ``` Nokia6630/1.0 (2.39.129) Series60/2.6 Profile/MIDP-2.0 Configuration/CLDC-1.1 ``` That would allow the responses to be compared for Internet Explorer 6 and a Nokia 6630 mobile phone. User-Agent strings for common browsers and wireless devices can be found on the Internet. ## References RFC2616 - Hypertext Transfer Protocol - HTTP/1.1 RFCs are "Request For Comments" documents and each system used on the Internet has one that describes exactly how to use it. The documents are all numbered and are hosted many places on the Internet. RFC2616 can be found by performing a search for "RFC2616" in any search engine. ## Known Issues **IPv6 with NTLM** In a few cases timeout issues have been seen when using NTLM authentication with some types of IPv6 environments. If you experience any issues, contact [ITRS Support](mailto:support@itrsgroup.com) .