Since your custom service is already being discovered successfully using the MySer.* regex, the next step is to create an alert based on the service object's availability/status, rather than on the regex itself.
In Aria Operations, I would approach it this way:
- Go to Configure > Alerts > Symptom Definitions.
- Create a new Metric Symptom and select the object type associated with the discovered/monitored service.
- Select the service availability metric, typically System > Availability where available.
- Configure the condition so the symptom becomes critical when availability is down. Aria Operations uses the convention 1 = available/up and 0 = unavailable/down. Broadcom documents this availability behavior for monitored objects.
- Go to Configure > Alerts > Alert Definitions and create an alert such as: Custom MySer Service is Down
- Add the symptom you created and configure the desired severity and wait/cancel cycles.
- Finally, verify that both your custom Alert Definition and Symptom Definition are activated in the policy assigned to the service objects. A custom alert can be configured correctly but still not trigger if it isn't enabled in the active policy.
You may also want to use a wait cycle of 2–3 collection intervals so a brief service restart doesn't immediately generate an alert.
One important point: Service Discovery requires the custom service to be associated with a listening TCP/UDP port. Since your regex-based definition is already discovering the services, it sounds like you've satisfied that requirement.
If you open one of the discovered MySer.* service objects under Inventory and share the exact Object Type and the metrics shown under Metrics, I can suggest the exact symptom condition to use rather than guessing which availability metric your Aria Operations version exposes.