Hmm, hadn't even considered doing it via SNMP. Thanks - that's a useful line of investigation. Sounds like the same limitations as df over ssh, which I can live with. 

For one reason or another, I've an isolated environment that I can't hook up to my existing monitoring infrastructure, and whilst a DFM install within the environment would be an option, I've found it remarkably useful to have an 'at a glance' MRTG style set of filer perf graphs. rrdtool has holt-winters aberration detection mechanisms, which with a bit of help from R I'm fiddling with getting automatic aberration detection. (I say 'fiddling' rather than 'working' because whilst I've got such a thing up and running, I'm less sure I actually trust it's results). 

Grabbing API extracts and forwarding them on for processing periodically is therefore what I'm aiming to do.

On 23 April 2015 at 16:48, Steve Francis <sfrancis@logicmonitor.com> wrote:
In 7 mode, that is actually easier to get with SNMP than the API. (Although you do have to deal with the fact that the volume OID's change when you create/delete volumes - existing volumes will be renumbered.)

In 7 mode, snapshot volumes look just like regular volumes (except they will be called /vol/volname/.snapshot)
Then you can just query the usual OIDs:
.1.3.6.1.4.1.789.1.5.4.1.29 - the total capacity of the file system
.1.3.6.1.4.1.789.1.5.4.1.30 - the used capacity

to get the size/space used of the snapshot reserve. (You may have to use different objects if running older OnTap, that does not support the 64 bit counters.)

But be aware that the 'parent' volume will report its size *not* including the snap reserve, but that snapshot usage that has exceeded the snapreserve will count in the used space of the parent volume.

In cluster mode, LogicMonitor uses this call for space monitoring:
<volume-get-iter>
    <desired-attributes>
      <volume-attributes>     
        <volume-id-attributes>
        </volume-id-attributes>
        <volume-inode-attributes>
        </volume-inode-attributes>
          <volume-sis-attributes>
        </volume-sis-attributes>
        <volume-snapshot-attributes>
        </volume-snapshot-attributes>
           <volume-space-attributes>
        </volume-space-attributes>
        <volume-state-attributes>
        </volume-state-attributes>
      </volume-attributes>
    </desired-attributes>
    <query>
    </query>
  </volume-get-iter>

In the returned response is, amongst other things we grab:
VOLUME-SPACE-ATTRIBUTES.SNAPSHOT-RESERVE-SIZE
volume-space-attributes.percentage-snapshot-reserve-used

LMK if you have further questions. Happy to help. 
(Of course, you could also give LogicMonitor a try, and have this all solved for you, along with all your other monitoring issues...)


On Thu, Apr 23, 2015 at 6:47 AM, Oliver Brakmann <oliver.brakmann+toasters@posteo.de> wrote:
Hi,

On 2015-04-23 14:58, Edward Rolison wrote:
> There's just one thing missing - how much of the 'snap reserve' I'm
> actually using.

That is indeed hard to find. When you call 'snapshot-list-info' on the
volume, you'll get back an array of snapshot-info objects. The value you
want is in the last snapshot's 'cumulative-total' field (in kilobytes,
iirc).

Hope this helps!

Oliver
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters



--
Steve Francis | Chief Product Officer


Cloud-based performance monitoring
 

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters