Alarming if Persistent Connection fails?

[Turbo]

Greetings, all:

I'm running Mango 3.7 right now:

I'm wondering why my Mango Persistent TCP Tunnels don't seem to show alarms. I've got the "Event Alarm Levels" set for Urgent and Urgent for both Data Source Exception and Decryption Failed. We have one of our persistent tunnels offline due to perhaps a cell modem failure, and none of those alarms show in the "current alarms" panel on the Persistent publisher screen.

What am I missing here? I'd like to get an event created when the Tunnel fails, so I can go start fixing the problem.

[CraigWeb]

@turbo said in Alarming if Persistent Connection fails?:

have one of our persistent tunnels offline due to perha

Hi Turbo

There are 2 ways to do this.
1: using the mango internal data source. add all persistent metrics as data points.
this will give you the following points for each PTCP data source:

You can then put a has not changed event detector on connection time or a low limit event detector on total connections.

2: you can create a binary virtual data point on the edge device that changes every 5 seconds and publish it to the central server. Which can be viewed as a heart beat. Put a has not changed event detector on this point.

[Turbo]

Greetings, Craig:

Thanks for the help.

So, what do the Data Source Exception and Decryption Failed alarms do on the Master side of a persistent tunnel actually indicate? What would cause those to actualy generate their own events?

I've seen the Outstation (Publisher) side give me alarms when alarms are enabled, when I remote in to do troubleshooting and stuff, but I've never see the Master (Data source) alarms actually do anything.. Do they actually alarm on anything? I understand the difficulty of alarming on the Persistent thing, since there's a lot of hair on how people configure it (updating nightly, etc).. So, maybe I just answered my own question there.

I appreciate your advice, and I'll go for option (1). Putting a heartbeat on an edge detector seems like a kludgey workaround to me. And, well, I'm paying for cell data bandwidth here, so I'd rather not shovel more data than I need to. Especially if there's already handy counters built into the Persistent TCP metrics.

You've got me thinking, though, of any other steady-state values I regularly get throughout the day that I could alarm on for this. We do solar, and it changes all day long, but at night nearly all my data goes dead (no sun, you see), but we do have all our environmental sensors going out there. Problem is, we already have alarms on most of those.. and for some really still nights, the temperature and stuff are really quite stable.

I'll have to think a bit on this.. I think maybe your option 1 is probably the best option for this. Thanks for your help!

Cheers,
-Greg

[CraigWeb]

Hi Greg

The data source exception is a generic error that can be caused by the following:
Failing to open the socket on the port to listen for data. There are various reasons this can happen, port permissions, duplicate port or unlicensed core. The log message will indicate the reason.

Failing to set a point back from the data source --> publisher. Will cause an exception, the log will indicate "Failed to send value for point "

Data source decryption failed means what it says if the pair is using encryption and the decryption fails for any reason this event will fire.

Option 1 is definitely the best, the heartbeat is klunky, and is more of a novelty that can be charted on a status page.

[Turbo]

I appreciate your help on this:

I've been gradually rolling out Option (1), and it seems to work out ok. Seems to be it would be a Handy and Useful Feature to have an alarm point that would fail within the Persistent publisher itself when the link fails (for any reason). Maybe some people do persistent links that come up and down randomly through the day, but it seems that the persistent link feature is generally intended to be used.. Well, persistently.

Anyways, the not changed event detector option for the persistent metrics seems to do the job.

Thanks!

-Greg