Update: Alert Correlation in FRUN by resmi.ks
Newly imagined Alert Management within FRUN, open to integration at both Inbound and Outbound, insightful and responsive user interfaces. Part 2 includes Open Alert List and Alert Search, most common actions on multiple alerts at one go.
In the Part 1 of this series, we talked about the purpose of AEM within FRUN. We briefly touched upon the very basics of Scope selector and the Unified Shell that are meant for all applications of FRUN. More related to this series, we then looked the at the Overview Page of AEM and mooted on its objective, its powerful Visual Filters. Let us now get onto the part 2.
One could navigate to the page containing the Alert list by directly jumping to the page from the respective menu on the left-hand side panel of the Shell. In this case, all Open Alerts related to the Scope would get listed. Or, as discussed earlier, clicking on any of the visual filters takes the user to the page containing the list of Alerts that matched the filter-condition, within the Scope.
As one would expect, a list is a list. Or, is it a bit more?
The small color strip on left tells us about the Current Rating (Red, Yellow, Green, or none) of the Alert, whereas the “Worst rating” is visible in another column.
Icons by the side of the Alert Names tell us about the broad Category (Availability, Performance, Exception, Configuration and so on) of the Alert.
Managed Object Types (Database, Host, Technical Instance, Technical System, Firewall, External Service, and so on) are shown by respective icons by the side of the Managed Object Names in another column.
Name of the Customer (of the service provider) which the Managed Object belonged to is also visible in another column.
Some of the Alerts in the example list has a processor assigned.
The list is by default sorted by Priority (Very High, High, Medium and Low) for the alerts whose current rating is known. Priority is a function of the Current rating and Severity of an Alert.
Of course, we may make the list look different, once we discover those few buttons at the top-right corner of the list. We may --
The buttons on the top of the list tells us that we may take one or more of few actions on one of more of the alerts from the list, at one go.
Following are some example screenshots of how these are performed, should be self-explanatory.
A little more on the intended purpose of "Postpone":
Postponement, however, does not change any data related to the Alert life cycle, such as the Alert creation time, or, if the rating changed from Critical to Warning (or other way round) and so on. It of course adds action logs that the alert was postponed, or, the postponement was cancelled and so on.
In case it becomes interesting to know what all actions occurred for an Alert, after few hours of days it was created, we could select it and pull up the menu “Show Logs” to get a basic view including the date & time of each action, what was the action about and who initiated the same and so on, such as shown below:
On the Alert list, we might have observed that each Alert name is a clickable link. Clicking on this is how we would navigate and get to see the detail of an Alert. Upon click, the list does not disappear totally, but rather collapses to left with only two most important columns remaining visible, while the rest of the screen space to the right shows the detail of the alert that was clicked upon. At any point in time, it would be possible to expand to the full list view again. The Alert-detail screen may be opened in a new window, by using the respective menu from the available “Actions”.
We would investigate the details of a single alert later in the Part 3 of this series. In continuation of the theme of this part, let us discuss on yet another useful way of arriving at a list of alerts.
We have seen the possibility to view a list of alerts in two ways so far. One was to click / tap on any of the visual filters from the Overview page, which took us to the list of alerts that matched the filter condition. Second was to directly navigate to the Alert List page. In both the cases, we looked at list of “Open” or “In Process” alerts.
What if we wanted to view alerts irrespective of if the alerts were in status “Open / In-Process / Confirmed”? What if we were looking for one or more of the alerts that occurred in a known time-window, or with some other known attributes?
We would, for such situations, use the page “Alert search”. We observed already that AEM includes a dedicated default page for alert search.
It includes the Status (Open / In Process / Confirmed) of alerts in a dedicated column, as the resultant list of alerts after a Search could fetch alerts in any status.
On this page we would find a free-text search bar that works on most common attributes of alerts such as the name of Alert and / or Managed Object and / or Processor, if any. This proves a handy alternative to using strictly typed filter conditions.
The page offers a set of filters as well.
It still works within the application Scope, indeed.
Rest of the look-and-feel and navigation on the list of alerts in this page is nearly same as that of “Open Alert list” page.
This separate page of “Alert Search”, which works on “Confirmed” alerts together with Open / In Process alerts may look an overkill at times. On a second thought, alert processing is more operational, daily work. Overview page, and Open Alert List pages are useful there. Searching for one or more alerts indicates some analytical purpose and being able to narrow down the window of search before viewing the list seems worth it.
And of course, Alert Search may go hand-in-hand with “Alert reporting” – we would look into this in Part 4 of this series.
Newly imagined Alert Management within FRUN, open to integration at both Inbound and Outbound, insightful and responsive user interfaces. Part 2 includes Open Alert List and Alert Search, most common actions on multiple alerts at one go.
FRUN AEM Part 1 | Part 2 | Part 3 | Part 4 | Part 5
In the Part 1 of this series, we talked about the purpose of AEM within FRUN. We briefly touched upon the very basics of Scope selector and the Unified Shell that are meant for all applications of FRUN. More related to this series, we then looked the at the Overview Page of AEM and mooted on its objective, its powerful Visual Filters. Let us now get onto the part 2.
Open Alert list
One could navigate to the page containing the Alert list by directly jumping to the page from the respective menu on the left-hand side panel of the Shell. In this case, all Open Alerts related to the Scope would get listed. Or, as discussed earlier, clicking on any of the visual filters takes the user to the page containing the list of Alerts that matched the filter-condition, within the Scope.
First look at the Open Alert list
As one would expect, a list is a list. Or, is it a bit more?
The small color strip on left tells us about the Current Rating (Red, Yellow, Green, or none) of the Alert, whereas the “Worst rating” is visible in another column.
Icons by the side of the Alert Names tell us about the broad Category (Availability, Performance, Exception, Configuration and so on) of the Alert.
Managed Object Types (Database, Host, Technical Instance, Technical System, Firewall, External Service, and so on) are shown by respective icons by the side of the Managed Object Names in another column.
Name of the Customer (of the service provider) which the Managed Object belonged to is also visible in another column.
Some of the Alerts in the example list has a processor assigned.
The list is by default sorted by Priority (Very High, High, Medium and Low) for the alerts whose current rating is known. Priority is a function of the Current rating and Severity of an Alert.
Customizing the list view
Of course, we may make the list look different, once we discover those few buttons at the top-right corner of the list. We may --
- Choose from among the available attributes which we want to view in dedicated columns and hide the rest
- Influence the sorting
- Use filters that work within the Scope.
Mass-functionalities on the List of Alerts
The buttons on the top of the list tells us that we may take one or more of few actions on one of more of the alerts from the list, at one go.
Common actions on list of alerts
- Confirm the Alert(s), if the underlying issue(s) is / are believed to be resolved.
- Postpone
- Assign or change a processor.
- Classify and / or Categorize the alerts based on their business impact and / or nature of root problem, respectively.
Following are some example screenshots of how these are performed, should be self-explanatory.
A little more on the intended purpose of "Postpone":
There could be some such alerts appearing, the reason and possible resolution of which are known to the alert processors, but the alerts are not yet possible to resolve and confirm. In case there is an alert that occurred due to short-fall of some hardware resource, just for an example, where the necessary hardware has been ordered for procurement already, but the item is expected to be received only after a few days. In this case, the alert processor does not want to keep viewing this alert in the list until such a known length of time. But once the hardware is replaced / added, he / she expects that the cause of the Alert would automatically cease to exist. It is in these situations, Postponing could be a better option than either keeping the alert visible or trying to prematurely “Confirm” it. In case the time-period of postponement has elapsed and the “Cause” still existed, the Alert would reappear in the list. This would thus work as a reminder to the responsible alert processor. And in case the item was received earlier than expected, one may cancel the postponement anytime.
How to cancel a postponement? Try the button on top of the list, rest is for us to self-explore.
Postponement, however, does not change any data related to the Alert life cycle, such as the Alert creation time, or, if the rating changed from Critical to Warning (or other way round) and so on. It of course adds action logs that the alert was postponed, or, the postponement was cancelled and so on.
Viewing Logs (action trail) of a single-alert
In case it becomes interesting to know what all actions occurred for an Alert, after few hours of days it was created, we could select it and pull up the menu “Show Logs” to get a basic view including the date & time of each action, what was the action about and who initiated the same and so on, such as shown below:
Navigation into each alert detail and back
On the Alert list, we might have observed that each Alert name is a clickable link. Clicking on this is how we would navigate and get to see the detail of an Alert. Upon click, the list does not disappear totally, but rather collapses to left with only two most important columns remaining visible, while the rest of the screen space to the right shows the detail of the alert that was clicked upon. At any point in time, it would be possible to expand to the full list view again. The Alert-detail screen may be opened in a new window, by using the respective menu from the available “Actions”.
We would investigate the details of a single alert later in the Part 3 of this series. In continuation of the theme of this part, let us discuss on yet another useful way of arriving at a list of alerts.
Alert Search
We have seen the possibility to view a list of alerts in two ways so far. One was to click / tap on any of the visual filters from the Overview page, which took us to the list of alerts that matched the filter condition. Second was to directly navigate to the Alert List page. In both the cases, we looked at list of “Open” or “In Process” alerts.
What if we wanted to view alerts irrespective of if the alerts were in status “Open / In-Process / Confirmed”? What if we were looking for one or more of the alerts that occurred in a known time-window, or with some other known attributes?
We would, for such situations, use the page “Alert search”. We observed already that AEM includes a dedicated default page for alert search.
It includes the Status (Open / In Process / Confirmed) of alerts in a dedicated column, as the resultant list of alerts after a Search could fetch alerts in any status.
Free text Search Bar
On this page we would find a free-text search bar that works on most common attributes of alerts such as the name of Alert and / or Managed Object and / or Processor, if any. This proves a handy alternative to using strictly typed filter conditions.
Search filters
The page offers a set of filters as well.
The most important filters could be the “From” and “To” date & time, which helps us focus on a narrower window of time, if we are dealing with vast number of alerts yet looking for those that occurred in a known window of time.
It still works within the application Scope, indeed.
Rest of the look-and-feel and navigation on the list of alerts in this page is nearly same as that of “Open Alert list” page.
This separate page of “Alert Search”, which works on “Confirmed” alerts together with Open / In Process alerts may look an overkill at times. On a second thought, alert processing is more operational, daily work. Overview page, and Open Alert List pages are useful there. Searching for one or more alerts indicates some analytical purpose and being able to narrow down the window of search before viewing the list seems worth it.
And of course, Alert Search may go hand-in-hand with “Alert reporting” – we would look into this in Part 4 of this series.
FRUN AEM Part 1 | Part 2 | Part 3 | Part 4 | Part 5
- SAP Managed Tags:
