Synology NAS Details Dashboard

[Mitchell Laframboise]

Good morning group,  I have only some of this public dashboard working and I'm wondering how to get the rest up and running.  I am starting with the interface.  Its showing no data, so I was hoping someone could point me in the right direction.  I've attached a screenshot of the queries for the dashboard and my generator.yml so you can see if I have this set up correctly.

---
auths:
  public_v1:
    version: 1
  public_v2:
    version: 2

modules:
  # Default IF-MIB interfaces table with ifIndex.
  if_mib:
    walk: [sysUpTime, 1.3.6.1.2.1.2.2, 1.3.6.1.2.1.31.1.1]
    lookups:
      - source_indexes: [ifIndex]
        lookup: ifAlias
      - source_indexes: [ifIndex]
        # Uis OID to avoid conflict with PaloAlto PAN-COMMON-MIB.
        lookup: 1.3.6.1.2.1.2.2.1.2 # ifDescr
      - source_indexes: [ifIndex]
        # Use OID to avoid conflict with Netscaler NS-ROOT-MIB.
        lookup: 1.3.6.1.2.1.31.1.1.1.1 # ifName
    overrides:
      ifAlias:
        ignore: true # Lookup metric
      ifDescr:
        ignore: true # Lookup metric
      ifName:
        ignore: true # Lookup metric
      ifType:
        type: EnumAsInfo
  # Default IP-MIB with ipv4InterfaceTable for example.
  ip_mib:
    walk: [ipv4InterfaceTable]

  readynas:
    walk:
      - 1.3.6.1.4.1.4526               # Raid/Disks status

# Synology
#
# Synology MIBs can be found here:
#   http://www.synology.com/support/snmp_mib.php
#   http://dedl.synology.com/download/Document/MIBGuide/Synology_MIB_File.zip
#
# Tested on RS2414rp+ NAS
#
  synology:
    walk:
      - 1.3.6.1.4.1.6574.1       # synoSystem
      - 1.3.6.1.4.1.6574.2       # synoDisk
      - 1.3.6.1.4.1.6574.3       # synoRaid
      - 1.3.6.1.4.1.6574.4       # synoUPS
      - 1.3.6.1.4.1.6574.5       # synologyDiskSMART
      - 1.3.6.1.4.1.6574.6       # synologyService
      - 1.3.6.1.4.1.6574.101     # storageIO
      - 1.3.6.1.4.1.6574.102     # spaceIO
      - 1.3.6.1.4.1.6574.104     # synologyiSCSILUN
      - 1.3.6.1.4.1.6574.3.1  # raid table
    lookups:
      - source_indexes: [spaceIOIndex]
        lookup: spaceIODevice
        drop_source_indexes: true
      - source_indexes: [storageIOIndex]
        lookup: storageIODevice
        drop_source_indexes: true
      - source_indexes: [serviceInfoIndex]
        lookup: serviceName
        drop_source_indexes: true
      - source_indexes: [diskIndex]
        lookup: diskID
        drop_source_indexes: true
      - source_indexes: [raidIndex]
        lookup: raidName
        drop_source_indexes: true
    overrides:
      diskModel:
        type: DisplayString
      diskSMARTAttrName:
        type: DisplayString
      diskSMARTAttrStatus:
        type: DisplayString
      diskSMARTInfoDevName:
        type: DisplayString
      diskType:
        type: DisplayString
      modelName:
        type: DisplayString
      raidFreeSize:
        type: gauge
      raidName:
        type: DisplayString
      raidTotalSize:
        type: gauge
      serialNumber:
        type: DisplayString
      serviceName:
        type: DisplayString
      version:
        type: DisplayString

# UCD-SNMP-MIB
#
# University of California, Davis extensions. Commonly used for host
# metrics. For example, Linux-based systems, DD-WRT, Synology,
# Mikrotik, Kemp LoadMaster, etc.
#
# http://www.net-snmp.org/docs/mibs/UCD-SNMP-MIB.txt
#
  ucd_la_table:
    walk:
      - 1.3.6.1.4.1.2021.10.1.2 # laNames
      - 1.3.6.1.4.1.2021.10.1.5 # laLoadInt
      - 1.3.6.1.4.1.2021.10.1.6 # laLoadFloat
    lookups:
      - source_indexes: [laIndex]
        lookup: laNames
        drop_source_indexes: true
  ucd_memory:
    walk:
      - 1.3.6.1.4.1.2021.4 # memory
  ucd_system_stats:
    walk:
      - 1.3.6.1.4.1.2021.11 # systemStats

