Trusted Contributor.. bwcole Trusted Contributor..
Trusted Contributor..

Re: SiteScope 11.33 - Skip monitors - research and corrections

Dasomm,

Thank you for your response.

 

I haven't thought about moving the dependency since there are several hundred ping monitors within the ping group and I'm not very well versed in using templates for mass updates.  With those two, and this occurring in our production environment, I would need to try to recreate this behavior in our test environment.

I would have already tried to recreate this issue over in our test environment, but we are almost done with our install/upgrade of 11.51 and that has been an adventure/trial.

Guess I need to read up on how to use a template to do mass updates, and then attempt to build a model over in our test environment.  Hopefully in doing so, recreating this strange behavior then using templates update the ping monitors.

Thank you,

Billy

 

0 Likes
Honored Contributor.. dasomm Honored Contributor..
Honored Contributor..

Re: SiteScope 11.33 - Skip monitors - research and corrections

Yes, sometimes the work load is too high to "delve into" all the different functionality.

But when you can set aside some time you should definately look into how to create templates and deploy them using csv files. That way you can easily do mass deploy of new monitors and mass changes to already deployed monitors.
To create a csv file from the ping monitors you already have, run a monitor report on the ping group, choose the columns you need and save it as a csv file. 

0 Likes
Trusted Contributor.. bwcole Trusted Contributor..
Trusted Contributor..

Re: SiteScope 11.33 - Skip monitors - research and corrections

Thank you dasomm.

 

Micro Focus support basically came back with the same to remove the set dependency of the ping group and set the composite monitor as the dependency on each of the 200+ ping monitors directly.

While this sound feasible, this is only occurring in production and is not the representive of the settings we currently have.  Changing over 200+ ping monitors to test something in production is a pretty hard sell.

On review of our use of composite monitors, we use them in two use cases.  First is a flow limitor where we have multiple remote connection monitors (UNIX resource, Window Service State) that we want to run in a linear fashion to prevent the connection pool or the target from being over loaded. 

The second case, is as a multiple dependency container.  The only dependency container composite that we have, is having this issue.  It is the only dependency container composite within our implementation.

Has anyone else used a composite to work around a monitor being dependent on a single monitor?

Thank you,

Billy

 

 

0 Likes
Trusted Contributor.. bwcole Trusted Contributor..
Trusted Contributor..

Re: SiteScope 11.33 - Skip monitors - research and corrections

Update

If the composite that contains the two DNS monitors, composite Settings, "Run Monitors" is unchecked and the two DNS monitors's runtime setting - frequency is set to 4 minutes.  The two DNS monitors run every 4 minutes.

The Composite, however runs at varying times which appear to be caused by the monitors with the "Ping" group (over 200 ping monitors with run frequencies of 1, 3, 5, 10 minutes).

We use composites within two use cases, a resource sequence and a multi-dependency.

For the resource-sequence use case, we have a target server with multiple Unix Resource or Windows WMI monitors.  We set the monitors for a specific server in a composite so the monitors will run one after another and not all at once, limiting the connection usage.

The second, multi-dependency, since a monitor or group can only be dependent on a single monitor, we use a composite to contain the multiple dependencies.  In this case we have two DNS servers and at least one has to be in good status before we run the over 200 ping monitors.

In the multi-dependency, if we set the composite to run the contained monitors, we found that when the monitors that are configured to be dependent on the composite requests state, the composite will run the contained monitors.

So it appears that a composite used as a dependency container, when queried for state, will actually run the contained monitors if the "Run Monitors" check box is checked.  If this box is unchecked, the composite will "Check" the contained monitors for most recent status.

While this behavior does help with reducing the number of runs on the two DNS monitors, the composite runs quite often but appears to be only checking the most recent state of the two DNS monitors.

 

We will run this configuration for a while to see if we see any additional skips on the composite monitor.

 

Hope this helps,

 

Billy

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.