Forum Replies Created
As per screenshots you shared, the CI pattern provided is (?<=EM Event.*-.*).*?(?=-.*)
Ensure that you do not have * or + quantifier inside a lookbehind regex section.
A more appropriate regex pattern would be (?<=EM Event: Fatal:)\w+
Use this as a reference to create the CI pattern and retry.
As a thumb rule validated your regex in regex101.com
3 years, 1 month ago in reply to: ignio AI.OPs Event Management to pull alerts from Solman and update Solman post #3262::
- This reply was modified 3 years, 2 months ago by vilok0806.
You might want to post this question in the ERPOPs group. There must be an adaptor that can be used to get alerts from Solman and additionally update the Solman alert after performing event mgmt (suppression, aggregation, self-heal)2 years, 11 months ago in reply to: How to Extract CI ? ( which has multiple key attributes ) #3454::
Entity search from blueprint will be based on the caption of that entity, which usually has one key identifier. So Jboss server entity will have its name as the caption, if you extract this name from the alert, then it would get used for searching in blueprint.
If the entity is not present in blueprint, we copy the extracted name to both the key identifiers which may not be the right thing, but at least the fault will be processed.::
1. First check the log view of the process fault workitem and investigate each of the child workitems checking which one took most of the time.
2. It is possible that there some fix action that took time to complete.
3. If none of the child workitems have taken time, check if there is any wait configured on check fault or fix action. In 2.6.0 release onwards waits are configured in “Self Heal Configuration” policy. For pre 2.6.0 release, there are separate policies – “Wait before self heal” and “Wait check fault before fix”::
In earlier versions, we had a wildcard search on entity resolution. But it has the disadvantage of searching incorrect entities and hence leading to incorrect entity getting mapped
For this specific scenario of yours, I would recommend attaching the domain name to the root entity either in pre-processing or field mapping script to make it match the actual blueprint name. The root entity type can be given – you can give exact type like RHEL7/8::
There must be some information in the alert either in description or some field which indicates dev or prod. Without this you can not use a BP api to find the actual root entity.
So you can use this additional info in the alert which differentiates dev or prod, and create a proper root entity name. It can be case insensitive.
Let me know.::
We cannot avoid check functions on faults in the influencer map/path. But we can avoid performing fixes on it. SP6 onwards, the self-heal configuration can be used to customize fix for self heal flow of a specific fault/entity.
Let me know if this works out for you.3 years, 1 month ago in reply to: Out of box Health check process fault not executing #3284::
Process fault (pattern) will invoke check faults (aka health checks) on influencing entities while triaging. If the required blueprint topology is present health checks will get invoked.
Health check is slightly separate use case, it is purely checking and detecting faults. So you can trigger it on-demand or schedule it. Whereas Process fault is in response to an issue attempting to triage/resolve it.
If you want to resolve a fault that is detected during HC, you can configure it by setting the “Fault Triage policy”3 years, 1 month ago in reply to: Out of box Health check process fault not executing #3286::
I got it mixed with process fault while you wanted to trigger HC on a windows process.
You can blueprint the process entity, process name is the key which I believe will not change. You can schedule HC on it (Actions –> Check Health).::
We will support wildcard search in SP6 Patch 1. The logic will be as follows
1. If the wildcard search results in exactly one record, that CI will be used.
2. If the search results in more than 1 record, then the exactly matching entity (case insensitive) will be used. If none found, then a new CI mentioned in the root entity field will be used.
In your case, you will only have one entry – either Win1vp.eeaus.com or Win1vp.ie.integral.com.au. So you should have the root entity specified as Win1vp, it will pick the one which is present in the blueprint and continue processing.
If more than one record found in BP, this will be an ambiguous situation. The alert will not be lost, instead, a new CI Win1vp will be created and the alert will be processed.
Hope this will resolve your scenario.
We had removed wildcard search in SP6 because of the ambiguity, but we will bring it back and in ambiguous situations use the input root entity.3 years, 1 month ago in reply to: Out of box Health check process fault not executing #3296::
I believe you meant blueprinting the entity and not modelling it. There is an OOB entity named OSProcess.