Any help would be greatly appreciated!

Thanks,

[Brian Candler]

First, do a query in the Prometheus web interface (for example, just "ifPhysAddress"). If you see no answers, then you need to drill down into your metrics collection. Check the query "up" to see if SNMP scraping is successful. If it's not, then check logs from snmp_exporter ("journalctl -eu snmp_exporter), or use the test web interface at <your-snmp-exporter>:9116/snmp/status

If the metrics collection into Prometheus is working, meaning that you have a problem with Grafana, then please seek Grafana support from the Grafana Community.

[Mitchell Laframboise]

Thanks Brian.  I am successful in querying the metrics in Prometheus, so I will check out the Grafana community for support.

[Mitchell Laframboise]

Hi there,

  I did some more queries and found that I'm unable to return ifName?  Im walking that specific OID so I don't understand?

Can you help

[Brian Candler]

>  I am successful in querying the metrics in Prometheus

Which ones in particular *are* you able to see?

> I did some more queries and found that I'm unable to return ifName?

Please explain exactly what you're doing when you say "unable to return". If you're going to the Prometheus web interface (usually at x.x.x.x:9090) and entering "ifName" as the query and hitting Enter, and getting no results, then it seems like you're not successfully scraping the if_mib from any targets. However if you're getting some other metrics like ifHCInOctets from the if_mib, then maybe the way you built snmp.yml from generator.yml is broken.

You'll need to work out what's happening. In the same Prometheus web interface go to Status > Targets as a starting point. If it says the target is "up" then try doing exactly the same scrape manually:

curl -v 'x.x.x.x:9116/snmp?target=y.y.y.y&module=zzzz&auth=aaaa'

and/or point a web browser at x.x.x.x:9116/snmp/status as I suggested before. Also look at snmp_exporter's stdout ("systemctl status snmp_exporter" if you're running it under systemd).

Basically, you need to divide and conquer. If ifName not being returned from any targets, then is it a problem with your snmp.yml, or with your prometheus scrape config, or something else? You haven't shown your scrape config, so the problem could be there. You also haven't shown the snmp.yml which came from your generator.yml.

[Mitchell Laframboise]

Thanks for your reply.  I was using the default generator.yml which lists an override of ifName and ignore was set to "true"  I removed those lines before generating the snmp.yml and was able to query ifName.  

Thank you!

[Mitchell Laframboise]

  Hi.  I'm having issues with another metric.  raidTotalSize 

its in the default generator.yml under the synology module in overrides but when I generate the snmp.yml it doesn't put the metric in there???   I can't figure out why

Here is my generator.yml file

---
auths:
  public_v1:
    version: 1
  public_v2:
    version: 2

modules:
  # Default IF-MIB interfaces table with ifIndex.
  if_mib:

    walk: [sysUpTime, interfaces, ifXTable]

    lookups:
      - source_indexes: [ifIndex]
        lookup: ifAlias
      - source_indexes: [ifIndex]
        # Uis OID to avoid conflict with PaloAlto PAN-COMMON-MIB.
        lookup: 1.3.6.1.2.1.2.2.1.2 # ifDescr
      - source_indexes: [ifIndex]
        # Use OID to avoid conflict with Netscaler NS-ROOT-MIB.
        lookup: 1.3.6.1.2.1.31.1.1.1.1 # ifName
    overrides:
      ifAlias:
        ignore: true # Lookup metric
      ifDescr:
        ignore: true # Lookup metric
      ifName:
        ignore: true # Lookup metric
      ifType:
        type: EnumAsInfo

# Synology
#
# Synology MIBs can be found here:
#   http://www.synology.com/support/snmp_mib.php
#   http://dedl.synology.com/download/Document/MIBGuide/Synology_MIB_File.zip
#
# Tested on RS2414rp+ NAS
#
  synology:
    walk:
      - 1.3.6.1.4.1.6574.1       # synoSystem
      - 1.3.6.1.4.1.6574.2       # synoDisk
      - 1.3.6.1.4.1.6574.3       # synoRaid
      - 1.3.6.1.4.1.6574.4       # synoUPS
      - 1.3.6.1.4.1.6574.5       # synologyDiskSMART
      - 1.3.6.1.4.1.6574.6       # synologyService
      - 1.3.6.1.4.1.6574.101     # storageIO
      - 1.3.6.1.4.1.6574.102     # spaceIO
      - 1.3.6.1.4.1.6574.104     # synologyiSCSILUN

