Thanks Sebastian!
I can't find a '-instance' option.
We generally judge problems by the schedule x 2. If the snapmirror is supposed to replicate every hour, if the lag is 2 hours or more, for example, fire off an alert.
There is an 'is-healthy' in 'snapmirror-info', but it's a boolean option, it doesn't report how far behind from the source, the destination is. The 7mode 'snapmirror-status' child_get_string("lag-time") is how I did this before.
-Blake
On Sat, Jun 8, 2013 at 9:03 AM, Sebastian Goetze spgoetze@gmail.com wrote:
Hi Blake,
try looking at it with the '-instance' switch.
'Lag' time without knowledge of the replication interval is not very useful. That's why it was sort of replaced by the 'health' info. If the relationship is healthy, the lag time is OK...
Hope that helps
Sebastian
On 08.06.2013 17:04, Blake Golliher wrote:
Hi!
It looks as if the concept of a 'snapmirror lag' has been scrubbed from Clustered OnTap, at least on 8.1.2P3. 'snapmirror show' will show the state, and transferring, but there's no lag, or a start time that I can extrapolate. There's a progress, which reports what's been transferred, but no lag.
The api documentation doesn't have any mention of snapmirror lag in snapmirror-info attributes-list. There's no support of snapmirror in snmp (at least so far). So does DFM (or whatever they call it now) monitor this? And how would it?
Thanks for any and all suggestions. If I find where this data is, I'll put the script on github.
-Blake
Toasters mailing listToasters@teaparty.nethttp://www.teaparty.net/mailman/listinfo/toasters