F5 extension alerts

[Theodore_x86]

Hello.

We have deployed the F5 BIG-IP extension and we enabled the relevant extension alerts.

Since the alerts are based on metrics like this one:

com.dynatrace.extension.f5.bigip.virtualserver.state

General state metric for the server. Value is always 1, but dimensions carry all details of a virtual server.

and the alerting condition is above threshold of 0, then the problem remains open indefinitely.

Has anyone ever wondered what is the meaning of such alert configuration?

Thank you.

[p_devulapalli]

@Theodore_x86 Form my understanding virtual server state would not always remain 1 , it would switch between different states as below depending on the condition . Usually  green(1) is considered available and anything that's not green(1) is being considered as unhealthy . My assumption is that in Dynatrace = green(1) would be the threshold for healthy and any state other than green(1) is unhealthy

 F5-BIGIP-LOCAL-MIB::ltmVsStatusAvailState."/Common/VS_TEST"
    ltmVsStatusAvailState OBJECT-TYPE
      -- FROM       F5-BIGIP-LOCAL-MIB
      SYNTAX        INTEGER {none(0), green(1), yellow(2), red(3), blue(4), gray(5)}
      MAX-ACCESS    read-only
      STATUS        current
      DESCRIPTION   "The availability of the specified virtual server indicated in color.
                    none - error;
                    green - available in some capacity;
                    yellow - not currently available;
                    red - not available;
                    blue - availability is unknown;
                    gray - unlicensed."

[Fin_Ubels]

Hey @Theodore_x86 

I just went and had a look at one of these alerts in an environment and the one I found using that metric was filtered for undesirable states as seen below and so it should only remain open while the state is undesirable and not indefinitely. If the state was green then it shouldn't alert. I also tried adding the extension to a different environment and found the same filtering in place on the alert.

Do you have a specific example of an alert using that metric but without filters? Could it be that the alert was modified or the extension is out of date?

[Theodore_x86]

Hello! Thank you both @p_devulapalli and @Fin_Ubels for your replies on this.

In our environment, the metric is always 1, so the alert is present all the time making it useless.

@Fin_Ubels, to my understanding, the metric will present with value=1 as long as there are undiserable states and will present with no data when those states do not exist (all states in GREEN).

The question is why the alert is not defined per virtual server entity and trigger an alert for every virtual server (there would be a flood of those, I know). A constantly open alert loses its integrity.

Thank you.

[Fin_Ubels]

Hey @Theodore_x86 

Looking at the alert again it appears to not have a :splitBy defined which should cause it to be split by every dimension available on the metric. I have tested this in an environment as seen below. When charting the metric selector used for the alert it's split by every dimension even though :splitBy is not defined in the metric selector.

Looking into this in another environment in more detail, the metric should always report "1" as the value regardless of the state of the F5 server. It then carries dimensions which contains information about the state. In the above alert definition it filters for just problematic states. This means that if you are getting an alert based on this metric it should be a correct alert suggesting that a F5 server is in an undesirable state. 

If your metric event setting for this alert is different than the one I showed then likely it's custom or someone modified the out of the box one. Would you be able to provide screenshots or more specific examples of whats happening?

[Theodore_x86]

Hello @Fin_Ubels 

What happens on the F5 monitored by Dynatrace is that an alert is raised when virtual server is down (as it should), but after some time (minutes) another virtual server is DOWN and this does not creates a new problem. It simply changes the "Impacted By" field with the new virtual server. So the same problem remains open indefinitely while constantly changing the relevant Virtual Server entity. Not to mention that the "virtual server" name is not changing on the Description field of the problem, it shows only the 1st impacted entity.

This behavior makes difficult for the administrator to monitor properly the F5.

I will try to add the dimension on the entity selector of the problem to see if there is any difference. I am just wondering why it is configured that way (all in one metric).

BR

[Fin_Ubels · Accepted solution]

Hey @Theodore_x86 

Ah ok, I better understand the issue now. Looking in the Demo environment, because it splits by every dimension it shares the "F5 Instance name" dimension and so yes, it would join the alerts if they shared an F5 Instance. This could also be caused by other dimensions, I just used that one as an example.

I am not sure why it's set up this way by default, but if it isn't working for you then there are a couple of options to fix it. The first would be to change the metric selector to split by specific dimensions, for example changing it to only split by virtual server instance. The other option would be to disable the merging option as seen below. That should stop it from merging the problems allowing them to open and close independently.

[Theodore_x86]

Yes @Fin_Ubels , the "Allow merge" button did the trick (disabling it).

Now, we have a problem per F5 virtual server entity.

I guess the same could happen by splitting by the entity on the entity selector field, but with the  button is much easier way.

Thank you!