Re: [Observium] ifAlias Description notmatches multiple wildcard issue
![](https://secure.gravatar.com/avatar/0fa97865a0e1ab36152b6b2299eedb49.jpg?s=120&d=mm&r=g)
Use attributes as attributes.
You probably don't want to create permanent alert table entries just for this, and it's not time critical.
Using attributes to match these non-valid descriptions, an alert table entry would only be created when it's necessary, and then you can just use an unrealistic metric condition to make it always trigger.
adam.
------ Original Message ------ From: "Klimek, Denis" DKlimek@Stadtwerke-Norderstedt.de To: "'observium@observium.org'" observium@observium.org Sent: 2018-07-26 15:01:55 Subject: [Observium] ifAlias Description notmatches multiple wildcard issue
Hi all,
I would like to setup a alert checker which checks configured Ethernet ports if there is a “valid” Observium port description configured. I tried it with following conditions “ifAlias notmatches *:*[*Gbit]*{*}*(*)*:*:” but it’s reporting any port as “OK”. The “::” got added by us for internal purposes.
B: POP102-TBA [20Gbit] {} () ::-> get’s reported as “OK” which is correct
CERRZ2R_C_X670-> get’s reported also as “OK” but this is wrong
Attached a screenshot of the complete rule set.
Any ideas are welcome how to solve this J
Mit freundlichem Gruß
Stadtwerke Norderstedt
Denis Klimek
Professional Network Engineer
IP-Systemtechnik
Tel: 040 / 521 04 – 1049
Mobil: 0151 / 652 219 06
dklimek@stadtwerke-norderstedt.de
www.stadtwerke-norderstedt.de
![](https://secure.gravatar.com/avatar/22b9fee005332ad201332f6af605cfd9.jpg?s=120&d=mm&r=g)
Mhh! I understand what you mean ☺ I will try this, you’re right it’s not time critical and during every full discover it will rebuild the alert association.
Regarding the custom type categories. Is there a way how Observium can support them too to add the description information into the port_descr_* fiels? Or do we have to adjust any config parameters to get them supported? We are not using only core,peering,server,transit,customer… also using “B”,”T”,”P” etc pp for internal purposes but with the correct syntax style.
Mit freundlichem Gruß Stadtwerke Norderstedt
Denis Klimek
Professional Network Engineer IP-Systemtechnik
Tel: 040 / 521 04 – 1049 Mobil: 0151 / 652 219 06
dklimek@stadtwerke-norderstedt.demailto:dklimek@stadtwerke-norderstedt.de www.stadtwerke-norderstedt.dehttp://www.stadtwerke-norderstedt.de/
Von: observium [mailto:observium-bounces@observium.org] Im Auftrag von Adam Armstrong Gesendet: Dienstag, 31. Juli 2018 17:02 An: Observium Betreff: Re: [Observium] ifAlias Description notmatches multiple wildcard issue
Use attributes as attributes.
You probably don't want to create permanent alert table entries just for this, and it's not time critical.
Using attributes to match these non-valid descriptions, an alert table entry would only be created when it's necessary, and then you can just use an unrealistic metric condition to make it always trigger.
adam.
------ Original Message ------ From: "Klimek, Denis" <DKlimek@Stadtwerke-Norderstedt.demailto:DKlimek@Stadtwerke-Norderstedt.de> To: "'observium@observium.org'" <observium@observium.orgmailto:observium@observium.org> Sent: 2018-07-26 15:01:55 Subject: [Observium] ifAlias Description notmatches multiple wildcard issue
Hi all,
I would like to setup a alert checker which checks configured Ethernet ports if there is a “valid” Observium port description configured. I tried it with following conditions “ifAlias notmatches *:*[*Gbit]*{*}*(*)*:*:” but it’s reporting any port as “OK”. The “::” got added by us for internal purposes.
B: POP102-TBA [20Gbit] {} () ::-> get’s reported as “OK” which is correct CERRZ2R_C_X670-> get’s reported also as “OK” but this is wrong
Attached a screenshot of the complete rule set.
Any ideas are welcome how to solve this ☺
Mit freundlichem Gruß Stadtwerke Norderstedt
Denis Klimek
Professional Network Engineer IP-Systemtechnik
Tel: 040 / 521 04 – 1049 Mobil: 0151 / 652 219 06
dklimek@stadtwerke-norderstedt.demailto:dklimek@stadtwerke-norderstedt.de www.stadtwerke-norderstedt.dehttp://www.stadtwerke-norderstedt.de/
![](https://secure.gravatar.com/avatar/3bbbd945c333b8013d0dfa23058f65b9.jpg?s=120&d=mm&r=g)
Klimek, Denis mailto:DKlimek@Stadtwerke-Norderstedt.de 31 July 2018 at 18:15
Mhh! I understand what you mean JI will try this, you’re right it’s not time critical and during every full discover it will rebuild the alert association.
Regarding the custom type categories. Is there a way how Observium can support them too to add the description information into the port_descr_* fiels? Or do we have to adjust any config parameters to get them supported?
We are not using only core,peering,server,transit,customer… also using “B”,”T”,”P” etc pp for internal purposes but with the correct syntax style.
This named as "Port Parsed (Type, Descriprion, etc)"
Mit freundlichem Gruß
Stadtwerke Norderstedt
*Denis Klimek*
Professional Network Engineer
IP-Systemtechnik
Tel: 040 / 521 04 – 1049
Mobil: 0151 / 652 219 06
dklimek@stadtwerke-norderstedt.de mailto:dklimek@stadtwerke-norderstedt.de
www.stadtwerke-norderstedt.de http://www.stadtwerke-norderstedt.de/
*Von:*observium [mailto:observium-bounces@observium.org] *Im Auftrag von *Adam Armstrong *Gesendet:* Dienstag, 31. Juli 2018 17:02 *An:* Observium *Betreff:* Re: [Observium] ifAlias Description notmatches multiple wildcard issue
Use attributes as attributes.
You probably don't want to create permanent alert table entries just for this, and it's not time critical.
Using attributes to match these non-valid descriptions, an alert table entry would only be created when it's necessary, and then you can just use an unrealistic metric condition to make it always trigger.
adam.
------ Original Message ------
From: "Klimek, Denis" <DKlimek@Stadtwerke-Norderstedt.de mailto:DKlimek@Stadtwerke-Norderstedt.de>
To: "'observium@observium.org'" <observium@observium.org mailto:observium@observium.org>
Sent: 2018-07-26 15:01:55
Subject: [Observium] ifAlias Description notmatches multiple wildcard issue
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium Adam Armstrong mailto:adama@memetic.org 31 July 2018 at 18:01 Use attributes as attributes.
You probably don't want to create permanent alert table entries just for this, and it's not time critical.
Using attributes to match these non-valid descriptions, an alert table entry would only be created when it's necessary, and then you can just use an unrealistic metric condition to make it always trigger.
adam.
------ Original Message ------ From: "Klimek, Denis" <DKlimek@Stadtwerke-Norderstedt.de mailto:DKlimek@Stadtwerke-Norderstedt.de> To: "'observium@observium.org'" <observium@observium.org mailto:observium@observium.org> Sent: 2018-07-26 15:01:55 Subject: [Observium] ifAlias Description notmatches multiple wildcard issue
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
participants (3)
-
Adam Armstrong
-
Klimek, Denis
-
Mike Stupalov