host Disk Space & very large drives

[julian924s]

Hi - sorry I haven't looked at this sooner - on the monitored host I have installed 5.5 from source and confirmed its working. Removed ALL disk usage graphs from cacti, got it to refresh all the Associated Data Queries for that host and added the graphs again. But the same result I either get a max capacity of 2.0T or 4.0T depending on which usage graph I select.

Thanks - Julian.

[TheWitness]

I concur. I did look at the source code for the snmp agent and see what it is "not" doing. It would be a minor patch for the agent, but I am uncertain they will accept it.

TheWitness

[intenso]

hi,

i have the same problem. on my monitored client i have mounted a 10 TB iscsi-storage device.

the cacti graph shows me the correct used value (3,8TB) but the total value is 0.

if i run a snmpget from my mib-browser i get this:
OID, Value, Type
hrStorageSize.35, -1647589634, Integer

great!!! it looks like the integer is too small.

my machine works with ubuntu karmic-server (9.10) and the net-snmp 5.4.1-ubuntu packet.

did i understand it correct, the net-snmp 5.5 dont fix it?


thx

ronny

[TheWitness]

Right the hrStorageSize is "truncated" to an unsigned 32 bit integer, in your case, since it fit's inside of a signed 32bit integer, it's going negative (two's complement). So, theoretically, in your case, the Cacti indexing script could be corrected to take the absolute value of that number and add the max two complement positive integer to it and you would be back in business.

However, generically, this will not work. The only thing to do is to perform a bounds check in the agent and decrease the AllocationUnits by 2^x where x is any value that keeps the AllocationSize's below the max two complement 32bit integer size.

It's a simple loop to be placed in the host source code for the agent. If any one of you can "compile" the net-snmp 5.5 smpd daemon, I would be willing to write a patch, but you have to test, not me.

TheWitness

[julian924s]

I'll test ... what do I need to do? Just get net-snmp 5.5 sources and apply a patch you can provide. If so, not a problem.

Thanks - J.

[julian924s]

Well it's been a while. I've just updated Cacti today so I now have:

Cacti Version - 0.8.7g
Plugin Architecture - 2.8
Poller Type - Cactid v
Server Info - Linux 2.6.18-194.8.1.el5
Web Server - Apache/2.2.3 (CentOS)
PHP - 5.1.6
PHP Extensions - libxml, xml, wddx, tokenizer, sysvshm, sysvsem, sysvmsg, standard, SimpleXML, sockets, SPL, shmop, session, Reflection, pspell, posix, mime_magic, iconv, hash, gmp, gettext, ftp, exif, date, curl, ctype, calendar, bz2, zlib, pcre, openssl, apache2handler, dbase, gd, memcache, mssql, mysql, mysqli, PDO, pdo_mysql, pdo_sqlite, snmp
MySQL - 5.0.77-log
RRDTool - 1.4.4
SNMP - 5.3.2.2
Plugins

• Device Monitoring (monitor - v0.8.2)
  Global Plugin Settings (settings - v0.5)
  syslog
  Host Info (hostinfo - v0.2)
  memorize plugin for cacti (memorize - v0.2)
  status

And I'm still getting this same issue - the server with a 21T partition is still only showing at 4T max - does anyone know if this is meant to be fixed or can be fixed?

Thanks.

[TheWitness]

Post a walk of the host mib for the two devices in question.

TheWitness

[julian924s]

Hi - hope this is what you wanted? I've tried a couple of different methods for this, SNMP - hrStorageTable and ucd 10 fs - the latter running host_disk.xml.

I've done some snmpwalks of the host and these are the results - its only the /data (/dev/sdb) partition that is wrong - this is the 21T partition.

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 137G 2.9G 127G 3% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/sdb 21T 16M 21T 1% /data


snmpwalk -v2c -cxxxxxxxxxxxxxxxx localhost .1.3.6.1.4.1.2021.9
UCD-SNMP-MIB::dskIndex.1 = INTEGER: 1
UCD-SNMP-MIB::dskIndex.2 = INTEGER: 2
UCD-SNMP-MIB::dskPath.1 = STRING: /
UCD-SNMP-MIB::dskPath.2 = STRING: /data
UCD-SNMP-MIB::dskDevice.1 = STRING: /dev/sda1
UCD-SNMP-MIB::dskDevice.2 = STRING: /dev/sdb
UCD-SNMP-MIB::dskMinimum.1 = INTEGER: 0
UCD-SNMP-MIB::dskMinimum.2 = INTEGER: 0
UCD-SNMP-MIB::dskMinPercent.1 = INTEGER: -1
UCD-SNMP-MIB::dskMinPercent.2 = INTEGER: -1
UCD-SNMP-MIB::dskTotal.1 = INTEGER: 142702528
UCD-SNMP-MIB::dskTotal.2 = INTEGER: 1966080
UCD-SNMP-MIB::dskAvail.1 = INTEGER: 132370880
UCD-SNMP-MIB::dskAvail.2 = INTEGER: 1949696
UCD-SNMP-MIB::dskUsed.1 = INTEGER: 2965836
UCD-SNMP-MIB::dskUsed.2 = INTEGER: 16380
UCD-SNMP-MIB::dskPercent.1 = INTEGER: 2
UCD-SNMP-MIB::dskPercent.2 = INTEGER: 0
UCD-SNMP-MIB::dskPercentNode.1 = INTEGER: 0
UCD-SNMP-MIB::dskPercentNode.2 = INTEGER: 0
UCD-SNMP-MIB::dskErrorFlag.1 = INTEGER: noError(0)
UCD-SNMP-MIB::dskErrorFlag.2 = INTEGER: noError(0)
UCD-SNMP-MIB::dskErrorMsg.1 = STRING:
UCD-SNMP-MIB::dskErrorMsg.2 = STRING:


snmpwalk -v2c -cxxxxxxxxxxxxxxx localhost .1.3.6.1.2.1.25.2.3.1
HOST-RESOURCES-MIB::hrStorageIndex.1 = INTEGER: 1
HOST-RESOURCES-MIB::hrStorageIndex.2 = INTEGER: 2
HOST-RESOURCES-MIB::hrStorageIndex.3 = INTEGER: 3
HOST-RESOURCES-MIB::hrStorageIndex.4 = INTEGER: 4
HOST-RESOURCES-MIB::hrStorageIndex.5 = INTEGER: 5
HOST-RESOURCES-MIB::hrStorageType.1 = OID: HOST-RESOURCES-TYPES::hrStorageOther
HOST-RESOURCES-MIB::hrStorageType.2 = OID: HOST-RESOURCES-TYPES::hrStorageRam
HOST-RESOURCES-MIB::hrStorageType.3 = OID: HOST-RESOURCES-TYPES::hrStorageVirtualMemory
HOST-RESOURCES-MIB::hrStorageType.4 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageType.5 = OID: HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Memory Buffers
HOST-RESOURCES-MIB::hrStorageDescr.2 = STRING: Real Memory
HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: Swap Space
HOST-RESOURCES-MIB::hrStorageDescr.4 = STRING: /
HOST-RESOURCES-MIB::hrStorageDescr.5 = STRING: /data
HOST-RESOURCES-MIB::hrStorageAllocationUnits.1 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.2 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.3 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.4 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.5 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 4046780
HOST-RESOURCES-MIB::hrStorageSize.2 = INTEGER: 4046780
HOST-RESOURCES-MIB::hrStorageSize.3 = INTEGER: 8385920
HOST-RESOURCES-MIB::hrStorageSize.4 = INTEGER: 35675630
HOST-RESOURCES-MIB::hrStorageSize.5 = INTEGER: 1074233344
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 37944
HOST-RESOURCES-MIB::hrStorageUsed.2 = INTEGER: 385012
HOST-RESOURCES-MIB::hrStorageUsed.3 = INTEGER: 0
HOST-RESOURCES-MIB::hrStorageUsed.4 = INTEGER: 741459
HOST-RESOURCES-MIB::hrStorageUsed.5 = INTEGER: 4095

What I see is a graph that states the max storage is only 4T.

Thanks.

[TheWitness]

Yup. The net-snmp gives you a number that looks good, but off by several orders of magnitude. You should check the net-snmp mainling list. Last I checked, they were working on a revised RFC, might be a new OID and it was assigned to one of the team members.

You might be able to 'hack' a good result by making a new template that applies a CDEF to the output value, but don't modify the 'standard' template.

TheWitness

[yousillygoose]

NECROPOST TIME!!!

Wouldn't this solution fail for partitions that can't be stored with 2 max ints? After the first wrap around wouldn't it just...fail? I think that point is right around 16tb's.

Edit: I just came across this: http://forums.cacti.net/viewtopic.php?f ... 3&start=15. It seems my realization was already...realized. Unfortunately, no proposed solution exists. My brain will be churning!