Hello experts,
Need some help to understand how observium handles IPSLA probes links.
We have a fully working weathermap with IP sla information (jitter, echo, etc) all nice with nodes and links.
Links are configured this way:
LINK A-B INFOURL /graphs/type=sla_jitter/id=10495/ OVERLIBGRAPH /graph.php?height=100&width=512&id=10495&type=sla_jitter&legend=no INBWFORMAT {link:this:bandwidth_in:%0} OUTBWFORMAT {link:this:bandwidth_out:%d} BWLABELPOS 50 50 TARGET gauge:../../rrd/router_A/sla_jitter-cisco-rttmon-mib-1100020-LMR_IO.rrd:rtt:rtt NODES Chicago Washington BANDWIDTH 34
Now the problem that we have is that when observium server loses connectivity with router_A (i.e. network outage, check below) It will generate a new ID for the link to the graphic hence we have to go to the editor and update INFOURL and OVERLIBGRAPH ID values.
As shown below the ID is 12961 for SLA 1100020 whereas above the ID configured was 10495.
[cid:image002.jpg@01D6075C.16B03280]
[cid:image006.jpg@01D6075C.16B03280]
This becomes very annoying as we cannot maintain a fully working IPSLA map and we're not sure why it's constantly generating new ids.
[cid:image007.jpg@01D6075C.16B03280]
Hope there is a way to force this ID not to change and remain static no matter what happens as the device ID never changes.
Thanks in advance!
--------------------------------------------------------------------- Mauro S. Cartas Global WAN Team Contact: E-mail: acc-ngwan@accenture.commailto:acc-ngwan@accenture.com Phone 1: +91 80 496 61103 (GMT 00:00 to 10:00 on weekdays and any time on Weekends) Phone 2: +420 225 071 060 (GMT 07:00 to 24:00 on weekdays only)
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy. ______________________________________________________________________________________
www.accenture.com
Hi,
as I see your screenshot, there is correct ID is 10495.
I not know how you get id 12961 in url (probably from an previously viewed page).
SLA 1100020 - is not our ID, but ID for SLA on your device.
Anyway, for any graph you can open page with that graph and click to "Link to Graph", where always will show correct id. *//* *//*Cartas, Mauro S. via observium wrote on 31.03.2020 18:58:
Hello experts,
Need some help to understand how observium handles IPSLA probes links.
We have a fully working weathermap with IP sla information (jitter, echo, etc) all nice with nodes and links.
Links are configured this way:
LINK A-B
INFOURL */graphs/type=sla_jitter/**id=10495**/*
OVERLIBGRAPH */graph.php?height=100&width=512&**id=10495**&type=sla_jitter&legend=no*
INBWFORMAT {link:this:bandwidth_in:%0}
OUTBWFORMAT {link:this:bandwidth_out:%d}
BWLABELPOS 50 50
TARGET *gauge:../../rrd/**router_A**/sla_jitter-cisco-rttmon-mib-1100020-LMR_IO.rrd:rtt:rtt*
NODES Chicago Washington
BANDWIDTH 34
Now the problem that we have is that when observium server loses connectivity with *router_A*(i.e. network outage, */check below/*) It will generate a new ID for the link to the graphic hence we have to go to the editor and update INFOURL and OVERLIBGRAPH *ID*values.
*/As shown below the ID is 12961 for SLA 1100020 whereas above the /**/ID /**/configured was /**/10495/**/./*
This becomes very annoying as we cannot maintain a fully working IPSLA map and we’re not sure why it’s constantly generating new ids.
Hope there is a way to force this ID not to change and remain static no matter what happens as the device ID never changes.
Thanks in advance!
*---------------------------------------------------------------------*
*Mauro S. Cartas*
*_Global WAN Team Contact:_*
*E-mail:*acc-ngwan@accenture.com mailto:acc-ngwan@accenture.com
*Phone 1*: +91 80 496 61103 (GMT 00:00 to 10:00 on weekdays and any time on Weekends)
*Phone 2*: +420 225 071 060 (GMT 07:00 to 24:00 on weekdays only)
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy. ______________________________________________________________________________________
www.accenture.com
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hello Mike,
I guess I didn't explain myself quite ok.
What I meant is that the ID on the URL link changes every time the server looses communication with the device, hence I have to go to weathermap editor and update all links that use that device as source of information.
"Link to graph" will show the same ID as the URL with all the summary graphics so that won't work either.
Again, the problem is that this ID changes every time there is a connectivity issue shown in the graphic below as those "blank" areas in white.
--------------------------------------------------------------------- Mauro S. Cartas Global WAN Team Contact: E-mail: acc-ngwan@accenture.commailto:acc-ngwan@accenture.com Phone 1: +91 80 496 61103 (GMT 00:00 to 10:00 on weekdays and any time on Weekends) Phone 2: +420 225 071 060 (GMT 07:00 to 24:00 on weekdays only)
From: Mike Stupalov mike@stupalov.ru On Behalf Of Mike Stupalov Sent: Friday, April 3, 2020 6:52 PM To: Observium observium@observium.org; Cartas, Mauro S. via observium observium@observium.org Cc: Cartas, Mauro S. mauro.s.cartas@accenture.com; Tomas Garcia, Jose L. jose.l.tomas.garcia@accenture.com Subject: [External] Re: [Observium] Issues with IP SLA
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments. ________________________________
Hi,
as I see your screenshot, there is correct ID is 10495.
I not know how you get id 12961 in url (probably from an previously viewed page).
SLA 1100020 - is not our ID, but ID for SLA on your device.
Anyway, for any graph you can open page with that graph and click to "Link to Graph", where always will show correct id.
Cartas, Mauro S. via observium wrote on 31.03.2020 18:58:
Hello experts,
Need some help to understand how observium handles IPSLA probes links.
We have a fully working weathermap with IP sla information (jitter, echo, etc) all nice with nodes and links.
Links are configured this way:
LINK A-B INFOURL /graphs/type=sla_jitter/id=10495/ OVERLIBGRAPH /graph.php?height=100&width=512&id=10495&type=sla_jitter&legend=no INBWFORMAT {link:this:bandwidth_in:%0} OUTBWFORMAT {link:this:bandwidth_out:%d} BWLABELPOS 50 50 TARGET gauge:../../rrd/router_A/sla_jitter-cisco-rttmon-mib-1100020-LMR_IO.rrd:rtt:rtt NODES Chicago Washington BANDWIDTH 34
Now the problem that we have is that when observium server loses connectivity with router_A (i.e. network outage, check below) It will generate a new ID for the link to the graphic hence we have to go to the editor and update INFOURL and OVERLIBGRAPH ID values.
As shown below the ID is 12961 for SLA 1100020 whereas above the ID configured was 10495.
[cid:image002.jpg@01D609FA.77144760]
[cid:image004.jpg@01D609FA.77144760]
This becomes very annoying as we cannot maintain a fully working IPSLA map and we're not sure why it's constantly generating new ids.
[cid:image006.jpg@01D609FA.77144760]
Hope there is a way to force this ID not to change and remain static no matter what happens as the device ID never changes.
Thanks in advance!
--------------------------------------------------------------------- Mauro S. Cartas Global WAN Team Contact: E-mail: acc-ngwan@accenture.commailto:acc-ngwan@accenture.com Phone 1: +91 80 496 61103 (GMT 00:00 to 10:00 on weekdays and any time on Weekends) Phone 2: +420 225 071 060 (GMT 07:00 to 24:00 on weekdays only)
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy. ______________________________________________________________________________________
www.accenture.comhttp://www.accenture.com
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observiumhttps://urldefense.proofpoint.com/v2/url?u=http-3A__postman.memetic.org_cgi-2Dbin_mailman_listinfo_observium&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=McbgqmvvydV65sgbP0BXGKJV4cVm85IpgT_CI3xWCKk&m=culuC4HIOarZ4EgNZCZm9ThNNq2ZSLZH75y3FDoOr5g&s=boTOyHV4YTpCkKjPEPfX_IUTTSeB--JTvb0IIZleyZU&e=
-- Mike Stupalov Observium Limited, http://observium.orghttps://urldefense.proofpoint.com/v2/url?u=http-3A__observium.org&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=McbgqmvvydV65sgbP0BXGKJV4cVm85IpgT_CI3xWCKk&m=culuC4HIOarZ4EgNZCZm9ThNNq2ZSLZH75y3FDoOr5g&s=w2owcCPLPibcPb2qH37K1yG8otXE9mvB-FPmFl6pPtw&e=
We can't use the device SLA ID because two or 500 devices could have the same ID.
It's possible we could have an alternative mode which takes device_id and sla_index, though this might not work on all device types.
We already do this in some instances, like allowing hostname and/or ifDescr to be used in place of device_id and port_id
Adam.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Cartas, Mauro S. via observium Sent: 04 April 2020 01:03 To: Mike Stupalov mike@observium.org; Observium observium@observium.org; Cartas, Mauro S. via observium observium@observium.org Cc: Cartas, Mauro S. mauro.s.cartas@accenture.com; Tomas Garcia, Jose L. jose.l.tomas.garcia@accenture.com Subject: Re: [Observium] [External] Re: Issues with IP SLA
Hello Mike,
I guess I didn't explain myself quite ok.
What I meant is that the ID on the URL link changes every time the server looses communication with the device, hence I have to go to weathermap editor and update all links that use that device as source of information.
"Link to graph" will show the same ID as the URL with all the summary graphics so that won't work either.
Again, the problem is that this ID changes every time there is a connectivity issue shown in the graphic below as those "blank" areas in white.
---------------------------------------------------------------------
Mauro S. Cartas
Global WAN Team Contact:
E-mail: mailto:acc-ngwan@accenture.com acc-ngwan@accenture.com
Phone 1: +91 80 496 61103 (GMT 00:00 to 10:00 on weekdays and any time on Weekends)
Phone 2: +420 225 071 060 (GMT 07:00 to 24:00 on weekdays only)
From: Mike Stupalov <mike@stupalov.ru mailto:mike@stupalov.ru > On Behalf Of Mike Stupalov Sent: Friday, April 3, 2020 6:52 PM To: Observium <observium@observium.org mailto:observium@observium.org >; Cartas, Mauro S. via observium <observium@observium.org mailto:observium@observium.org > Cc: Cartas, Mauro S. <mauro.s.cartas@accenture.com mailto:mauro.s.cartas@accenture.com >; Tomas Garcia, Jose L. <jose.l.tomas.garcia@accenture.com mailto:jose.l.tomas.garcia@accenture.com > Subject: [External] Re: [Observium] Issues with IP SLA
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.
_____
Hi,
as I see your screenshot, there is correct ID is 10495.
I not know how you get id 12961 in url (probably from an previously viewed page).
SLA 1100020 - is not our ID, but ID for SLA on your device.
Anyway, for any graph you can open page with that graph and click to "Link to Graph", where always will show correct id.
Cartas, Mauro S. via observium wrote on 31.03.2020 18:58:
Hello experts,
Need some help to understand how observium handles IPSLA probes links.
We have a fully working weathermap with IP sla information (jitter, echo, etc) all nice with nodes and links.
Links are configured this way:
LINK A-B
INFOURL /graphs/type=sla_jitter/id=10495/
OVERLIBGRAPH /graph.php?height=100&width=512&id=10495&type=sla_jitter&legend=no
INBWFORMAT {link:this:bandwidth_in:%0}
OUTBWFORMAT {link:this:bandwidth_out:%d}
BWLABELPOS 50 50
TARGET gauge:../../rrd/router_A/sla_jitter-cisco-rttmon-mib-1100020-LMR_IO.rrd:rtt: rtt
NODES Chicago Washington
BANDWIDTH 34
Now the problem that we have is that when observium server loses connectivity with router_A (i.e. network outage, check below) It will generate a new ID for the link to the graphic hence we have to go to the editor and update INFOURL and OVERLIBGRAPH ID values.
As shown below the ID is 12961 for SLA 1100020 whereas above the ID configured was 10495.
This becomes very annoying as we cannot maintain a fully working IPSLA map and we're not sure why it's constantly generating new ids.
Hope there is a way to force this ID not to change and remain static no matter what happens as the device ID never changes.
Thanks in advance!
---------------------------------------------------------------------
Mauro S. Cartas
Global WAN Team Contact:
E-mail: mailto:acc-ngwan@accenture.com acc-ngwan@accenture.com
Phone 1: +91 80 496 61103 (GMT 00:00 to 10:00 on weekdays and any time on Weekends)
Phone 2: +420 225 071 060 (GMT 07:00 to 24:00 on weekdays only)
_____
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy. ____________________________________________________________________________ __________
www.accenture.com http://www.accenture.com
_______________________________________________ observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium https://urldefense.proofpoint.com/v2/url?u=http-3A__postman.memetic.org_cgi -2Dbin_mailman_listinfo_observium&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrU K8IrwNKOtkVU&r=McbgqmvvydV65sgbP0BXGKJV4cVm85IpgT_CI3xWCKk&m=culuC4HIOarZ4Eg NZCZm9ThNNq2ZSLZH75y3FDoOr5g&s=boTOyHV4YTpCkKjPEPfX_IUTTSeB--JTvb0IIZleyZU&e =
participants (3)
-
Adam Armstrong -
Cartas, Mauro S. -
Mike Stupalov