Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Smarts SAM: How is the hyper notification driver used for Notification List (NL) functions? What is the processing sequence of the hyper notification driver for alarms between SAMs? (304575)

Last Updated: 12/17/2018Categories: How toTotal Views: 2701Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Resolution

1.) How is the hyper notification driver used for Notification List (NL) functions? What is the processing sequence of hyper notification driver for a durable and momentary alarms between SAM, how it decides to make notify or clear or changed operation on the alarm, when hook script is called etc.

2.) What kind of change (ex: difference in lastchangedat, lastnotifiedat oroccurancecount between lower domain and upperdomain) on lower domain will trigger notify,change,clear operations on the upper domain? How this is decided for Durable and Momentary alarms?

3.) Is there a way to subscribe with the domain the way how hyper notif driver does? (like we do sm_adapter --subscribe=<NL>/n)?

1.) How is the hyper notification driver used for Notification List (NL) functions? What is the processing sequence of hyper notification driver for Durable and Momentary alarms between SAMs? How does the hyper notification driver decide to make notify or clear or changed operation on the alarm, when hook script is called etc.

The HyperNotif driver will propagate Notify, Change, Clear and Delete from source as is.

If present, a hookscript will be executed to update some of the attributes before finally notifying to the user  (NL_CLEAR, NL_NOTIFY and etc.).

The calls of notify, change and clear are purely called based on the message type of the notification and not based on the hookscript.

NOTIFY means there is an event at the underlying domain and that comes to SAM as a new event (whether it is earlier present or not) and that will be converted into new notification with NOTIFY message type and propagated to its clients from that SAM. If it is DURABLE notification it is expected that these notifications follows some life cycle of the notification being active and cleared at later point of time.

Some notifications are caused by durable events. A durable event has a measurable duration; it is active for a period of time (for example, a link failure).  Durable events are sent from underlying Smarts Managers.

Other notifications are caused by momentary events. A momentary event occurs and is significant for only a specific point in time (for example, an authentication failure event for a device).
Generally momentary notifications gets keep notified in case of persistent issues. During that time SAM will process this notification and keeps updating the LastNotifiedAt based on the receive time.

2.) What kind of update (ex: difference in LastChangedAt, LastNotifiedAt OccuranceCount) on lower domain will trigger notify, change, clear operations on the upper domain? How this is decided for Durable and Momentary alarms?

Any changes in the notification object which is considered as change event in SAM itself(Once the notification notified and post that any change to the notification attributes during its active duration always considered as CHANGE event). These CHANGE events always not necessary to come from underlying domain. Generally it happens to originate from the first level SAM based on the user action or scripts to change the notification attributes.

Any change in attributes irrespective of Momentary or Durable will be notified as CHANGE to the subscriber. Specifically attributes like Active is decided for Notify or Clear based on the even received from underlying domain.
In case of HyperNotif, all notify and change comes with the same message type as NL_Notify_V2. SAM internal logic will detect whether notify or change and take appropriate calls at the subscribed SAM. If you would like to understand how these notification types are processed, refer ics-nl-processing.asl.

3.) Is there a way to subscribe with the domain the way how hyper notif driver does? (like we do sm_adapter --subscribe=<NL>/n)?

There is no provision to subscribe for hypernotif. If users want to it, then they need to write a C++/Java client to the server, poll, get the notification and process from there.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

No results for undefined

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

Related Versions:

VMware Smart Assurance - SMARTS

Take Our Survey

Support Assistant