Heya

I really wish i was at your level of expertise here Adam, sadly I’m not. =( I googled a bit and walked hrStorageTable and this is the hrStorageDescr from that:

HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical memory
HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: Virtual memory
HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: Memory buffers
HOST-RESOURCES-MIB::hrStorageDescr.7 = STRING: Cached memory
HOST-RESOURCES-MIB::hrStorageDescr.10 = STRING: Swap space
HOST-RESOURCES-MIB::hrStorageDescr.31 = STRING: /
HOST-RESOURCES-MIB::hrStorageDescr.35 = STRING: /dev/shm
HOST-RESOURCES-MIB::hrStorageDescr.36 = STRING: /boot
HOST-RESOURCES-MIB::hrStorageDescr.37 = STRING: /boot-rcvy
HOST-RESOURCES-MIB::hrStorageDescr.38 = STRING: /crash
HOST-RESOURCES-MIB::hrStorageDescr.39 = STRING: /rcvy
HOST-RESOURCES-MIB::hrStorageDescr.40 = STRING: /var
HOST-RESOURCES-MIB::hrStorageDescr.41 = STRING: /var-rcvy

So no luck there. In diskTable I do see it though:
UCD-SNMP-MIB::dskPath.1 = STRING: /ddnnas0
UCD-SNMP-MIB::dskPath.2 = STRING: /


So with this, any hints on how to make it work? Or is the first step to update net-snmp?
Installed Packages
net-snmp.x86_64                                                              1:5.5-54.el6_7.1                                                              @ddn-dvd


Cheers and thanks a million


-- 
Henrik Cednert  /  + 46 704 71 89 54  /  CTO  /  Filmlance
Disclaimer, the hideous bs disclaimer at the bottom is forced, sorry. ¯\_(ツ)_/¯ 

On 6 Nov 2018, at 22:53, Adam Armstrong via observium <observium@observium.org> wrote:

We actually use the HOST-RESOURCES-MIB hrStorage table, not the UCD-MIB dskTable.

Have you checked what SNMP is sending? You can walk the hrStorageTable and dskTable to see what is returned.

I seem to remember some issue with SNMP not picking up "strange" filesystems. Making sure you're running the very latest net-snmp might help.

Adam.

On 2018-11-06 21:17, Henrik Cednert (Filmlance) via observium wrote:
Hello
So I got the ‘go ahead’ from DDN to monitor it directly on the
server. Strange thing is, I’ve added the mount point to the
/etc/snmpd.conf but it still doesn’t appear in observium. I’ve
played with the syscontact just to make sure  that the snmpd.conf is
actually read properly upon discovery and poll, and it is. But it does
not seem to take this string  from conf:
disk  /ddnnas0 80%
And that is the actual mount point, as seen from ‘mount’ here:
/dev/ddnnas0 on /ddnnas0 type gpfs
(rw,relatime,mtime,nfssync,dev=ddnnas0)
Am i missing something obvious? If so, please be gentle and throw me
with great force, and maybe anger, in the right direction. =)
Cheers and thanks
--
Henrik Cednert  /  + 46 704 71 89 54  /  CTO  /  FILMLANCE
Disclaimer, the hideous bs disclaimer at the bottom is forced, sorry.
¯\_(ツ)_/¯
On 23 Oct 2018, at 21:32, Chris Neam via observium
<observium@observium.org> wrote:
We monitor our GPFS system directly from the GridScaler and have
been able to monitor up to 2.6PB so far. I'd guess it is something
with the way Windows is handling it.
On Tue, Oct 23, 2018 at 12:54 PM Henrik Cednert (Filmlance) via
observium <observium@observium.org> wrote:
Hello
We just expanded a volume on a DDN GPFS system to over 1 PB. I
monitor this volume via SNMP via a Windows server. Noticed that I
run into a 1024TB cap on the size there though. Trying to
understand where this cap is comping from, if it’s the SNMP on
windows or something in observium.
Anyone that’ve dealt with this?
Cheers and thanks
--
Henrik Cednert  /  + 46 704 71 89 54  /  CTO  /  FILMLANCE
Disclaimer, the hideous bs disclaimer at the bottom is forced,
sorry. ¯\_(ツ)_/¯
DISCLAIMER
The information contained in this communication from the sender is
confidential. It is intended solely for use by the recipient and
others authorized to receive it. If you are not the recipient, you
are hereby notified that any disclosure, copying, distribution or
taking action in relation of the contents of this information is
strictly prohibited and may be unlawful.
_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
--
CHRIS NEAM
US Mobile: +1 (703) 628 7897 [1]
E-mail: chris.neam@vricon.com
VRICON
Visiting address
US: 8280 Greensboro Drive, Suite 850, McLean, VA, 22102, USA
Sweden: Bröderna Ugglas gata, 581 88 Linköping, Sweden
www.vricon.com [2]
This e-mail is private and confidential between the sender and the
addressee.
In the event of misdirection, the recipient is prohibited from
using, copying or
disseminating it or any information in it. Please notify the above
if any misdirection. <Screen Shot 2018-10-23 at
15.29.23.png>_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Links:
------
[1] tel:%2B1%20%28703%29%20628%207897
[2] http://www.vricon.com/
_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium

Disclaimer


The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.