any help would be appreciated.

Thanks,

[Brian Candler]

I can't see what you're looking at, because:

1. You've shown your generator.yml, but you've not shown the snmp.yml output that generator creates.

2. You've not said how the output snmp.yml is different from the supplied snmp.yml

3. You've not said what version of snmp_exporter you're using, so I can't look at the supplied snmp.yml.

Have you tried using *exactly* the same synology section in your generator.yml as in the supplied generator.yml, and then comparing the snmp.yml output?

Are you getting any errors or warnings from generator when you run it? If so, maybe you've not got the correct versions of MIBs available. The Makefile in the generator directory shows where it downloads them from when building the default MIBs.

[Mitchell Laframboise]

I looked at the sample snmp.yml from Github that I assume is generated from the default generator.yml and I see that the "raidTotalSize" metric is included, but when I check my snmp.yml that metric isn't included.  So I edited the snmp.yml to include that metric and now Prometheus is scraping that data, but the dashboard is still not picking it up.  I guess I'm going to have to ask the Grafana community.

[Mitchell Laframboise]

From the generator.yml I posted do you know why the snmp.yml didn't include that metric?  Since the generator.yml has that metric in overrides, shouldn't it be generated?

[Brian Candler]

> I looked at the sample snmp.yml from Github that I assume is generated from the default generator.yml and I see that the "raidTotalSize" metric is included, but when I check my snmp.yml that metric isn't included.

Either something is different in your generator.yml, or something is different in the set of MIBs you are making available to generator. If you can solve that, it would avoid you having to hack snmp.yml manually, and might be covering up some other problem.

> the dashboard is still not picking it up.  I guess I'm going to have to ask the Grafana community.

It will be a problem with the queries configured in Grafana, and if they make use of Grafana variables they may not be set the way you expect. So indeed, Grafana is where you need to look. Using (three dots) > Inspect > Query on a panel, you should be able to see what query it is sending.

[Brian Candler]

> Since the generator.yml has that metric in overrides, shouldn't it be generated?

No. Overrides only change how a metric is rendered; if there's no matching metric in the MIB then there's nothing to override.

[Mitchell Laframboise]

Thank you for the explanations... I've checked the mibs and that metric is included as an object along with others like raidFreeSize that are also not being included in the generated snmp.yml  I'm using the latest verison of snmp-exporter 0.26.0 Im wondering if the generator is broken?

[Mitchell Laframboise]

I know the mib is working because when I do an snmpwalk i get the following output.

~/snmp_exporter/generator$ snmpwalk -v2c -c public *.*.*.* 1.3.6.1.4.1.6574.3
SNMPv2-SMI::enterprises.6574.3.1.1.1.0 = INTEGER: 0
SNMPv2-SMI::enterprises.6574.3.1.1.1.1 = INTEGER: 1
SNMPv2-SMI::enterprises.6574.3.1.1.2.0 = STRING: "Volume 1"
SNMPv2-SMI::enterprises.6574.3.1.1.2.1 = STRING: "Storage Pool 1"
SNMPv2-SMI::enterprises.6574.3.1.1.3.0 = INTEGER: 1
SNMPv2-SMI::enterprises.6574.3.1.1.3.1 = INTEGER: 1
SNMPv2-SMI::enterprises.6574.3.1.1.4.0 = Counter64: 14395893346304
SNMPv2-SMI::enterprises.6574.3.1.1.4.1 = Counter64: 398458880
SNMPv2-SMI::enterprises.6574.3.1.1.5.0 = Counter64: 15355710676992
SNMPv2-SMI::enterprises.6574.3.1.1.5.1 = Counter64: 15995942993920
SNMPv2-SMI::enterprises.6574.3.1.1.6.0 = INTEGER: 0
SNMPv2-SMI::enterprises.6574.3.1.1.6.1 = INTEGER: 0

[Brian Candler]

I mean the MIB files consumed by generator.

[Mitchell Laframboise]

here is the contents of the Synology raid mib file

SYNOLOGY-RAID-MIB DEFINITIONS ::= BEGIN

IMPORTS
OBJECT-GROUP, MODULE-COMPLIANCE
FROM SNMPv2-CONF
enterprises, MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter64
FROM SNMPv2-SMI;

