Dear all,
Just wondering if there was an appetite out there for expanding the interface labelling feature of observium. The existing description parsing (http://www.observium.org/wiki/Interface_Description_Parsing) is pretty useful but also a bit limiting at times, as it seems more useful when labelling layer 3 services and less so for layer 2. Just a few general comments:
* For us the pseudowires tab does not seem to auto populate (we use a variety of juniper, brocade and extreme switches and routers), just wondering if I have missed something here...
* This aside there are more frequent occasions where we are providing VPLS services for a client and it would be nice if it were possible to label an interface as both a customer and a P2P link for example and then have these separately broken down in observium itself
* There are also occasions where it would extremely useful to label backhaul circuits such as dark fibre and waves. Currently the only option for this is to label things as core but that page becomes so big it is not that useful unless you know what you are after (and then you would just go straight to the interface). Something like BACKHAUL: , PROVIDER:, END (A/B etc.) would be immensely useful and time saving.
* The other issue we have that I don't have a simple answer for is the unhelpful aggregation of customer switch ports (quite often both ends of a P2P) and their layer 3 router ports. Could we start by having a separate aggregate graph for each circuit reference for each specific client. Maybe if END A and B are specified then the graph could demonstrate that these are actually different ends of the same link?
What do people think?
BW
rob
Hi Robert,
Maybe this can help you out, we are using different interface descriptions as the default ones. The interface description parsing url you pasted needs an update in the custom section. :)
http://jira.observium.org/browse/OBSERVIUM-299
On 22 November 2014 at 13:08, Robert Hatch Robert.Hatch@vorboss.com wrote:
Dear all,
Just wondering if there was an appetite out there for expanding the interface labelling feature of observium. The existing description parsing (http://www.observium.org/wiki/Interface_Description_Parsing) is pretty useful but also a bit limiting at times, as it seems more useful when labelling layer 3 services and less so for layer 2. Just a few general comments:
· For us the pseudowires tab does not seem to auto populate (we use a variety of juniper, brocade and extreme switches and routers), just wondering if I have missed something here…
· This aside there are more frequent occasions where we are providing VPLS services for a client and it would be nice if it were possible to label an interface as both a customer and a P2P link for example and then have these separately broken down in observium itself
· There are also occasions where it would extremely useful to label backhaul circuits such as dark fibre and waves. Currently the only option for this is to label things as core but that page becomes so big it is not that useful unless you know what you are after (and then you would just go straight to the interface). Something like BACKHAUL: , PROVIDER:, END (A/B etc.) would be immensely useful and time saving.
· The other issue we have that I don’t have a simple answer for is the unhelpful aggregation of customer switch ports (quite often both ends of a P2P) and their layer 3 router ports. Could we start by having a separate aggregate graph for each circuit reference for each specific client. Maybe if END A and B are specified then the graph could demonstrate that these are actually different ends of the same link?
What do people think?
BW
rob
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Thanks prins,
Groups are certainly a step forward but they won't achieve all my aims, specifically the graphing of different services provided to clients etc.
What are other people finding?
Rob
Sent from my iPhone
On 22 Nov 2014, at 12:11, Wouter Prins <wp@null0.nlmailto:wp@null0.nl> wrote:
Hi Robert,
Maybe this can help you out, we are using different interface descriptions as the default ones. The interface description parsing url you pasted needs an update in the custom section. :)
http://jira.observium.org/browse/OBSERVIUM-299
On 22 November 2014 at 13:08, Robert Hatch <Robert.Hatch@vorboss.commailto:Robert.Hatch@vorboss.com> wrote: Dear all,
Just wondering if there was an appetite out there for expanding the interface labelling feature of observium. The existing description parsing (http://www.observium.org/wiki/Interface_Description_Parsing) is pretty useful but also a bit limiting at times, as it seems more useful when labelling layer 3 services and less so for layer 2. Just a few general comments:
• For us the pseudowires tab does not seem to auto populate (we use a variety of juniper, brocade and extreme switches and routers), just wondering if I have missed something here…
• This aside there are more frequent occasions where we are providing VPLS services for a client and it would be nice if it were possible to label an interface as both a customer and a P2P link for example and then have these separately broken down in observium itself
• There are also occasions where it would extremely useful to label backhaul circuits such as dark fibre and waves. Currently the only option for this is to label things as core but that page becomes so big it is not that useful unless you know what you are after (and then you would just go straight to the interface). Something like BACKHAUL: , PROVIDER:, END (A/B etc.) would be immensely useful and time saving.
• The other issue we have that I don’t have a simple answer for is the unhelpful aggregation of customer switch ports (quite often both ends of a P2P) and their layer 3 router ports. Could we start by having a separate aggregate graph for each circuit reference for each specific client. Maybe if END A and B are specified then the graph could demonstrate that these are actually different ends of the same link?
What do people think?
BW
rob
_______________________________________________ observium mailing list observium@observium.orgmailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
-- Wouter Prins wp@null0.nlmailto:wp@null0.nl
_______________________________________________ observium mailing list observium@observium.orgmailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Have you considered writing your own description parser? I wrote a pretty simple one in an hour or so that meets our needs and pointed to it in config.php, then created some custom menu entries via navbar-custom.inc.php.
From: Robert Hatch <Robert.Hatch@vorboss.commailto:Robert.Hatch@vorboss.com> Reply-To: Observium Network Observation System <observium@observium.orgmailto:observium@observium.org> Date: Saturday, November 22, 2014 at 6:57 AM To: Observium Network Observation System <observium@observium.orgmailto:observium@observium.org> Subject: Re: [Observium] Interface Parsing
Thanks prins,
Groups are certainly a step forward but they won't achieve all my aims, specifically the graphing of different services provided to clients etc.
What are other people finding?
Rob
Sent from my iPhone
On 22 Nov 2014, at 12:11, Wouter Prins <wp@null0.nlmailto:wp@null0.nl> wrote:
Hi Robert,
Maybe this can help you out, we are using different interface descriptions as the default ones. The interface description parsing url you pasted needs an update in the custom section. :)
http://jira.observium.org/browse/OBSERVIUM-299
On 22 November 2014 at 13:08, Robert Hatch <Robert.Hatch@vorboss.commailto:Robert.Hatch@vorboss.com> wrote: Dear all,
Just wondering if there was an appetite out there for expanding the interface labelling feature of observium. The existing description parsing (http://www.observium.org/wiki/Interface_Description_Parsing) is pretty useful but also a bit limiting at times, as it seems more useful when labelling layer 3 services and less so for layer 2. Just a few general comments:
· For us the pseudowires tab does not seem to auto populate (we use a variety of juniper, brocade and extreme switches and routers), just wondering if I have missed something here...
· This aside there are more frequent occasions where we are providing VPLS services for a client and it would be nice if it were possible to label an interface as both a customer and a P2P link for example and then have these separately broken down in observium itself
· There are also occasions where it would extremely useful to label backhaul circuits such as dark fibre and waves. Currently the only option for this is to label things as core but that page becomes so big it is not that useful unless you know what you are after (and then you would just go straight to the interface). Something like BACKHAUL: , PROVIDER:, END (A/B etc.) would be immensely useful and time saving.
· The other issue we have that I don't have a simple answer for is the unhelpful aggregation of customer switch ports (quite often both ends of a P2P) and their layer 3 router ports. Could we start by having a separate aggregate graph for each circuit reference for each specific client. Maybe if END A and B are specified then the graph could demonstrate that these are actually different ends of the same link?
What do people think?
BW
rob
_______________________________________________ observium mailing list observium@observium.orgmailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
-- Wouter Prins wp@null0.nlmailto:wp@null0.nl
_______________________________________________ observium mailing list observium@observium.orgmailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Founded in 2007, IO is a worldwide leader in software defined data center technology, services and solutions that enable businesses and governments to intelligently control their information.
The communication contained in this e-mail is confidential and is intended only for the named recipient(s) and may contain information that is privileged, proprietary, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Please immediately notify the sender of the error, and delete this communication including any attached files from your system. Thank you for your cooperation.
participants (3)
-
Pedersen, Sean -
Robert Hatch -
Wouter Prins