Montioring PI Notifications

Hi Cedric

Please find the list of performance counters available for PI Notifications : Highlighted few peformance counters which will be helpful to monitor. Would suggest you to create PI Vision dashboard and AF analysis to check if counter is active or stale.

Reference : PI Server

Escalations in Progress

Number of active escalation teams in progress.

Escalations Scheduled

Number of escalation events scheduled since the start of the PI Notifications Service.

Event Frame Changes Observed

Number of event frame changes received from the AF server since the start of the PI Notifications Service. Changes received cause notification instances to start, end, and change state.

Failed Sends

Number of failed send attempts since the start of the PI Notifications Service.

Failed Sends / sec

Rate of failed send attempts per second. This counter displays the difference between the values observed in the last two samples divided by the duration of the sample interval. This counter is not an average over time.

History Updates

Number of history updates written since the start of the PI Notifications Service. History updates include state changes, sends, resends, and escalations events.

Last Update Change to Process Time

The number of milliseconds the last online change item took to process since the time the change was made in the PI AF server. This counter is updated every time the service completes processing an item.

Last Update Receipt to Process Time

The number of milliseconds the last online change item took to process in the PI Notifications Service from its receipt time. This counter is updated every time the service completes processing an item.

Notification Rules in Error

Number of notification rules in error in the PI Notifications Service.

Running Notification Rules

Number of running notification rules in the PI Notifications Service.

Sends in Progress

Number of send attempts currently in progress.

State Changes Observed

Number of notification state changes recorded since the start of the PI Notifications Service. This includes state changes that may not have caused sends because the notification went into a lower state or was within the non-repetition interval.

Stopped Notification Rules

Number of stopped notification rules in the PI Notifications Service.

Successful Sends

Number of successful send attempts since the start of the PI Notifications Service.

Successful Sends / sec

Rate of successful message sends per second. This counter displays the difference between the values observed in the last two samples divided by the duration of the sample interval. This counter is not an average over time.

Total Sends

Number of attempts to send messages to subscribers since the start of the PI Notifications Service.

Total Sends / sec

Rate of attempts to send messages to subscribers per second. This counter displays the difference between the values observed in the last two samples divided by the duration of the sample interval. This counter is not an average over time.

Total Updates Processed

The number of total changes received from the PI AF server since the start of the PI Notifications Service. This is the number of changes the PI Notifications Service has processed from AFSDK'sFindChangedItemscalls.

Total Updates Processed / sec

Rate of total changes processed from the PI AF server. This counter displays the difference between the values observed in the last two samples divided by the duration of the sample interval. This counter is not an average over time.

Thanks,

Lal

Hey Cedric,

As a friendly suggestion I would also monitor the PI Analysis Service if your event frames are being generated by this application.

As you know Notifications are triggered off Event Frames, so if there is an issue with the application generating those Event Frames, those Notifications will not be sent out.

You can find the performance counters for Asset Analytics here: PI Server

I would be cautious with the logic to avoid false positives. For example, the Maximum Latency counter returns the highest current lag for a specific analysis group. There may be one poorly performing group while all others are performing well. You wouldn't want to notify users for this type of issue. However, you could monitor the maximum latency over a period of time, and if it is continuously increasing then there might be a more serious performance issue. Or, if you have an idea of the Event Frame written rate, you could monitor the Event Frame written counter and if that number stops increasing (or increases at a much slower rate) then there might be an issue.

Let us know if you have any follow up questions!

Thanks,

Seb

Check out Topview Free and you can monitor the perfmon counters for free and not have to support code/powershell. You can make VOIP calls, do escalation and more if needed.