Moving an interface from one device to another and having the graph follow
I just moved a transit link from router 1 to router 2. I cleared the old interface on router 1 and copied it to router 2. When I went back to my Observium graphs, the aggregate graphs picked up the interface in the transit aggregate graph, but all the old data was lost. I guess this doesn't really surprise me, although it might be kinda cool to have Observium automagically move the graph to the new interface if the new interface description matches, but that might be a little problematic if there was ever a case where a dedupe was required on interface descriptions, so I digress..
Is there a way to get that old data back somehow?
Thanks in advance.
We explicitely do not allow this to happen.
A graph's data is related to an interface, not a service.
adam.
On 29/11/2012 15:20, Jason Lixfeld wrote:
I just moved a transit link from router 1 to router 2. I cleared the old interface on router 1 and copied it to router 2. When I went back to my Observium graphs, the aggregate graphs picked up the interface in the transit aggregate graph, but all the old data was lost. I guess this doesn't really surprise me, although it might be kinda cool to have Observium automagically move the graph to the new interface if the new interface description matches, but that might be a little problematic if there was ever a case where a dedupe was required on interface descriptions, so I digress..
Is there a way to get that old data back somehow?
Thanks in advance. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
... unless you copy over the correct rrd file manually, of course.
On 29/11/2012 22:32, Adam Armstrong wrote:
We explicitely do not allow this to happen.
A graph's data is related to an interface, not a service.
adam.
On 29/11/2012 15:20, Jason Lixfeld wrote:
I just moved a transit link from router 1 to router 2. I cleared the old interface on router 1 and copied it to router 2. When I went back to my Observium graphs, the aggregate graphs picked up the interface in the transit aggregate graph, but all the old data was lost. I guess this doesn't really surprise me, although it might be kinda cool to have Observium automagically move the graph to the new interface if the new interface description matches, but that might be a little problematic if there was ever a case where a dedupe was required on interface descriptions, so I digress..
Is there a way to get that old data back somehow?
Thanks in advance. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
BURN THE HERETIC
On 29/11/2012 17:58, Tom Laermans wrote:
... unless you copy over the correct rrd file manually, of course.
On 29/11/2012 22:32, Adam Armstrong wrote:
We explicitely do not allow this to happen.
A graph's data is related to an interface, not a service.
adam.
On 29/11/2012 15:20, Jason Lixfeld wrote:
I just moved a transit link from router 1 to router 2. I cleared the old interface on router 1 and copied it to router 2. When I went back to my Observium graphs, the aggregate graphs picked up the interface in the transit aggregate graph, but all the old data was lost. I guess this doesn't really surprise me, although it might be kinda cool to have Observium automagically move the graph to the new interface if the new interface description matches, but that might be a little problematic if there was ever a case where a dedupe was required on interface descriptions, so I digress..
Is there a way to get that old data back somehow?
Thanks in advance. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
This is not recommended because it will also copy other statistics, such as errors and etherlike-mib stats.
adam.
On 29/11/2012 17:58, Tom Laermans wrote:
... unless you copy over the correct rrd file manually, of course.
On 29/11/2012 22:32, Adam Armstrong wrote:
We explicitely do not allow this to happen.
A graph's data is related to an interface, not a service.
adam.
On 29/11/2012 15:20, Jason Lixfeld wrote:
I just moved a transit link from router 1 to router 2. I cleared the old interface on router 1 and copied it to router 2. When I went back to my Observium graphs, the aggregate graphs picked up the interface in the transit aggregate graph, but all the old data was lost. I guess this doesn't really surprise me, although it might be kinda cool to have Observium automagically move the graph to the new interface if the new interface description matches, but that might be a little problematic if there was ever a case where a dedupe was required on interface descriptions, so I digress..
Is there a way to get that old data back somehow?
Thanks in advance. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Yes, and it will make it seem like the interface had traffic which it never had, so you're essentially changing history. Was just sayin'. ;)
On 30/11/2012 1:02, Adam Armstrong wrote:
This is not recommended because it will also copy other statistics, such as errors and etherlike-mib stats.
adam.
On 29/11/2012 17:58, Tom Laermans wrote:
... unless you copy over the correct rrd file manually, of course.
On 29/11/2012 22:32, Adam Armstrong wrote:
We explicitely do not allow this to happen.
A graph's data is related to an interface, not a service.
adam.
On 29/11/2012 15:20, Jason Lixfeld wrote:
I just moved a transit link from router 1 to router 2. I cleared the old interface on router 1 and copied it to router 2. When I went back to my Observium graphs, the aggregate graphs picked up the interface in the transit aggregate graph, but all the old data was lost. I guess this doesn't really surprise me, although it might be kinda cool to have Observium automagically move the graph to the new interface if the new interface description matches, but that might be a little problematic if there was ever a case where a dedupe was required on interface descriptions, so I digress..
Is there a way to get that old data back somehow?
Thanks in advance. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
So would it be a compromise to copy over the rrd for graphing and scrap mib stats? (optionally)
Jacob Gardiner
On Fri, Nov 30, 2012 at 11:12 AM, Tom Laermans tom.laermans@powersource.cxwrote:
Yes, and it will make it seem like the interface had traffic which it never had, so you're essentially changing history. Was just sayin'. ;)
On 30/11/2012 1:02, Adam Armstrong wrote:
This is not recommended because it will also copy other statistics, such as errors and etherlike-mib stats.
adam.
On 29/11/2012 17:58, Tom Laermans wrote:
... unless you copy over the correct rrd file manually, of course.
On 29/11/2012 22:32, Adam Armstrong wrote:
We explicitely do not allow this to happen.
A graph's data is related to an interface, not a service.
adam.
On 29/11/2012 15:20, Jason Lixfeld wrote:
I just moved a transit link from router 1 to router 2. I cleared the old interface on router 1 and copied it to router 2. When I went back to my Observium graphs, the aggregate graphs picked up the interface in the transit aggregate graph, but all the old data was lost. I guess this doesn't really surprise me, although it might be kinda cool to have Observium automagically move the graph to the new interface if the new interface description matches, but that might be a little problematic if there was ever a case where a dedupe was required on interface descriptions, so I digress..
Is there a way to get that old data back somehow?
Thanks in advance. ______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
______________________________**_________________ observium mailing list observium@observium.org http://postman.memetic.org/**cgi-bin/mailman/listinfo/**observiumhttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
I'd say it's a whole lot of arsing around and would severly reduce the believability of the data for something that very rarely happens.
On 05/12/2012 21:05, Jacob Gardiner wrote:
So would it be a compromise to copy over the rrd for graphing and scrap mib stats? (optionally)
Jacob Gardiner
On Fri, Nov 30, 2012 at 11:12 AM, Tom Laermans <tom.laermans@powersource.cx mailto:tom.laermans@powersource.cx> wrote:
Yes, and it will make it seem like the interface had traffic which it never had, so you're essentially changing history. Was just sayin'. ;) On 30/11/2012 1:02, Adam Armstrong wrote: This is not recommended because it will also copy other statistics, such as errors and etherlike-mib stats. adam. On 29/11/2012 17:58, Tom Laermans wrote: ... unless you copy over the correct rrd file manually, of course. On 29/11/2012 22:32, Adam Armstrong wrote: We explicitely do not allow this to happen. A graph's data is related to an interface, not a service. adam. On 29/11/2012 15:20, Jason Lixfeld wrote: I just moved a transit link from router 1 to router 2. I cleared the old interface on router 1 and copied it to router 2. When I went back to my Observium graphs, the aggregate graphs picked up the interface in the transit aggregate graph, but all the old data was lost. I guess this doesn't really surprise me, although it might be kinda cool to have Observium automagically move the graph to the new interface if the new interface description matches, but that might be a little problematic if there was ever a case where a dedupe was required on interface descriptions, so I digress.. Is there a way to get that old data back somehow? Thanks in advance. _______________________________________________ observium mailing list observium@observium.org <mailto:observium@observium.org> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium _______________________________________________ observium mailing list observium@observium.org <mailto:observium@observium.org> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium _______________________________________________ observium mailing list observium@observium.org <mailto:observium@observium.org> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium _______________________________________________ observium mailing list observium@observium.org <mailto:observium@observium.org> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium _______________________________________________ observium mailing list observium@observium.org <mailto:observium@observium.org> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Upgrades/migrations are rare? Unlikely.
Jacob Gardiner
On Thu, Dec 6, 2012 at 5:09 PM, Adam Armstrong adama@memetic.org wrote:
I'd say it's a whole lot of arsing around and would severly reduce the believability of the data for something that very rarely happens.
On 05/12/2012 21:05, Jacob Gardiner wrote:
So would it be a compromise to copy over the rrd for graphing and scrap mib stats? (optionally)
Jacob Gardiner
On Fri, Nov 30, 2012 at 11:12 AM, Tom Laermans < tom.laermans@powersource.cx> wrote:
Yes, and it will make it seem like the interface had traffic which it never had, so you're essentially changing history. Was just sayin'. ;)
On 30/11/2012 1:02, Adam Armstrong wrote:
This is not recommended because it will also copy other statistics, such as errors and etherlike-mib stats.
adam.
On 29/11/2012 17:58, Tom Laermans wrote:
... unless you copy over the correct rrd file manually, of course.
On 29/11/2012 22:32, Adam Armstrong wrote:
We explicitely do not allow this to happen.
A graph's data is related to an interface, not a service.
adam.
On 29/11/2012 15:20, Jason Lixfeld wrote:
I just moved a transit link from router 1 to router 2. I cleared the old interface on router 1 and copied it to router 2. When I went back to my Observium graphs, the aggregate graphs picked up the interface in the transit aggregate graph, but all the old data was lost. I guess this doesn't really surprise me, although it might be kinda cool to have Observium automagically move the graph to the new interface if the new interface description matches, but that might be a little problematic if there was ever a case where a dedupe was required on interface descriptions, so I digress..
Is there a way to get that old data back somehow?
Thanks in advance. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing listobservium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 06/12/2012, at 09.24, Jacob Gardiner jacob@jacobgardiner.com wrote:
Upgrades/migrations are rare? Unlikely.
A software upgrade on our SRX boxes changed the SNMP interfaces number, so we have seen this across multiple devices :-(
I dont mind a manual process, but if we could have this described in some way it would be nice.
Best regards
Henrik -- Henrik Lund Kramshøj, Follower of the Great Way of Unix internet samurai cand.scient CISSP hlk@kramse.org hlk@solidonetworks.com +45 2026 6000 http://solidonetworks.com/ Network Security is a business enabler
On 12/06/2012 06:47 PM, Henrik Lund Kramshøj wrote:
On 06/12/2012, at 09.24, Jacob Gardiner jacob@jacobgardiner.com wrote:
Upgrades/migrations are rare? Unlikely.
A software upgrade on our SRX boxes changed the SNMP interfaces number, so we have seen this across multiple devices :-(
I dont mind a manual process, but if we could have this described in some way it would be nice.
Not to mention the stupidity of SNMP implementations on Linux & Windows, where certain interfaces (e.g. pppX on Linux) disappear and reappear randomly.
Paul
Sure, but it is following rfc, where it say you shouldnt relay on ifindex as may change across reboots
On 07.12.2012, at 4:01, Paul Gear observium@gear.dyndns.org wrote:
On 12/06/2012 06:47 PM, Henrik Lund Kramshøj wrote:
On 06/12/2012, at 09.24, Jacob Gardiner jacob@jacobgardiner.com wrote:
Upgrades/migrations are rare? Unlikely.
A software upgrade on our SRX boxes changed the SNMP interfaces number, so we have seen this across multiple devices :-(
I dont mind a manual process, but if we could have this described in some way it would be nice.
Not to mention the stupidity of SNMP implementations on Linux & Windows, where certain interfaces (e.g. pppX on Linux) disappear and reappear randomly.
Paul _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Name & shame silly bounces, bouncing Nikolay's email:
jeremy@azuria.net: host mx1.azuria.net[62.233.62.10] said: 550 5.7.1 Sorry, Russian mail not allowed here (in reply to end of DATA command)
Funniest bounce I've seen in ages. Even funnier than the stupid American corporate systems who bounce messages with "shit" in!
adam.
On 07/12/2012 00:21, Nikolay Shopik wrote:
Sure, but it is following rfc, where it say you shouldnt relay on ifindex as may change across reboots
On 07.12.2012, at 4:01, Paul Gear observium@gear.dyndns.org wrote:
On 12/06/2012 06:47 PM, Henrik Lund Kramshøj wrote:
On 06/12/2012, at 09.24, Jacob Gardiner jacob@jacobgardiner.com wrote:
Upgrades/migrations are rare? Unlikely.
A software upgrade on our SRX boxes changed the SNMP interfaces number, so we have seen this across multiple devices :-(
I dont mind a manual process, but if we could have this described in some way it would be nice.
Not to mention the stupidity of SNMP implementations on Linux & Windows, where certain interfaces (e.g. pppX on Linux) disappear and reappear randomly.
Paul _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Blindly belive its russian because of tld even more stupid. Not checking encoding nor IP where it comes from at least.
On 07.12.2012, at 11:12, Adam Armstrong adama@memetic.org wrote:
Name & shame silly bounces, bouncing Nikolay's email:
jeremy@azuria.net: host mx1.azuria.net[62.233.62.10] said: 550 5.7.1 Sorry, Russian mail not allowed here (in reply to end of DATA command)
Funniest bounce I've seen in ages. Even funnier than the stupid American corporate systems who bounce messages with "shit" in!
adam.
On 07/12/2012 00:21, Nikolay Shopik wrote:
Sure, but it is following rfc, where it say you shouldnt relay on ifindex as may change across reboots
On 07.12.2012, at 4:01, Paul Gear observium@gear.dyndns.org wrote:
On 12/06/2012 06:47 PM, Henrik Lund Kramshøj wrote:
On 06/12/2012, at 09.24, Jacob Gardiner jacob@jacobgardiner.com wrote:
Upgrades/migrations are rare? Unlikely.
A software upgrade on our SRX boxes changed the SNMP interfaces number, so we have seen this across multiple devices :-(
I dont mind a manual process, but if we could have this described in some way it would be nice.
Not to mention the stupidity of SNMP implementations on Linux & Windows, where certain interfaces (e.g. pppX on Linux) disappear and reappear randomly.
Paul _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
The sad part is that you can't rely on ifName or ifDescr either, because 33% of vendors just return "ethernet interface" for them!
adam.
On 07/12/2012 00:21, Nikolay Shopik wrote:
Sure, but it is following rfc, where it say you shouldnt relay on ifindex as may change across reboots
On 07.12.2012, at 4:01, Paul Gear observium@gear.dyndns.org wrote:
On 12/06/2012 06:47 PM, Henrik Lund Kramshøj wrote:
On 06/12/2012, at 09.24, Jacob Gardiner jacob@jacobgardiner.com wrote:
Upgrades/migrations are rare? Unlikely.
A software upgrade on our SRX boxes changed the SNMP interfaces number, so we have seen this across multiple devices :-(
I dont mind a manual process, but if we could have this described in some way it would be nice.
Not to mention the stupidity of SNMP implementations on Linux & Windows, where certain interfaces (e.g. pppX on Linux) disappear and reappear randomly.
Paul _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Sure, ifindex is more stable then these two.
On 07.12.2012, at 11:13, Adam Armstrong adama@memetic.org wrote:
The sad part is that you can't rely on ifName or ifDescr either, because 33% of vendors just return "ethernet interface" for them!
adam.
On 07/12/2012 00:21, Nikolay Shopik wrote:
Sure, but it is following rfc, where it say you shouldnt relay on ifindex as may change across reboots
On 07.12.2012, at 4:01, Paul Gear observium@gear.dyndns.org wrote:
On 12/06/2012 06:47 PM, Henrik Lund Kramshøj wrote:
On 06/12/2012, at 09.24, Jacob Gardiner jacob@jacobgardiner.com wrote:
Upgrades/migrations are rare? Unlikely.
A software upgrade on our SRX boxes changed the SNMP interfaces number, so we have seen this across multiple devices :-(
I dont mind a manual process, but if we could have this described in some way it would be nice.
Not to mention the stupidity of SNMP implementations on Linux & Windows, where certain interfaces (e.g. pppX on Linux) disappear and reappear randomly.
Paul _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
You haven't seen our DSL lines. ;-)
I have remote site Linux routers monitored by Observium that have 2000+ leftover ppp0 interfaces. I keep meaning to dig into the code and find a way to merge them intelligently, but i haven't had the time yet.
On 12/07/2012 06:10 PM, Nikolay Shopik wrote:
Sure, ifindex is more stable then these two.
On 07.12.2012, at 11:13, Adam Armstrong adama@memetic.org wrote:
The sad part is that you can't rely on ifName or ifDescr either, because 33% of vendors just return "ethernet interface" for them!
adam.
...
Not to mention the stupidity of SNMP implementations on Linux & Windows, where certain interfaces (e.g. pppX on Linux) disappear and reappear randomly.
Something along the lines of :
if there is an an existing deleted interface with the same ifName, grab its port_id
*this* wouldn't be all that difficult, perhaps...
On 07/12/2012 16:17, Paul Gear wrote:
You haven't seen our DSL lines. ;-)
I have remote site Linux routers monitored by Observium that have 2000+ leftover ppp0 interfaces. I keep meaning to dig into the code and find a way to merge them intelligently, but i haven't had the time yet.
On 12/07/2012 06:10 PM, Nikolay Shopik wrote:
Sure, ifindex is more stable then these two.
On 07.12.2012, at 11:13, Adam Armstrong adama@memetic.org wrote:
The sad part is that you can't rely on ifName or ifDescr either, because 33% of vendors just return "ethernet interface" for them!
adam.
...
Not to mention the stupidity of SNMP implementations on Linux & Windows, where certain interfaces (e.g. pppX on Linux) disappear and reappear randomly.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 07/12/2012 16:20, Adam Armstrong wrote:
Something along the lines of :
if there is an an existing deleted interface with the same ifName, grab its port_id
Though, this wouldn't work when two interfaces are flipped (happens a lot on linux reboots).
Possibly at poll time we could compare ifName and grab a different port_id even if the port isn't deleted?
Possibly a per-OS whitelist to enable the functionality would work, but checking this stuff at every poll might prove... fragile.
adam.
On 12/08/2012 08:23 AM, Adam Armstrong wrote:
On 07/12/2012 16:20, Adam Armstrong wrote:
Something along the lines of :
if there is an an existing deleted interface with the same ifName, grab its port_id
Though, this wouldn't work when two interfaces are flipped (happens a lot on linux reboots).
Possibly at poll time we could compare ifName and grab a different port_id even if the port isn't deleted?
Possibly a per-OS whitelist to enable the functionality would work, but checking this stuff at every poll might prove... fragile.
On 12/08/2012 08:23 AM, Tom Laermans wrote:
But the RRD is numbered after the ifIndex...
Sounds like all of the solutions are bound to be icky. I personally think that in order to do it in a non-fragile manner it would be necessary to look at the time range of data in the RRD, which is probably too intensive to do in the poller.
Paul
But the RRD is numbered after the ifIndex...
On 7/12/2012 23:20, Adam Armstrong wrote:
Something along the lines of :
if there is an an existing deleted interface with the same ifName, grab its port_id
*this* wouldn't be all that difficult, perhaps...
On 07/12/2012 16:17, Paul Gear wrote:
You haven't seen our DSL lines. ;-)
I have remote site Linux routers monitored by Observium that have 2000+ leftover ppp0 interfaces. I keep meaning to dig into the code and find a way to merge them intelligently, but i haven't had the time yet.
On 12/07/2012 06:10 PM, Nikolay Shopik wrote:
Sure, ifindex is more stable then these two.
On 07.12.2012, at 11:13, Adam Armstrong adama@memetic.org wrote:
The sad part is that you can't rely on ifName or ifDescr either, because 33% of vendors just return "ethernet interface" for them!
adam.
...
Not to mention the stupidity of SNMP implementations on Linux & Windows, where certain interfaces (e.g. pppX on Linux) disappear and reappear randomly.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 07/12/2012 16:23, Tom Laermans wrote:
But the RRD is numbered after the ifIndex...
Perhaps we could name them based on ifName for OSes which cause issues? (Linux/Windows)
adam.
On 7/12/2012 23:20, Adam Armstrong wrote:
Something along the lines of :
if there is an an existing deleted interface with the same ifName, grab its port_id
*this* wouldn't be all that difficult, perhaps...
On 07/12/2012 16:17, Paul Gear wrote:
You haven't seen our DSL lines. ;-)
I have remote site Linux routers monitored by Observium that have 2000+ leftover ppp0 interfaces. I keep meaning to dig into the code and find a way to merge them intelligently, but i haven't had the time yet.
On 12/07/2012 06:10 PM, Nikolay Shopik wrote:
Sure, ifindex is more stable then these two.
On 07.12.2012, at 11:13, Adam Armstrong adama@memetic.org wrote:
The sad part is that you can't rely on ifName or ifDescr either, because 33% of vendors just return "ethernet interface" for them!
adam.
...
> Not to mention the stupidity of SNMP implementations on Linux & > Windows, where certain interfaces (e.g. pppX on Linux) disappear > and reappear randomly.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 7/12/2012 23:39, Adam Armstrong wrote:
On 07/12/2012 16:23, Tom Laermans wrote:
But the RRD is numbered after the ifIndex...
Perhaps we could name them based on ifName for OSes which cause issues? (Linux/Windows)
Possible - I guess we best put the filename in the database then, to not have 500 places in the code try and figure out the filename based on whatever parameters. :-)
Tom
On 07/12/2012 16:43, Tom Laermans wrote:
On 7/12/2012 23:39, Adam Armstrong wrote:
On 07/12/2012 16:23, Tom Laermans wrote:
But the RRD is numbered after the ifIndex...
Perhaps we could name them based on ifName for OSes which cause issues? (Linux/Windows)
Possible - I guess we best put the filename in the database then, to not have 500 places in the code try and figure out the filename based on whatever parameters. :-)
We would probably do it how we do the sensors rrd filenames with get_sensor_rrd.
get_port_rrd($port)
:D
participants (7)
-
Adam Armstrong -
Henrik Lund Kramshøj -
Jacob Gardiner -
Jason Lixfeld -
Nikolay Shopik -
Paul Gear -
Tom Laermans