Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Object order not respected #213

Open
fabienmagagnosc opened this issue Nov 20, 2024 · 6 comments
Open

Object order not respected #213

fabienmagagnosc opened this issue Nov 20, 2024 · 6 comments
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@fabienmagagnosc
Copy link

What did you do?

I added 4 templates to the original trap, to provide more data to the SNMP system

What did you expect to see?

a simple trap with the trap object ID respected

What did you see instead? Under which circumstances?

the trap is generated, but the order of the ObjectID are not respected, causing parsing issue by the libreNM and openNMS

Environment

docker/latest SNMP notifier

  • System information:

    not applicable

  • SNMP notifier version:

~ $ snmp_notifier --version --help
snmp_notifier, version 1.5.0 (branch: HEAD, revision: af4f2a9)
build user: root@b0fff167f945
build date: 20231105-08:03:08
go version: go1.21.3
platform: linux/amd64
tags: netgo

  • Alertmanager version:

/alertmanager $ alertmanager --version
alertmanager, version 0.27.0 (branch: HEAD, revision: 0aa3c2aad14cff039931923ab16b26b7481783b5)
build user: root@22cd11f671e9
build date: 20240228-11:51:20
go version: go1.21.7
platform: linux/amd64
tags: netgo

  • Prometheus version:

    N/A

  • Alertmanager command line:

    N/A
    
  • SNMP notifier command line:

    volumes:
    - /opt/tecnotree/containers/persistence/insights-ccbu-alertmanager-snmp/etc/snmp_notifier:/etc/snmp_notifier
    ports:
    - "9464:9464"
    command:
    - "--snmp.trap-description-template=/etc/snmp_notifier/description-template.tpl"
    - "--snmp.extra-field-template=4=/etc/snmp_notifier/instance-template.tpl"
    - "--snmp.extra-field-template=5=/etc/snmp_notifier/summary-template.tpl"
    - "--snmp.extra-field-template=6=/etc/snmp_notifier/status-template.tpl"
    - "--snmp.extra-field-template=7=/etc/snmp_notifier/job-template.tpl"
    - "--snmp.extra-field-template=8=/etc/snmp_notifier/comment-template.tpl"
    - "--snmp.version=V2c"
    - "--snmp.destination=127.0.0.1:162"
    - "--snmp.community=system"
    - "--snmp.timeout=5s"
    - "--alert.severity-label=severity"
    - "--alert.default-severity=critical"
    - "--alert.severities=critical,warning,info"

  • Prometheus alert file:

    N/A

  • Logs:

image

@fabienmagagnosc
Copy link
Author

and funnily, when I set the order to follow the failed order .. it follows the order.

  - "--snmp.trap-description-template=/etc/snmp_notifier/description-template.tpl"
  - "--snmp.extra-field-template=4=/etc/snmp_notifier/summary-template.tpl"
  - "--snmp.extra-field-template=5=/etc/snmp_notifier/status-template.tpl"
  - "--snmp.extra-field-template=6=/etc/snmp_notifier/job-template.tpl"
  - "--snmp.extra-field-template=7=/etc/snmp_notifier/comment-template.tpl"
  - "--snmp.extra-field-template=8=/etc/snmp_notifier/instance-template.tpl"

image

I suspect hat for performance, the notfied spawn all the calculation in parallel, and then merge them.
But the order is not respected, but "added" one after another one causing the ordering failure.

@fabienmagagnosc
Copy link
Author

but it seems anyway, that the execution is "too random" and cause a lot of problem as this is not stabel for any NMS to process.

in my case, I managed to get it parsed properly, one every 5 traps

@fabienmagagnosc
Copy link
Author

it seems that the addition of the fields inside the traps is not "order incrementally"

for subOid, template := range trapSender.configuration.ExtraFieldTemplates {

@fabienmagagnosc
Copy link
Author

those extra fields are important, as they allow to carry way more information, in my case :

  • summary of the incident (from the Alarm Annotations Summary)
  • a status OK/FAULT to start/stop the alarm
  • the job to identify the type of alarms generated and linked directly to the Prometheus group
  • an optional comment to add resolution/command line
  • the instance to be sure it's identified inside the NMS automatically and change the instance/server color according to the criticality

@maxwo
Copy link
Owner

maxwo commented Jan 26, 2025

it seems that the addition of the fields inside the traps is not "order incrementally"

for subOid, template := range trapSender.configuration.ExtraFieldTemplates {

True. I will ensure it is sorted by the OID.

@maxwo maxwo added bug Something isn't working good first issue Good for newcomers labels Jan 26, 2025
@fabienmagagnosc
Copy link
Author

fabienmagagnosc commented Jan 29, 2025

i did an internal version for testing. sorry if I didn't reverted back and helped

in the trap_sender.go.
I imported :

"sort"

and changed the way the OID are added to the trap.

_// Extract the keys from the map
var subOids []string
for subOid := range trapSender.configuration.ExtraFieldTemplates {
	subOids = append(subOids, subOid)
}

// Sort the keys
sort.Strings(subOids) 

// Iterate over the sorted keys
for _, subOid := range subOids {
	template := trapSender.configuration.ExtraFieldTemplates[subOid]_

attached my result

trap_sender.go.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants