A medida que los volúmenes de más de 16 TB se hicieron más comunes, se reconoció que el valor de 32 bits utilizado para informar el tamaño del disco y el uso dentro de la MIB estándar "HOST-RESOURCES" en SNMP no era lo suficientemente grande como para informar el tamaño de disco adecuado.
Net-SNMP parece haber abordado este problema simplemente manipulando el valor de "AllocationUnits" para mantener un valor de 32 bits para la utilización del disco (ya que el tamaño / uso total del disco es igual al valor del espacio de 32 bits multiplicado por la unidad de asignación), para permitir para el cálculo de un volumen mayor a 8 / 16TB. Suponiendo que no tiene ningún interés en informar sobre la unidad de asignación, y está bien con un pequeño nivel de inexactitud. Esto parece una solución elegante.
https://bugzilla.redhat.com/show_bug.cgi?id=654384
Sin embargo, el servicio SNMP integrado de Windows parece continuar sufriendo este error, simplemente informando el módulo del espacio de disco utilizado / asignado, lo que resulta en informes de tamaño de disco inexactos.
¿Hay alguna manera de permitir que Windows informe correctamente el uso del disco para volúmenes de más de 16 TB? Intentamos simplemente instalar Net-SNMP 5.5 x64 y deshabilitar por completo el servicio SNMP de Windows, sin embargo, desafortunadamente, esto no solucionó nuestro problema.
Cuando se usan las extensiones de NetSNMP, la información que recopilamos para el disco en particular que nos interesa es la siguiente:
Estos resultados son los mismos independientemente de si estamos utilizando el servicio SNMP de Windows o NetSNMP.
He visto a personas en la comunidad de Cacti mencionar simplemente la creación de una solución. Desafortunadamente, estamos usando Observium para el monitoreo rápido y básico de sistemas. Si el problema no se puede corregir en el lado de la ventana, ¿se puede hacer que Observium informe MIB personalizados?
- Actualización -
Al analizar la mención del informe de error de agregar "realStorageUnits" al archivo snmpd.conf, experimentamos el siguiente problema al configurar esa directiva:
- Actualización 2 -
Bueno, después de muchos ajustes, no parece ninguna de las versiones de Windows de Net-SNMP como la directiva "realStorageUnits". La inclusión de la directiva genera una advertencia al iniciar SNMP. Probamos en la versión 5.5, 5.6 y 5.7. ¿Alguien ha descubierto alguna vez cómo hacer que SNMP informe más de 16 volúmenes de TB en Windows?
fuente
.1.3.6.1.4.1.2021.100.2.0
para verificar si realmente es Net-SNMP el que está respondiendo. En mis hosts (Linux) con Net-SNMP daSNMPv2-SMI::enterprises.2021.100.2.0 = STRING: "5.4.1"
Respuestas:
Hace un tiempo hubo un parche para Net-SNMP 5.5 que introdujo una nueva opción
realStorageUnits
para el archivo de configuración.Del informe de errores de Redhat # 748410 :
(el texto entre [corchetes] es mío)
Por lo tanto, agregar la directiva de configuración
realStorageUnits 0
a su snmpd.conf podría estar resolviendo su problema.Sin embargo, los valores no serán correctos hasta el último megabyte; ymmv.
No puedo decir si este parche se incluyó en su distribución binaria de Net-SNMP, pero sería genial si pudiera informar los resultados y qué binario está utilizando. Además, no lo probé por la falta de hardware adecuado en este momento.
fuente
realStorageUnits
directiva. Si esto aún no funciona para usted, tengo la clara sensación de que esta característica de alguna manera no está incluida en el binario NetSNMP que está utilizando.Sé que esta no es una respuesta directa a su pregunta, pero tal vez sea útil. Le sugiero que intente ponerse en contacto con el equipo que hace que SNMP Informant: http://www.snmp-informant.com/
Extienden el agente SNMP de Windows para evitar las limitaciones de Microsoft para algunos de sus OID. Lo uso con Zenoss para obtener números de almacenamiento y utilización de CPU más precisos y hay una buena probabilidad de que esto solucionará su problema, pero no puedo decirlo con certeza.
fuente