On Thu, Jan 1, 2015 at 9:09 PM, Adam Armstrong <adama@memetic.org> wrote:
I honestly can't tell if you're intentionally trolling or not! :DDon't have time to troll. Unless I wanted to discuss IPv8 or some other silly nonsense :)And I don't
Example snmpwalks with the MIB loaded and non-numeric OIDs would be quite helpful. The actual names of those OIDs so I can find them in the MIB would be a minimum (so I can see wether they're instanced or not, and wether they'd require infrastructure to graph, or if they'd fit as a simple graph).I'll provide SNMP walks shortly.Looking up the first one, RSSI, it seems to be a signal strength measurement with no fixed scale or standards :Measured in dBm i believe. Will double check. Value is a negative float, with numbers closer to zero being "better" or higher strength. Range is more or less dictated by the applicable regulatory body, FCC in the US, etc."There is no standardized relationship of any particular physical parameter to the RSSI reading. The 802.11 standard does not define any relationship between RSSI value and power level in mW or dBm. Vendors and chipset makers provide their own accuracy".This is NOT WiFi. This is licensed fixed location microwave. Think 6 foot dishes on a tower, pointing up to 30 miles away. The RSSI number is the RF energy level received by the radio and has to be within limits set by the regulatory body and what level of modulation you are wanting to achieve and distance. It will vary depending on mother nature (rain, snow fade, etc)I assume the others are similar. There are some things in there which look like they'd fit into the existing "state" sensor type.
Once new sensor types exist, you'd just need to write a poller module for the sensors to be discovered. They'd be pretty simple, being hardcoded.
With access to the relevant hardware these things could be added pretty quickly, and then automatically available to everyone with that hardware.
adam.
P.S.
And again, for everyone's benefit:
If you're asking a question about doing something new, provide all of the information you reasonably can, including motivations and expected outcomes, because you aren't in a position to judge what information is useful or not. I have this very same exchange about once a week these days, and it's getting pretty boring. Perhaps an FAQ entry would be helpful... :D
On 2015-01-01 21:40, John Brown wrote:
MIB is here_______________________________________________
http://support.trangosys.com/attachments/token/0z6i3eorlctajt5/?name=TRANGO-PTP-MIB.txt
[2]
I want to graph, monitor and set low / high value alarms for
.1.3.6.1.4.1.5454.1.80.1.33.3.0
.1.3.6.1.4.1.5454.1.80.1.33.4.0
.1.3.6.1.4.1.5454.1.80.3.14.1.0
This would be just the start. monitoring both ODU and IDU parameters
On Thu, Jan 1, 2015 at 2:58 PM, Adam Armstrong <adama@memetic.org> wrote:
The simple answer is no, the long answer is long and depends upon many things.
You've not (in common with every other question on this subject) actually provided any information at all for us to ascertain what you're trying to do.
adam.
------ Original Message ------
From: "John Brown" <john@citylinkfiber.com>
To: "observium" <observium@observium.org>
Sent: 1/1/2015 3:29:47 PM
Subject: [Observium] add specific OID to a host to monitor.graph
Hi,
I'm working towards building some additional OS and device definitions for Observium.
At first, I would like to know if there is a way to add a specific OID to a device to be monitored.
Other words, I have a device and the standard mibs are being monitored / graph'd. I'd like to add a specific OID to also be monitored / graphed.
thanks
_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
------
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
[2]
http://support.trangosys.com/attachments/token/0z6i3eorlctajt5/?name=TRANGO-PTP-MIB.txt
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium