Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE
Acclaimed Contributor.. FrankMortensen Acclaimed Contributor..
Acclaimed Contributor..
159 views

Process monitoring with various number of process instances

Jump to solution

Hi,

In OBM 10.63 IP2 on Windows, my customer has a base policy template with rules that monitors a set of standard Linux processes. The policy is included in an Aspect that is coupled to a Deployment View, by means of an AAR. One of the processes being monitored is rsyslogd. The policy creates an event if the number of ryslogd instances is different than 1.

Now the cu even have Linux servers with Docker installed on them. On these specific servers there may be more than one running instance of rsyslogd.

I want to adjust the current monitoring to this mixed environment. The servers with Docker can be identified in RTSM by means of their relation to a "Docker Daemon" CIT. My first thought was therefore to modify the current Base deployment view so that it does *not* contain servers with Docker, and then even create a second view containing only servers that *do* contain Docker. My idea was then to specify the number of requried process instances for rsyslogd in the policy by means of a parameter, and supply the value of this paramater in the two AAR's that ties the aspect to the two deployment views. Thus I could i.e. continue to use the same policy and aspect for all Linux servers.

The problem, however, is that for the general servers "one and only one" instance of rsyslogd should exist, whereas on servers with Docker there should be "one or more". This means that the two requirements cannot use the same operator in the policy (one requires "=" and the other ">="), so my plan to just use a policy parameter fails...

Any suggestions on how to solve this in the most elegant manner?

Am I forced to remove rsyslogd form our general Base policy and create two dedicated policies for this process only? I.e. one for servers with Docker and one for all other servers?

BR,
Frank Mortensen
Managon AB

0 Likes
1 Solution

Accepted Solutions
Acclaimed Contributor.. FrankMortensen Acclaimed Contributor..
Acclaimed Contributor..

Re: Process monitoring with various number of process instances

Jump to solution

Hi,

Regarding the possibility to use *different* operator-types for the same policy, I actually found a workaround to it myself. Obviously I'll leave it to each of you to determine whether it would be an acceptable solution in your environment, but I'll share it in case it is of interest to anyone.

I did as follows (Note: my policy only has one rule. If a policy has several rules, some of the steps below would probably have to be repeated, but I have not tested that in our environment):

1. Added a parameter to the policy called MonitoringMode, type Enumeration and added the tre entries <=, == and >=.

2. Saved and closed the policy. Note that the editor will ask if you want to delete the unused parameter at this stage, but answer that you do *not* want to delete it (I think you answer ignore or something, I don't remember the exact question, but the answer becomes obvious when you see the question).

3. Opened the policy in RAW-mode. Replaced the row #MonMode=== of the rule in question (the row may look slightly different at the end, depending on the actual setting in the policy) with #MonMode=%%MonitoringMode%%

4. Saved the changes.

And that's all there is to it. That change (which as you can see is actually done in a comment area) in fact silently changes the approriate code further down in the underlying policy script, when you save the policy).

When opening the policy in normal mode after this, the variable name is shown in the Operator column in the rule overview on the Rules tab. When selecting the specific rule, however, and looking at the "Number of processes" field on the Condition subtab, it will show a hard-coded "<=". You may ignore this fact. This is the only little nagging thing about this solution... As long as you don't touch this field, though, everything should work ok. I have tried to change many of the other fields in the policy, even the fields in this particular rule, and as long as I do not touch the operator field, everything is good.

Cheers,
Frank

0 Likes
5 Replies
Acclaimed Contributor.. KAKA_2 Acclaimed Contributor..
Acclaimed Contributor..

Re: Process monitoring with various number of process instances

Jump to solution

What about setting a parameter with the use of conditional values? this will allow you to set one default value for regular user case and another value based on condition for Docker installed machines.

HTH
-KAKA-

Acclaimed Contributor.. FrankMortensen Acclaimed Contributor..
Acclaimed Contributor..

Re: Process monitoring with various number of process instances

Jump to solution

Hi Kaka, 

When I have looked at the conditional parameter value option previously, I have only looked within policy templates and thus found them very uninteresting. Considering the fact that one can only specify the OS Type there.

NOW, however, after reading your suggestion, I opened one of my aspects and see that one can even create conditional parameters based on CI Type and CI attributes. 

But I am still not sure how this would solve my problem? Could you please explain? Please also note the point in my original posting regarding the need for two different operators.

Cheers,
Frank

0 Likes
Acclaimed Contributor.. KAKA_2 Acclaimed Contributor..
Acclaimed Contributor..

Re: Process monitoring with various number of process instances

Jump to solution

if you are using standard service Process monitoring policy for then different operators are causing the trouble. if you use a custom policy then operator can be part of your parameter and it can be made work.

In first case just make a copy of original policy and change operator for Docker setup and configure conditional deployment for each policy.

may be you get better idea.

-KAKA-

0 Likes
Acclaimed Contributor.. FrankMortensen Acclaimed Contributor..
Acclaimed Contributor..

Re: Process monitoring with various number of process instances

Jump to solution

Hi,

I was hoping there was a way to avoid having to pull out the rsyslogd-monitoring from the base policy and create two dedicated policies for this process, but I guess not...

Nevertheless, i have a follow-up question on your previous suggestion "set one default value for regular user case and another value based on condition for Docker installed machines". If we assume that I was not limited by the aforementioned operator type in the Service/Process mon. policy, how exactly do you suggest that I could I specify a "condition for Docker installed machines"?

I am asking because I just yesterday discovered that I had more parameter conditions available in the aspect than in the policy template per se, but I in the aspect I still only see available properties on the Node CI and not the related "Docker Daemon" CI, so I still don't quite understand how I could use this feature to achieve my goal.

I am asking because I would like to be enlightended, not because I am being sceptical :)

Cheers,
Frank

0 Likes
Acclaimed Contributor.. FrankMortensen Acclaimed Contributor..
Acclaimed Contributor..

Re: Process monitoring with various number of process instances

Jump to solution

Hi,

Regarding the possibility to use *different* operator-types for the same policy, I actually found a workaround to it myself. Obviously I'll leave it to each of you to determine whether it would be an acceptable solution in your environment, but I'll share it in case it is of interest to anyone.

I did as follows (Note: my policy only has one rule. If a policy has several rules, some of the steps below would probably have to be repeated, but I have not tested that in our environment):

1. Added a parameter to the policy called MonitoringMode, type Enumeration and added the tre entries <=, == and >=.

2. Saved and closed the policy. Note that the editor will ask if you want to delete the unused parameter at this stage, but answer that you do *not* want to delete it (I think you answer ignore or something, I don't remember the exact question, but the answer becomes obvious when you see the question).

3. Opened the policy in RAW-mode. Replaced the row #MonMode=== of the rule in question (the row may look slightly different at the end, depending on the actual setting in the policy) with #MonMode=%%MonitoringMode%%

4. Saved the changes.

And that's all there is to it. That change (which as you can see is actually done in a comment area) in fact silently changes the approriate code further down in the underlying policy script, when you save the policy).

When opening the policy in normal mode after this, the variable name is shown in the Operator column in the rule overview on the Rules tab. When selecting the specific rule, however, and looking at the "Number of processes" field on the Condition subtab, it will show a hard-coded "<=". You may ignore this fact. This is the only little nagging thing about this solution... As long as you don't touch this field, though, everything should work ok. I have tried to change many of the other fields in the policy, even the fields in this particular rule, and as long as I do not touch the operator field, everything is good.

Cheers,
Frank

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.