synoRaid MODULE-IDENTITY
    LAST-UPDATED "201309110000Z"
    ORGANIZATION "www.synology.com"
    CONTACT-INFO
         "Synology Inc.
          Email: sn...@synology.com"
    DESCRIPTION
        "Characteristics of the raid information"
    REVISION     "201309110000Z"
    DESCRIPTION
        "Second draft."
    ::= { synology 3 }
   
synology  OBJECT IDENTIFIER
::= { enterprises 6574 }

raidTable OBJECT-TYPE
    SYNTAX    SEQUENCE OF RaidEntry
    MAX-ACCESS   not-accessible
    STATUS    current
    DESCRIPTION
    "Synology raid table"
    ::= { synoRaid 1 }

raidEntry   OBJECT-TYPE
    SYNTAX    RaidEntry
    MAX-ACCESS   not-accessible
    STATUS    current
    DESCRIPTION
    "For all raid entry"
    INDEX   { raidIndex }
    ::= { raidTable 1 }

RaidEntry ::= SEQUENCE {
    raidIndex Integer32,
    raidName OCTET STRING,
raidStatus Integer32,
raidFreeSize Counter64,
raidTotalSize Counter64,
raidHotspareCnt Integer32
}

raidIndex OBJECT-TYPE
    SYNTAX    Integer32(0..2147483647)
    MAX-ACCESS   read-only
    STATUS    current
    DESCRIPTION
    "The index of raid table"
    ::= { raidEntry 1 }

raidName OBJECT-TYPE
    SYNTAX   OCTET STRING
    MAX-ACCESS  read-only
    STATUS   current
    DESCRIPTION
    "Synology raid name
 The name of each raid will be showed here.
"
    ::= { raidEntry 2 }

raidStatus OBJECT-TYPE
    SYNTAX   Integer32(1..12)
    MAX-ACCESS  read-only
    STATUS   current
    DESCRIPTION
    "Synology Raid status
 Each meanings of status represented describe below.
 Normal(1): The raid functions normally.
   Degrade(11): Degrade happens when a tolerable failure of disk(s) occurs.
   Crashed(12): Raid has crashed and just uses for read-only operation.

 Note:
 Other status will be showed when creating or deleting raids, including below status, Repairing(2), Migrating(3), Expanding(4), Deleting(5), Creating(6), RaidSyncing(7), RaidParityChecking(8), RaidAssembling(9) and Canceling(10).
"
    ::= { raidEntry 3 }

raidFreeSize OBJECT-TYPE
    SYNTAX      Counter64
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
    "Synology raid freesize
 Free space in bytes.
"
    ::= { raidEntry 4 }

raidTotalSize OBJECT-TYPE
    SYNTAX      Counter64
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
    "Synology raid totalsize
 Total space in bytes.
"
    ::= { raidEntry 5 }

raidHotspareCnt OBJECT-TYPE
    SYNTAX      Integer32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
    "Synology raid hotspare
 Total hotspare disks count.
 Each meaning of values described as below.
 Normal(>=0): Total number of hotspare disks in this pool.
"
    ::= { raidEntry 6 }

raidConformance OBJECT IDENTIFIER ::= { synoRaid 2 }
raidCompliances OBJECT IDENTIFIER ::= { raidConformance 1 }
raidGroups OBJECT IDENTIFIER ::= { raidConformance 2 }

raidCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
            "The compliance statement for synoRaid entities which
            implement the SYNOLOGY RAID MIB."
    MODULE  -- this module
        MANDATORY-GROUPS { raidGroup }

    ::= { raidCompliances 1 }

raidGroup OBJECT-GROUP
    OBJECTS { raidIndex,
              raidName,
              raidStatus,
              raidFreeSize,
              raidTotalSize,
              raidHotspareCnt}
    STATUS  current
    DESCRIPTION
            "A collection of objects providing basic instrumentation and
            control of an synology raid entity."
    ::= { raidGroups 1 }

END

  Does this help?

[Mitchell Laframboise]

I just used this command and successfully return the right oid

snmptranslate -On -m /usr/share/snmp/mibs/SYNOLOGY-RAID-MIB.mib -IR raidTotalSize

so I don't get it

[Brian Candler]

First, make sure you can reproduce the existing generator.yml -> snmp.yml using the Makefile to download MIBs. You should be able to reproduce exactly what the supplied snmp.yml has. Once you have that working, then try your own generator.yml and compare the generated snmp.yml. Drilling down that way you should be able to identify where the difference is.

I'm dropping out now, rather than repeat myself any more. Good luck.