Intel Entry Storage Server SS4200-E
- type:
- user_template_host
- usertemplate:
- ss4200-e
- description:
- Intel Entry Storage Server SS4200-E.
- Cacti:
- 0.8.7
- homepage:
- http://www.wynwebtechnologies.com
- date:
- 2009-12-13
- email:
- [email protected]
- includes:
- yes
- templates:
- ss4200-e,
- intel,
- entry storage server,
- emc lifeline,
- nas
The Intel Entry Storage Server SS4200-E includes an installation of BusyBox which provides the capability for some types of basic SNMP monitoring. Unfortunately many of the SNMP implementation items are non-standard and are driven by proprietary EMC 'SOHO' configurations. After guess-and-check research on the platform, this host template should assimilate necessary data queries to get most kinds of immediately useful data points for performance monitoring of the system.
Download
| Version | File |
|---|---|
| 0.0.1 | Not yet Available |
Installation
Screenshots
Raw SNMP OIDs
The limited research conducted to put together this template indicated a strong lack of documentation surrounding the implementation of SNMP MIBs on the SS4200-E device. To make things even more challenging, initial research, indicated implementation of some standardized OIDs however subsequent probing yielded incomplete data.
Key data point still not identified at this time against the 1.1.11.32736 firmware include interface bytes input and output, and aggregate CPU utilization and load.
| SNMP OID | Data Point Description |
|---|---|
| .1.3.6.1.2.1.1.5 | SS4200-E HostName |
| .1.3.6.1.4.1.1139.10.6.1.1.3.2 | Internal Fan 1 Speed (RPM) |
| .1.3.6.1.4.1.1139.10.6.1.1.3.3 | Internal Fan 2 Speed (RPM) |
| .1.3.6.1.4.1.1139.10.6.3.1.3.1 | V+5 Rail (mV) |
| .1.3.6.1.4.1.1139.10.6.3.1.3.2 | Vccp |
| .1.3.6.1.4.1.1139.10.6.3.1.3.3 | 3V+ or - |
| .1.3.6.1.4.1.1139.10.6.3.1.3.4 | V1_in |
| .1.3.6.1.4.1.1139.10.6.3.1.3.5 | 12V Rail (mV) |
| .1.3.6.1.4.1.1139.10.6.3.1.3.6 | 3V+ or - |
| .1.3.6.1.4.1.1139.10.6.3.1.3.7 | 3V+ or - |
| .1.3.6.1.2.1.25.1.1.0 | Uptime |
| .1.3.6.1.2.1.25.1.5.0 | Users Logged On |
| .1.3.6.1.2.1.25.1.6.0 | Process Count |
| .1.3.6.1.2.1.25.2.3.1.5.1 | RAM Total |
| .1.3.6.1.2.1.25.2.3.1.5.10 | SWAP |
| .1.3.6.1.2.1.25.2.3.1.6.1 | RAM Used |
| .1.3.6.1.2.1.25.2.3.1.6.10 | SWAP Used |
| .1.3.6.1.2.1.2.2.1.11.3 | Packets In (Eth0) |
| .1.3.6.1.2.1.2.2.1.17.3 | Packets Out (Eth0) |
There is one other oddity, Ive noted. The amount of storage available is not dumped out ANYWHERE in the SNMP tree that has been implemented through the various MIBs. Seriously. A NAS head with an SNMP implementation that never spits out storage usage in bytes.
Instead, to get to a roughly close number, you can get the hrStorageSize and the hrStorage Used and then multiple those by the hrStorageAllocationUnits to get sorta close.
For reference, here are the necessary numeric OIDs for that calculation as well. Hopefully this will save someone, somewhere hours of pain dealing with non-standard and incomplete MIBs.
| SNMP OID | Data Point Description |
|---|---|
| .1.3.6.1.2.1.25.2.3.1.4.38 | /mnt/soho_storage Allocation Unit Size |
| .1.3.6.1.2.1.25.2.3.1.5.38 | /mnt/soho_storage Total Blocks |
| .1.3.6.1.2.1.25.2.3.1.6.38 | /mnt/soho_storage Units Allocated (Used) |
I had hoped that having to do disk geometry calculations went the way of the dodo back in the days when the whole LILO/LBA issues were solved… guess not.
(To address the emails I have already recieved on the above statement: Yes I realize, that physical cluster counts and address space issues are not an identical issue to doing calculations based on the data map for a drive, however my commentary is merely remarking upon the congruency of the headaches involved and is intended as satire.)
