Giter Site home page Giter Site logo

maxwo / snmp_notifier Goto Github PK

View Code? Open in Web Editor NEW
47.0 3.0 28.0 1.9 MB

A webhook to relay Prometheus alerts as SNMP traps, because sometimes, you have to deal with legacy

License: Apache License 2.0

Dockerfile 0.79% Makefile 2.28% Go 96.07% Shell 0.30% Smarty 0.55%
prometheus trap notification alert alerting alertmanager webhook golang nagios centreon

snmp_notifier's Introduction

SNMP Notifier

CircleCI Go Report Card

snmp_notifier receives alerts from the Prometheus' Alertmanager and routes them as SNMP traps.

Overview

The SNMP notifier receives alerts and sends them as SNMP traps to any given SNMP poller.

It has been created to handle older monitoring and alerting systems such as Nagios or Centreon.

Prometheus' Alertmanager sends the alerts to the SNMP notifier on its HTTP API. The SNMP notifier then looks for OID in the given alerts' labels. Each trap is sent with a unique ID, which allows, if the alert is updated or once it is resolved, to send additional traps with updated status and data.

Install

There are various ways to install the SNMP notifier:

Helm Chart

The SNMP notifier chart is available via the Prometheus Community Kubernetes Helm Charts:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install snmp-notifier prometheus-community/alertmanager-snmp-notifier --set 'snmpNotifier.snmpDestinations={my-snmp-server:162}'

Refer to the chart values to see the available options.

Docker Images

Docker images are available on the Docker Hub.

Precompiled binaries

Precompiled binaries are available in the release section of this repository.

Compiling the binary

Check out the source code and build it manually:

git clone https://github.com/maxwo/snmp_notifier.git
cd snmp_notifier
make build
./snmp_notifier

Running and configuration

Prometheus' alerts configuration

OID may be added to the alert labels to identify the kind of trap to be sent:


A default OID is specified in the SNMP notifier if none is found in the alert. This can be useful if you want all the alerts to share the same OID.


groups:
  - name: service
    rules:
      - alert: ServiceIsDown
        expr: up == 0
        for: 5m
        labels:
          severity: "critical"
          type: "service"
          oid: "1.3.6.1.4.1.123.0.10.1.1.1.5.1"
          environment: "production"
        annotations:
          description: "Service {{ $labels.job }} on {{ $labels.instance }} is down"
          summary: "A service is down."

Alertmanager configuration

The Alertmanager should be configured with the SNMP notifier as alert receiver:

receivers:
  - name: "snmp_notifier"
    webhook_configs:
      - send_resolved: true
        url: http://snmp.notifier.service:9464/alerts

Note that the send_resolved option allows the notifier to update the trap status to normal.

SNMP notifier configuration

Launch the snmp_notifier executable with the help flag to see the available options.

$ ./snmp_notifier --help
usage: snmp_notifier [<flags>]

A tool to relay Prometheus alerts as SNMP traps


Flags:
  -h, --[no-]help                Show context-sensitive help (also try --help-long and --help-man).
      --web.listen-address=:9464 ...
                                 Addresses on which to expose metrics and web interface. Repeatable for multiple addresses.
      --web.config.file=""       [EXPERIMENTAL] Path to configuration file that can enable TLS or authentication. See:
                                 https://github.com/prometheus/exporter-toolkit/blob/master/docs/web-configuration.md
      --alert.severity-label="severity"
                                 Label where to find the alert severity.
      --alert.severities="critical,warning,info"
                                 The ordered list of alert severities, from more priority to less priority.
      --alert.default-severity="critical"
                                 The alert severity if none is provided via labels.
      --snmp.version=V2c         SNMP version. V2c and V3 are currently supported.
      --snmp.sub-object-default-oid="1.3.6.1.4.1.123.456"
                                 Base OID to use for the sub-objects of each trap. Defaults to the trap-default-oid
      --snmp.destination=127.0.0.1:162
                                 SNMP trap server destination.
      --snmp.retries=1           SNMP number of retries
      --snmp.trap-oid-label="oid"
                                 Label where to find the trap OID.
      --snmp.trap-default-oid="1.3.6.1.4.1.98789"
                                 Trap OID to send if none is found in the alert labels.
      --snmp.trap-description-template=description-template.tpl
                                 SNMP description template.
      --snmp.extra-field-template=4=extra-field-template.tpl ...
                                 SNMP extra field templates, eg. --snmp.extra-field-templates=4=new-field.template.tpl to add a 4th
                                 field to the trap, with the given template file. You may add several fields using that flag several
                                 times.
      --snmp.timeout=5s          SNMP timeout duration
      --snmp.community="public"  SNMP community (V2c only). Passing secrets to the command line is not recommended, consider using the
                                 SNMP_NOTIFIER_COMMUNITY environment variable instead. ($SNMP_NOTIFIER_COMMUNITY)
      --[no-]snmp.authentication-enabled
                                 Enable SNMP authentication (V3 only).
      --snmp.authentication-protocol=MD5
                                 Protocol for password encryption (V3 only). MD5 and SHA are currently supported.
      --snmp.authentication-username=USERNAME
                                 SNMP authentication username (V3 only). Passing secrets to the command line is not
                                 recommended, consider using the SNMP_NOTIFIER_AUTH_USERNAME environment variable instead.
                                 ($SNMP_NOTIFIER_AUTH_USERNAME)
      --snmp.authentication-password=PASSWORD
                                 SNMP authentication password (V3 only). Passing secrets to the command line is not
                                 recommended, consider using the SNMP_NOTIFIER_AUTH_PASSWORD environment variable instead.
                                 ($SNMP_NOTIFIER_AUTH_PASSWORD)
      --[no-]snmp.private-enabled
                                 Enable SNMP encryption (V3 only).
      --snmp.private-protocol=DES
                                 Protocol for SNMP data transmission (V3 only). DES and AES are currently supported.
      --snmp.private-password=SECRET
                                 SNMP private password (V3 only). Passing secrets to the command line is not recommended, consider using
                                 the SNMP_NOTIFIER_PRIV_PASSWORD environment variable instead. ($SNMP_NOTIFIER_PRIV_PASSWORD)
      --snmp.security-engine-id=SECURITY_ENGINE_ID
                                 SNMP security engine ID (V3 only).
      --snmp.context-engine-id=CONTEXT_ENGINE_ID
                                 SNMP context engine ID (V3 only).
      --snmp.context-name=CONTEXT_ENGINE_NAME
                                 SNMP context name (V3 only).
      --log.level=info           Only log messages with the given severity or above. One of: [debug, info, warn, error]
      --log.format=logfmt        Output format of log messages. One of: [logfmt, json]
      --[no-]version             Show application version.

Also, it is recommended to use the following environment variables to set the SNMP secrets:

Environment variable Configuration Default
SNMP_NOTIFIER_COMMUNITY SNMP community for SNMP v2c public
SNMP_NOTIFIER_AUTH_USERNAME SNMP authentication username for SNMP v3
SNMP_NOTIFIER_AUTH_PASSWORD SNMP authentication password for SNMP v3
SNMP_NOTIFIER_PRIV_PASSWORD SNMP private (or server) password for SNMP v3

Any Go template directive may be used in the snmp.trap-description-template file.

Examples

Simple Usage

Here are 2 example traps received with the default configuration. It includes 2 firing alerts sharing the same OID, and 1 resolved alert.

Traps include 3 fields:

  • a trap unique ID;
  • the alert/trap status;
  • a description of the alerts.
$ snmptrapd -m ALL -m +SNMP-NOTIFIER-MIB -f -Of -Lo -c scripts/snmptrapd.conf
 Agent Address: 0.0.0.0
 Agent Hostname: localhost
 Date: 1 - 0 - 0 - 1 - 1 - 1970
 Enterprise OID: .
 Trap Type: Cold Start
 Trap Sub-Type: 0
 Community/Infosec Context: TRAP2, SNMP v2c, community public
 Uptime: 0
 Description: Cold Start
 PDU Attribute/Value Pair Array:
.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.sysUpTimeInstance = Timeticks: (853395100) 98 days, 18:32:31.00
.iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap.snmpTrapOID.0 = OID: .iso.org.dod.internet.private.enterprises.snmpNotifier.snmpNotifierDefaultTrap
.iso.org.dod.internet.private.enterprises.snmpNotifier.snmpNotifierAlertsObjects.snmpNotifierAlertId = STRING: "1.3.6.1.4.1.98789[environment=production,label=test]"
.iso.org.dod.internet.private.enterprises.snmpNotifier.snmpNotifierAlertsObjects.snmpNotifierAlertSeverity = STRING: "critical"
.iso.org.dod.internet.private.enterprises.snmpNotifier.snmpNotifierAlertsObjects.snmpNotifierAlertDescription = STRING: "2/3 alerts are firing:

Status: critical
- Alert: TestAlert
  Summary: this is the summary
  Description: this is the description on job1

Status: warning
- Alert: TestAlert
  Summary: this is the random summary
  Description: this is the description of alert 1"
 --------------

With extra fields

You may add additional fields thanks to the --snmp.extra-field-template arguments.

For instance, the template {{ len .Alerts }} alerts are firing. given in the --snmp.extra-field-template=4=alert-count.tpl argument will produce:

$ snmptrapd -m ALL -m +SNMP-NOTIFIER-MIB -f -Of -Lo -c scripts/snmptrapd.conf
 Agent Address: 0.0.0.0
 Agent Hostname: localhost
 Date: 1 - 0 - 0 - 1 - 1 - 1970
 Enterprise OID: .
 Trap Type: Cold Start
 Trap Sub-Type: 0
 Community/Infosec Context: TRAP2, SNMP v2c, community public
 Uptime: 0
 Description: Cold Start
 PDU Attribute/Value Pair Array:
.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.sysUpTimeInstance = Timeticks: (2665700) 7:24:17.00
.iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap.snmpTrapOID.0 = OID: .iso.org.dod.internet.private.enterprises.snmpNotifier.snmpNotifierDefaultTrap
.iso.org.dod.internet.private.enterprises.snmpNotifier.snmpNotifierAlertsObjects.snmpNotifierAlertId = STRING: "1.3.6.1.4.1.98789[environment=production,label=test]"
.iso.org.dod.internet.private.enterprises.snmpNotifier.snmpNotifierAlertsObjects.snmpNotifierAlertSeverity = STRING: "critical"
.iso.org.dod.internet.private.enterprises.snmpNotifier.snmpNotifierAlertsObjects.snmpNotifierAlertDescription = STRING: "2/3 alerts are firing:

Status: critical
- Alert: TestAlert
  Summary: this is the summary
  Description: this is the description on job1

Status: warning
- Alert: TestAlert
  Summary: this is the random summary
  Description: this is the description of alert 1"
.iso.org.dod.internet.private.enterprises.snmpNotifier.snmpNotifierAlertsObjects.4 = STRING: "2 alerts are firing."
--------------

Contributing

Issues, feedback, PR welcome.

snmp_notifier's People

Contributors

dependabot-preview[bot] avatar dependabot[bot] avatar maxwo avatar p-se avatar petertakacs avatar shayyxi avatar timfroidcoeur avatar vigno88 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

snmp_notifier's Issues

SNMP traps retry mechanism

Hi
Can someone explain how snmp retries mechanism works on snmp-notifier? If it uses udp how does it know if it should retry to resend the trap or does it somehow works over tcp?
@maxwo could you please provide some further details on this?

--snmp.retries=1

Thanks for any information

Dockerfile fix

Dockerfile references "snmp_notifier" to copy to bin directory, but this is not the name of the file it is "snmp_notifier.go"

level=error msg="400 Bad Request

Alertmanager configuration file:

apiVersion: v1
kind: ConfigMap
metadata:
name: alertmanager-config
namespace: monitor
data:
alertmanager.yml: |-
global:
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 30s
repeat_interval: 30s
receiver: 'snmp_notifier'
receivers:
- name: 'snmp_notifier'
webhook_configs:
- send_resolved: true
url: http://nodeIp:9464/alerts
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
prometheus configuration file:
apiVersion: v1
kind: ConfigMap
metadata:
name: prometheus-config
namespace: monitor
data:
prometheus.yml: |
global:
scrape_interval: 20s # 抓取周期
evaluation_interval: 20s # 估算规则的周期
rule_files:
- /etc/config/rules/*.rules
scrape_configs:
- job_name: "otel-collector"
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_pod_container_port_number]
action: keep
regex: monitor;8889
- source_labels: [__meta_kubernetes_pod_node_name]
action: replace
target_label: kubernetes_node_name
- job_name: prometheus
static_configs:
- targets:
- localhost:9090
alerting:
alertmanagers:
- static_configs:
- targets: ["alertmanager.monitor:9093"]

start up snmp_notifier

--download
https://github.com/maxwo/snmp_notifier/releases/download/v1.2.1/snmp_notifier-1.2.1.linux-amd64.tar.gz
--start up snmp_notifier

tar -zxvf snmp_notifier-1.2.1.linux-amd64.tar.gz -C /opt

mv /opt/snmp_notifier-1.2.1.linux-amd64 /opt/snmp_notifier

cd /opt/snmp_notifier

nohup /opt/snmp_notifier/snmp_notifier > /opt/snmp_notifier/snmp_notifier.log 2>&1 &

netstat -nap |grep -i 9464

tcp6 0 0 :::9464 :::* LISTEN 14502/snmp_notifier

logs

but. alert manager can not send alert to snmp_notifier, alert manager logs:
ts=2022-06-08T07:12:12.798Z caller=dispatch.go:354 level=error component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="snmp_notifier/webhook[0]: notify retry canceled due to unrecoverable error after 1 attempts: unexpected status code 400: http://10.99.212.66:9464/alerts"
ts=2022-06-08T07:12:42.801Z caller=dispatch.go:354 level=error component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="snmp_notifier/webhook[0]: notify retry canceled due to unrecoverable error after 1 attempts: unexpected status code 400: http://10.99.212.66:9464/alerts"
ts=2022-06-08T07:13:12.803Z caller=dispatch.go:354 level=error component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="snmp_notifier/webhook[0]: notify retry canceled due to unrecoverable error after 1 attempts: unexpected status code 400: http://10.99.212.66:9464/alerts"
ts=2022-06-08T07:13:42.801Z caller=dispatch.go:354 level=error component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="snmp_notifier/webhook[0]: notify retry canceled due to unrecoverable error after 1 attempts: unexpected status code 400: http://10.99.212.66:9464/alerts"
ts=2022-06-08T07:14:12.803Z caller=dispatch.go:354 level=error component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="snmp_notifier/webhook[0]: notify retry canceled due to unrecoverable error after 1 attempts: unexpected status code 400: http://10.99.212.66:9464/alerts"
ts=2022-06-08T07:14:42.803Z caller=dispatch.go:354 level=error component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="snmp_notifier/webhook[0]: notify retry canceled due to unrecoverable error after 1 attempts: unexpected status code 400: http://10.99.212.66:9464/alerts"

while snmp_notifier.logs as follows:
time="2022-06-08T15:14:12+08:00" level=error msg="400 Bad Request: err=incorrect severity: emergency data=&{Receiver:snmp_notifier Status:firing Alerts:[{Status:firing Labels:map[alertname:NodeMemoryUsage-emergency app_kubernetes_io_component:exporter app_kubernetes_io_name:node-exporter app_kubernetes_io_part_of:kube-prometheus app_kubernetes_io_version:1.3.1 controller_revision_hash:7f4f979f8 http_scheme:http instance:177.177.48.249:8889 job:otel-collector kubernetes_node_name:node66 kubernetes_pod_name:node-exporter-5tg42 net_host_name:177.177.48.210 net_host_port:9100 oid:1.3.6.1.4.1.98789.0.1 pod_template_generation:1 service:node service_instance_id:177.177.48.210:9100 service_name:nodeExporter severity:emergency type:service] Annotations:map[summary:177.177.48.249:8889内存使用大于85% (当前值: 31.021082537787933)] StartsAt:2022-06-08 06:38:32.77 +0000 UTC EndsAt:0001-01-01 00:00:00 +0000 UTC GeneratorURL:http://prometheus-6f7f6bbff4-8sqkv:9090/graph?g0.expr=100+-+%28node_memory_MemFree_bytes%7Bk8scluster%21~%22.%2B%22%7D+%2B+node_memory_Cached_bytes+%2B+node_memory_Buffers_bytes%29+%2F+node_memory_MemTotal_bytes+%2A+100+%3E+15&g0.tab=1 Fingerprint:a417884b87061093}] GroupLabels:map[alertname:NodeMemoryUsage-emergency] CommonLabels:map[alertname:NodeMemoryUsage-emergency app_kubernetes_io_component:exporter app_kubernetes_io_name:node-exporter app_kubernetes_io_part_of:kube-prometheus app_kubernetes_io_version:1.3.1 controller_revision_hash:7f4f979f8 http_scheme:http instance:177.177.48.249:8889 job:otel-collector kubernetes_node_name:node66 kubernetes_pod_name:node-exporter-5tg42 net_host_name:177.177.48.210 net_host_port:9100 oid:1.3.6.1.4.1.98789.0.1 pod_template_generation:1 service:node service_instance_id:177.177.48.210:9100 service_name:nodeExporter severity:emergency type:service] CommonAnnotations:map[summary:177.177.48.249:8889内存使用大于85% (当前值: 31.021082537787933)] ExternalURL:http://alertmanager-69494b9c76-jwgrq:9093}" source="http_server.go:129"
177.177.48.227 - - [08/Jun/2022:15:14:12 +0800] "POST /alerts HTTP/1.1" 400 69
177.177.48.227 - - [08/Jun/2022:15:14:12 +0800] "POST /alerts HTTP/1.1" 200 0
177.177.48.227 - - [08/Jun/2022:15:14:12 +0800] "POST /alerts HTTP/1.1" 200 0
time="2022-06-08T15:14:42+08:00" level=error msg="400 Bad Request: err=incorrect severity: emergency data=&{Receiver:snmp_notifier Status:firing Alerts:[{Status:firing Labels:map[alertname:NodeMemoryUsage-emergency app_kubernetes_io_component:exporter app_kubernetes_io_name:node-exporter app_kubernetes_io_part_of:kube-prometheus app_kubernetes_io_version:1.3.1 controller_revision_hash:7f4f979f8 http_scheme:http instance:177.177.48.249:8889 job:otel-collector kubernetes_node_name:node66 kubernetes_pod_name:node-exporter-5tg42 net_host_name:177.177.48.210 net_host_port:9100 oid:1.3.6.1.4.1.98789.0.1 pod_template_generation:1 service:node service_instance_id:177.177.48.210:9100 service_name:nodeExporter severity:emergency type:service] Annotations:map[summary:177.177.48.249:8889内存使用大于85% (当前值: 31.143249075185608)] StartsAt:2022-06-08 06:38:32.77 +0000 UTC EndsAt:0001-01-01 00:00:00 +0000 UTC GeneratorURL:http://prometheus-6f7f6bbff4-8sqkv:9090/graph?g0.expr=100+-+%28node_memory_MemFree_bytes%7Bk8scluster%21~%22.%2B%22%7D+%2B+node_memory_Cached_bytes+%2B+node_memory_Buffers_bytes%29+%2F+node_memory_MemTotal_bytes+%2A+100+%3E+15&g0.tab=1 Fingerprint:a417884b87061093}] GroupLabels:map[alertname:NodeMemoryUsage-emergency] CommonLabels:map[alertname:NodeMemoryUsage-emergency app_kubernetes_io_component:exporter app_kubernetes_io_name:node-exporter app_kubernetes_io_part_of:kube-prometheus app_kubernetes_io_version:1.3.1 controller_revision_hash:7f4f979f8 http_scheme:http instance:177.177.48.249:8889 job:otel-collector kubernetes_node_name:node66 kubernetes_pod_name:node-exporter-5tg42 net_host_name:177.177.48.210 net_host_port:9100 oid:1.3.6.1.4.1.98789.0.1 pod_template_generation:1 service:node service_instance_id:177.177.48.210:9100 service_name:nodeExporter severity:emergency type:service] CommonAnnotations:map[summary:177.177.48.249:8889内存使用大于85% (当前值: 31.143249075185608)] ExternalURL:http://alertmanager-69494b9c76-jwgrq:9093}" source="http_server.go:129"
177.177.48.227 - - [08/Jun/2022:15:14:42 +0800] "POST /alerts HTTP/1.1" 400 69

what's wrong with my configuration? how can I solve this problem?
thanks very much

Alarm description when it is cleared

I am using the snmp notifier V3 in a Kubernetes environment with many namespaces. Due this, I would like to see the description, summary in order to see which namespace belongs an alarm when it is cleared, in the same way when the alarm is generated. I did changes in description.tpl file but didn't work.

When an alarm is cleared, I would like to see after Status: OK, the description of the alarm in the same way it comes when the alarms is generated (Alert, Summary and Description)

With my changes, I see:
OID2: "clear"
OID3: MISSING

Summarizing, instead of MISSING, I want to see:
Status: OK
Alert: ----
Description: ----
Summary: ----

Thank you.

Forwarding the SNMP traps from snmp_notifier running on kubernetes to alerting system

What did you do?
ran the snmp-notifier as a deployment inside a kubernetes cluster. the YAML file is as below:
`---
apiVersion: apps/v1
kind: Deployment
metadata:
name: snmp-notifier-deployment
namespace: pf9-monitoring
labels:
component: snmp-notifier
spec:
replicas: 1
selector:
matchLabels:
app: snmp-notifier
template:
metadata:
labels:
app: snmp-notifier
spec:
containers:
- image: maxwo/snmp-notifier:v1.2.1
name: snmp-notifier
ports:
- containerPort: 9464
name: web-endpoint
protocol: TCP
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 500m
memory: 256Mi

apiVersion: v1
kind: Service
metadata:
name: snmp-notifier-service
namespace: pf9-monitoring
spec:
type: ClusterIP
ports:
- name: web-endpoint
port: 9464
targetPort: 9464
protocol: TCP
selector:
app: snmp-notifier
...Webhook: My webhook config:global:
resolve_timeout: 5m
route:
group_by: ['...']
group_wait: 3s
group_interval: 1m
repeat_interval: 15m
receiver: 'snmp_notifier'
receivers:

  • name: 'snmp_notifier'
    webhook_configs:
    • send_resolved: true
      url: http://10.140.15.246:9464/alerts`
      10.140.15.246 is IP of snmp_notifier service.
      I can see the alerts are posted from alert-manager to snmp_notifier in the snmp_notifier pod's log
      10.139.200.2 - - [21/Jan/2022:16:30:09 +0000] "POST /alerts HTTP/1.1" 200 0

I would like to know to things
[1] Is this configuration correct ?
[2] Additional configuration procedure to forward these alerts from snmp_notifier pod to the external legacy alerting system say netcool. This I could not find anywhere. Is there a secret that one need to create ? It will be helpful if I can get some help on how to set this up with an example. Thank you!

What did you expect to see?
procedure to forward the SNMP traps received in the snmp_notifier pod to the alerting system.

What did you see instead? Under which circumstances?

Environment
Kubernetes 1.21

  • System information:

Linux 3.10.0-957.1.3.el7.x86_64 x86_64

  • SNMP notifier version:

snmp_notifier, version 1.2.1 (branch: HEAD, revision: 73773b7)
build user: root@4c095c7fad1b
build date: 20210820-08:20:04
go version: go1.16
platform: linux/amd64

  • Alertmanager version:

alertmanager, version 0.21.0 (branch: HEAD, revision: 4c6c03ebfe21009c546e4d1e9b92c371d67c021d)
build user: root@dee35927357f
build date: 20200617-08:54:02
go version: go1.14.4

  • Prometheus version:

prometheus, version 2.32.1 (branch: HEAD, revision: 41f1a8125e664985dd30674e5bdf6b683eff5d32)
build user: root@54b6dbd48b97
build date: 20211217-22:08:06
go version: go1.17.5
platform: linux/amd64

  • Alertmanager command line:

    1 nobody    1:54 /bin/alertmanager --config.file=/etc/alertmanager/config/alertmanager.yaml --storage.path=/alertmanager --data.retention=120h --cluster.listen-address= --web.listen-ad

* SNMP notifier command line:

/bin/snmp_notifier --snmp.trap-description-template=/etc/snmp_notifier/description-template.tpl




Alerts not receiving in snmp receiver end

What did you do?
I am using Prometheus, Grafana, Alertmanager stack to monitor my EDB postgres installed in bare metal k8s cluster.

I am receiving alerts in alert manager with below configuration.

  resolve_timeout: 5m
  http_config:
    follow_redirects: true
  smtp_hello: localhost
  smtp_require_tls: true
  pagerduty_url: https://events.pagerduty.com/v2/enqueue
  opsgenie_api_url: https://api.opsgenie.com/
  wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/
  victorops_api_url: https://alert.victorops.com/integrations/generic/20131114/alert/
route:
  receiver: snmp_notifier
  group_by:
  - job
  continue: false
  routes:
  - receiver: "null"
    match:
      alertname: Watchdog
    continue: false
  - receiver: snmp_notifier
    continue: false
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
receivers:
- name: "null"
- name: snmp_notifier
  webhook_configs:
  - send_resolved: true
    http_config:
      follow_redirects: true
    url: http://snmpnotifier.cnp-monitoring.svc.cluster.local:9464/alerts
    max_alerts: 0
templates:
- /etc/alertmanager/config/*.tmpl

In alertmanager URL

image

Now I want to reciver those alerts in a snmp trap server.
So I have installed snmp_notifier with latest image.
SNMP notifier command line:

- /bin/snmp_notifier
        - --snmp.trap-description-template=/etc/snmp_notifier/description-template.tpl
        - --log.level=debug
        - --alert.severities="emergency,high,medium,low,critical,warning,info"
        - --alert.default-severity="high"
        - --snmp.destination=10.0.113.233:162
        - --snmp.version=V3
        - --snmp.authentication-enabled
        - --snmp.authentication-protocol=SHA
        - --snmp.authentication-username=snmp_user_v3
        - --snmp.authentication-password=auth_password_v3
        - --snmp.private-enabled
        - --snmp.private-protocol=AES
        - --snmp.private-password=encrypt_password_v3
        - --snmp.context-engine-id=0x8000000001020304

I have added some custom severities as per my PrometheusRule setup

In --snmp.destination I added the IP of the snmp-server service.
Which I installed in same namespace using your given example https://github.com/maxwo/snmp_notifier/blob/main/scripts/kubernetes/snmp-server.yaml without any change in given yaml.

In snmp_notifier pod log getting 200 in response, though requesting header not showing

ts=2023-02-21T11:15:14.994Z caller=http_server.go:78 level=debug msg="Handling /alerts webhook request"
ts=2023-02-21T11:15:14.994Z caller=http_server.go:78 level=debug msg="Handling /alerts webhook request"
ts=2023-02-21T11:15:14.995Z caller=http_server.go:78 level=debug msg="Handling /alerts webhook request"
ts=2023-02-21T11:15:15.006Z caller=http_server.go:78 level=debug msg="Handling /alerts webhook request"
192.168.216.59 - - [21/Feb/2023:11:15:14 +0000] "POST /alerts HTTP/1.1" 200 0
192.168.216.59 - - [21/Feb/2023:11:15:14 +0000] "POST /alerts HTTP/1.1" 200 0
192.168.216.59 - - [21/Feb/2023:11:15:14 +0000] "POST /alerts HTTP/1.1" 200 0
192.168.216.59 - - [21/Feb/2023:11:15:15 +0000] "POST /alerts HTTP/1.1" 200 0

But in snmp-server nothing is coming

kubectl logs of snmp-server

NET-SNMP version 5.9.3

What did you expect to see?
I am expecting the trap details to be shown in snmp-server logs, also in snmp notifier logs.

Environment
Bare metal K8s cluster, kubernetes version 1.25

  • System information:

     `Linux 4.18.0-372.9.1.el8.x86_64 x86_64`
    
  • SNMP notifier version:

    1.4.0

  • Alertmanager version:

    0.23.0

  • Alertmanager command line:

/bin/alertmanager --config.file=/etc/alertmanager/config/alertmanager.yaml --storage.path=/alertmanager --data.retention=120h --cluster.listen-address= --web.listen-address=:9093 --web.external-url=http://cnp-sandbox-kube-prometheu-alertmanager.cnp-monitoring:9093 --web.route-prefix=/ --cluster.peer=alertmanager-cnp-sandbox-kube-prometheu-alertmanager-0.alertmanager-operated:9094 --cluster.reconnect-timeout=5m

Dependabot can't resolve your Go dependency files

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

github.com/maxwo/snmp_notifier/alertparser: cannot find module providing package github.com/maxwo/snmp_notifier/alertparser
github.com/maxwo/snmp_notifier imports
	github.com/maxwo/snmp_notifier/configuration: cannot find module providing package github.com/maxwo/snmp_notifier/configuration
github.com/maxwo/snmp_notifier imports
	github.com/maxwo/snmp_notifier/httpserver: cannot find module providing package github.com/maxwo/snmp_notifier/httpserver
github.com/maxwo/snmp_notifier imports
	github.com/maxwo/snmp_notifier/telemetry: cannot find module providing package github.com/maxwo/snmp_notifier/telemetry
github.com/maxwo/snmp_notifier imports
	github.com/maxwo/snmp_notifier/trapsender: cannot find module providing package github.com/maxwo/snmp_notifier/trapsender

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

SNMP Notifier "Error":true,"Status":422

What did you do?

SNMP Notifier doesnt get alert from alertmanager. I cannto see anything when I click on SNMP alerts endpoint link in the SNMP Notifier URL.
I can just see this :
{"Error":true,"Status":422,"Message":"EOF"}

What did you expect to see?

What did you see instead? Under which circumstances?

Environment

  • System information:

    insert output of uname -srm here

  • SNMP notifier version:

    insert output of snmp_notifier --version here

  • Alertmanager version:

    insert output of alertmanager --version here

  • Prometheus version:

    insert output of prometheus -version here (if relevant to the issue)

  • Alertmanager command line:

route:
  receiver: "default"
  routes:
   - match:
      severity: critical
     receiver: snmp_notifier
   - match:
      severity: warning
     receiver: email
     group_wait: 30s
     group_interval: 15m
     repeat_interval: 15m
receivers:
  - name: default
    email_configs:
     - to: '[email protected]'
       from: '[email protected]'
       smarthost: 'localhost:25'
  - name: snmp_notifier
    webhook_configs:
    - send_resolved: true
      url: http://berlin01:9464/alerts
  - name: email
    email_configs:
     - to: '[email protected]'
       from: '[email protected]'
       smarthost: 'localhost:25'
  • SNMP notifier command line:
./snmp_notifier 

  • Prometheus alert file:

    rules:

    Alert for any instance that is unreachable for >5 minutes.

    • alert: PostgreSQLInstanceUpDown
      expr: pg_up == 0 or up{instance=~".*"} == 0
      for: 1m
      labels:
      severity: critical
      oid: "1.3.6.1.4.1.123.0.10.1.1.1.5.1"
      type: "service"
      environment: "production"
      annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."
  • Logs:

insert logs relevant to the issue here

How to change Hex-String to String on varbind 3

What did you do?
I have two k8s clusters apparently configured exactly the same, however, one sends traps correctly (text string in varbind 3) while the other sends Hex-String in varbind 3.

Where in the SNMP Notifier configuration can I control the varbind 3 string type?

What did you expect to see?
text string in varbind 3
What did you see instead? Under which circumstances?
hex-string. for example. .3 = Hex-STRING:

Environment

  • System information:

    insert output of uname -srm here
    Linux 4.14.35-1902.8.4.el7uek.x86_64 x86_64

  • SNMP notifier version:
    snmp-notifier:v0.3.0
    insert output of snmp_notifier --version here

  • Alertmanager version:

    insert output of alertmanager --version here
    alertmanager:v0.18.0

  • Prometheus version:

    insert output of prometheus -version here (if relevant to the issue)

  • Alertmanager command line:

insert command line here
  • SNMP notifier command line:
insert command line here
  • Prometheus alert file:
insert configuration here (if relevant to the issue)

{{- if (len .Alerts) gt 0 -}}
{{- range $severity, $alerts := (groupAlertsByLabel .Alerts "severity") -}}
Status: {{ $severity }}
{{- range $index, $alert := $alerts }}

  • Alert: {{ $alert.Labels.alertname }}
    Summary: {{ $alert.Annotations.summary }}
    Description: {{ $alert.Annotations.description }}
    {{ end }}
    {{ end }}
    {{ else -}}
    Status: OK
    {{- end -}}
  • Logs:
insert logs relevant to the issue here

Cannot see the snmp-server trap output

What did you do?
Send alert using curl to snmp-notifier and this one sending trap to snmp-server, both running in EKS. SNMP-Notifier installed using helm and snmp-server deploying the manifest available under scripts/kubernetes.

What did you expect to see?
I was expecting to see the trap output in snmp-server stdout.

What did you see instead? Under which circumstances?
The snmp-notifier receives the alert and with 200OK but i am not able to see anything on the snmp-server stdout.

Environment

  • System information:

    EKS

  • SNMP notifier version:

    1.5.0

  • Alertmanager version:

    N/A

  • Prometheus version:

    N/A

  • Alertmanager simulated post:

curl -i -H "Host: alertmanager-snmp-notifier:9464" -H "User-Agent: Alertmanager/0.23.0" -H "Content-Type: application/json" --request POST --data @alert1_warning_resolved.json http://alertmanager-snmp-notifier.network-observability.svc.cluster.local:9464/alerts
HTTP/1.1 200 OK
date: Mon, 05 Feb 2024 13:25:44 GMT
content-length: 0
x-envoy-upstream-service-time: 1
server: envoy

alert1_warning_resolved.json:

{
  "receiver": "snmp-notifier",
  "status": "firing",
  "groupLabels": {
    "environment": "staging",
    "label": "test"
  },
  "alerts": [
    {
      "status": "firing",
      "labels": {
        "severity": "warning",
        "alertname": "TestAlert1"
      },
      "annotations": {
        "message": "this is the message of alert 1"
      }
    }
  ]
}
  • SNMP-Notifer logs:
k logs -f alertmanager-snmp-notifier-5f5446bbdc-cmb9z
ts=2024-02-05T13:13:11.430Z caller=snmp_notifier.go:40 level=debug configuration="unsupported value type"
ts=2024-02-05T13:13:11.431Z caller=tls_config.go:274 level=info msg="Listening on" address=[::]:9464
ts=2024-02-05T13:13:11.431Z caller=tls_config.go:277 level=info msg="TLS is disabled." http2=false address=[::]:9464
ts=2024-02-05T13:17:41.035Z caller=http_server.go:79 level=debug msg="Handling /alerts webhook request"
  • snmp-server logs:
k logs -f snmp-server-546f65b5d6-bvgxg
NET-SNMP version 5.9.3

/var/lib/zabbix/snmptraps $ ps -ef
PID   USER     TIME  COMMAND
    1 zabbix    0:00 /usr/sbin/snmptrapd -n -C -c /etc/snmp/snmptrapd.conf -Lo -A
   24 zabbix    0:00 /bin/sh
   33 zabbix    0:00 ps -ef

SNMP V3 support

I want to generate SNMPv3 alerts using SNMP Notifier. I am unable to find documentation for the same. Please help me with it.

Can't find the MIB file

Hey,

I am trying to get the MIB file of the SNMP notifier with no luck,

where can I find this file?

How to configure the SNMP destination during runtime? Is there any REST API provided by SNMP Notifier?

What did you do?
I want to configure the snmp server destination during runtime of pod in K8s
What did you expect to see?
Is there any restapi provided ? or any other way to configure during runtime
What did you see instead? Under which circumstances?
I did not find any documentation to achieve this
Environment
K8s, started snmp_notifier through helm

  • System information:
    linux
    insert output of uname -srm here

  • SNMP notifier version:
    latest
    insert output of snmp_notifier --version here

  • Alertmanager version:
    latest
    insert output of alertmanager --version here

  • Prometheus version:
    latest
    insert output of prometheus -version here (if relevant to the issue)

  • Alertmanager command line:

insert command line here
  • SNMP notifier command line:
insert command line here
  • Prometheus alert file:
insert configuration here (if relevant to the issue)
  • Logs:
insert logs relevant to the issue here

422 Unprocessable Entity:

Hi
Install 1.1.1 and 1.2.1 on centos7.9 , all get error logs when input https://xxx.xxx.xxx.xxx/alerts

level=error msg="422 Unprocessable Entity: err=EOF data=&{Receiver: Status: Alerts:[] GroupLabels:map[] CommonLabels:map[] CommonAnnotations:map[] ExternalURL:}" source="http_server.go:129"

How to slove it

Issue when trying to use snmp.trap-description-template

When I use the provided example for the snmp.trap-description-template

--snmp.trap-description-template="\n{{- if (len .Alerts) gt 0 -}}\n{{- range $severity, $alerts := (groupAlertsByLabel .Alerts "severity") -}}\nStatus: {{ $severity }}\n{{- range $index, $alert := $alerts }}\n- Alert: {{ $alert.Labels.alertname }}\n Summary: {{ $alert.Annotations.summary }}\n Description: {{ $alert.Annotations.description }}\n{{ end }}\n{{ end }}\n{{ else -}}\nStatus: OK\n{{- end -}}"

I get the following error when trying to load the YAML

* : Invalid value: "The edited file failed validation": [yaml: line 37: did not find expected key, [invalid character 'a' looking for beginning of value, invalid character 'a' looking for beginning of value]]

I even tried loading the yaml in python and it seems to have an issue in column 180 which is around the s "severity") -}}\nStatus: {{ $severity area. Are you able to help me out with this please?

Dependabot can't parse your go.mod

Dependabot couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: github.com/onsi/[email protected] requires
	gopkg.in/[email protected] requires
	gopkg.in/[email protected]: invalid version: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /opt/go/gopath/pkg/mod/cache/vcs/9241c28341fcedca6a799ab7a465dd6924dc5d94044cbfabb75778817250adfc: exit status 128:
	fatal: The remote end hung up unexpectedly

View the update logs.

Try all SNMP destinations before failing

What did you do?

Currently, if a SNMP destination fails, subsequent destinations fail as well.

What did you expect to see?

It should try all SNMP destinations so that if one fails, some other may receive the alert.

What did you see instead? Under which circumstances?

Every time a destination fails.

Environment

All

Configure the docker image to set the SNMP destination via environment variable

What did you do?
We are trying to use this snmp_notifier docker image to send Prometheus Alert (In an Openshift cluster) to a Solarwind instance

What did you expect to see?
I would expect to have a environment variable to set the SNMP destination, I don't understand why it's not the case, so I wonder if this use case is managed.

What did you see instead? Under which circumstances?

I saw four env variables to setup the snmp_notifier run in the docker image :

SNMP_NOTIFIER_COMMUNITY
SNMP_NOTIFIER_AUTH_USERNAME
SNMP_NOTIFIER_AUTH_PASSWORD 
SNMP_NOTIFIER_PRIV_PASSWORD

I wonder if we could modify the file configuration.go in order to override the snmp.destination value as it's done for the four others

Environment
Openshift container Plateform 4.10

  • System information:

    Not relevant

  • SNMP notifier version:

    The one in the docker image, main branch

  • Alertmanager version:

sh-4.4$ alertmanager --version
alertmanager, version 0.23.0 (branch: rhaos-4.10-rhel-8, revision: 65e93ba8e0ee8d9a09df2d682e7d170560d05b86)
  build user:       root@4f9012b22b61
  build date:       20221006-15:26:42
  go version:       go1.17.12
  platform:         linux/amd64
  • Prometheus version:
sh-4.4$ prometheus --version
prometheus, version 2.32.1 (branch: rhaos-4.10-rhel-8, revision: 6e08107deec46c951a975014b175543eb5e44d4a)
  build user:       root@4f9012b22b61
  build date:       20221006-15:29:41
  go version:       go1.17.12
  platform:         linux/amd64
  • SNMP notifier command line:
The one in the Dockerfile
  • Prometheus alert file:
Default Openshift alert file
  • Logs:
No logs yet as we didn't run anythings, we are trying to integrate for now.

I don't know what is the good approch here, should I rebuild an image with the destination configurable ? is there any reason to not do it ?

I guess that the http server was design to be put at the same place than the SNMP Server at the beginning, and that the docker part came on top, but as it's a guess I would like to know if there is technical reason to wont do.

Kr,

Franck

How to get label when the alert is resolved ?

What did you do?
{{- if .Alerts -}}
{{- range $severity, $alerts := (groupAlertsByLabel .Alerts "severity") -}}
Status: {{ $severity }}
{{- range $index, $alert := $alerts }}

  • Alert: {{ $alert.Labels.alertname }}
    Category: {{ $alert.Labels.category }}
    Data environment: {{ $alert.Labels.source_environment }}
    Topic: {{ $alert.Labels.topic }}
    Index: {{ $alert.Labels.index }}
    Source: {{ $alert.Labels.source }}
    NODE: {{ $alert.Labels.node }}
    Source Environment: {{ $alert.Labels.env }}
    Severity: {{ $alert.Labels.severity }}
    MetricName: {{ $alert.Labels.metricname }}
    CI_ID: {{ $alert.Labels.ci }}
    SUMMARY: {{ $alert.Annotations.summary }}
    {{ end }}
    {{ end }}
    {{ else -}}
    Status: Ok
    {{- end -}}
    What did you expect to see?
    "SNMPv2-SMI::enterprises.4445.1.4978.3": "Status: resolved
  • Alert: logstash_monitoring_down
    Category: instances
    Source: prometheus
    NODE: server
    Source Environment: lab
    Severity: error
    MetricName: logstash_monitoring_down
    CI_ID: logstash_server
    SUMMARY: lab: Service of monitoring logstash-exporter is down on server on port 9651.",
    What did you see instead? Under which circumstances?
    "SNMPv2-SMI::enterprises.4445.1.4978.3": "Status: resolved
    Environment
    lab
  • System information:

    Linux 3.10.0-1062.4.3.el7.x86_64 x86_64

  • SNMP notifier version:

    snmp_notifier, version 1.2.1 (branch: HEAD, revision: 73773b7)
    build user: root@4c095c7fad1b
    build date: 20210820-08:20:04
    go version: go1.16
    platform: linux/amd64

  • Alertmanager version:

    alertmanager, version 0.20.0 (branch: HEAD, revision: f74be0400a6243d10bb53812d6fa408ad71ff32d)
    build user: root@00c3106655f8
    build date: 20191211-14:13:14
    go version: go1.13.5

  • Prometheus version:

    prometheus, version 2.14.0 (branch: HEAD, revision: edeb7a44cbf745f1d8be4ea6f215e79e651bfe19)
    build user: root@df2327081015
    build date: 20191111-14:27:12
    go version: go1.13.4

Is there a way to have more than 5 distinct fields with the template?

No matter how I modify the template I can only change the value of the .5 filed of the trap.
Is there a way to add .6, .7 etc. values with additional fileds?
Ideally we would need sometiong like that

6:{{ $alert.Labels.instance }}
7:{{ $alert.Annotations.summary }}
8:{{ $alert.Annotations.custom1 }}

How to get instance IP when the status is OK

I get the instance ip with parameter --snmp.extra-field-template=4=/opt/snmp_notifier/extra-field-template.tpl ,and it effective only when the alert is active, now i want the ip with alert resolve

my extra-field-template.tpl file like:
{{- if .Alerts -}}
{{- range $severity, $alerts := (groupAlertsByLabel .Alerts "severity") -}}
{{- range $index, $alert := $alerts }}
{{ $alert.Annotations.ip }}
{{ end }}
{{ end }}
{{ else -}}
127.0.0.1
{{- end -}}

127.0.0.1 is not the real alert instance ip .

wecom-temp-32f0f643bec4001ba6447ccb6b0a98c2

How to MIB file to snmp-notifier?

Hi,
In issue #8 , you mentioned that you customized default mib file to provide your own MIB file. In my case I have the MIB file with me, but how to provide that MIB file to snmp-notifier? Where default MIB file is placed in snmp-notifier?

About docker container configuration

Hi !
Wouldn't you mind to express how should I run container with the snmp notifier ?

I do it on that way (an usual configuration, no additional docker networks )

docker container run -p 9464:9464 -v /etc/snmp_notifier:/etc/snmp_notifier env_file=/etc/snmp_notifier/env_snmp.txt maxwo/snmp-notifier

where env_snmp.txt contains next strings

--web.listen-address=:9464
--snmp.version=V2c
--snmp.destination=another_host:162
--snmp.retries=1
--snmp.trap-oid-label="oid"
--snmp.trap-default-oid="1.3.6.1.4.1.98789.0.1"
--snmp.trap-description-template=/etc/snmp_notifier/description-template.tpl
--snmp.community="notpublicstring"
--alert.severity-label="severity"

When I run it I see next log

[root@my_host snmp_notifier]# docker run -v /etc/snmp_notifier:/etc/snmp_notifier -p 9464:9464 -p 162:162/udp --env-file /etc/snmp_notifier/env_snmp.txt maxwo/snmp-notifier
time="2020-05-20T12:26:01Z" level=info msg="Preparing to listen on: :9464" source="http_server.go:104"
my_host - - [20/May/2020:12:26:02 +0000] "POST /alerts HTTP/1.1" 200 0
my_host - - [20/May/2020:12:26:02 +0000] "POST /alerts HTTP/1.1" 200 0
my_host - - [20/May/2020:12:26:02 +0000] "POST /alerts HTTP/1.1" 200 0
my_host - - [20/May/2020:12:26:04 +0000] "POST /alerts HTTP/1.1" 200 0
my_host - - [20/May/2020:12:26:09 +0000] "POST /alerts HTTP/1.1" 200 0

So as you see I am able to receive webhooks from alertmanager
But I have no traps on another_host:162 at all.
What should I do to tune it, so that my container would be able to send traps ?

Meanwhile, it works fine from a command line . It gets webhooks and send traps with no issues.

Thanks for a really useful program. But it would be nice to add some info about docker container configuration.

Cheers
Andrii

Editing the description-template.tpl file for more fields

Hello,

I can get snmp trap packet from snmp_notifier. However, there are 3 field in the file. I added below the output, the 3rd field includes the Status , -Alert, Summary and Description information. I want to separate these fields parametrically. For example, the 4th field is Status, 5th field is -Alert, 6th field is Summary etc.

How can I edit the snmp_notifier template file ( --snmp.extra-field-template=4=alert-count.tpl ) for that configuration?

Could you please guide me?

Many thanks in advance.

  • SNMP notifier command line:
./snmp_notifier --web.listen-address=:9464 --alert.severities="critical,warning,info" --log.level=debug --snmp.destination=10.110.24.25:162

[1] .1.3.6.1.4.1.123.0.10.1.1.1.5.1.2.1 (OctetString): 1.3.6.1.4.1.123.0.10.1.1.1.5.1[]
[2] .1.3.6.1.4.1.123.0.10.1.1.1.5.1.2.2 (OctetString): critical
[3] .1.3.6.1.4.1.123.0.10.1.1.1.5.1.2.3 (OctetString): 1/1 alerts are firing:

Status: critical

  • Alert: PostgreSQLInstanceUpDown
    Summary: PostgreSQL Instance berlin03 down
    Description: berlin03 of job postgres has been down for more than 1 minutes.

groupAlertsByLable:wrong number of args for....

hello ;
this is a question when i execute ./snmp_notifier --..description-template.tpl
the Error :
502 bad Gateway: err=template : description-template.tpl : 2:33:executeing "description-template.tpl" at :wrong number of args for groupAlertsByLabel :want 2 got 0 . ......
this string "groupAlertsByLabel" is changed?

snmp-notifier is creating 3 fields only

func (trapSender TrapSender) generateVarBinds(alertGroup types.AlertGroup) (snmpgo.VarBinds, error) {
var (
varBinds snmpgo.VarBinds
)

trapUniqueID := strings.Join([]string{alertGroup.OID, "[", alertGroup.GroupID, "]"}, "")

descriptions, err := commons.FillTemplate(alertGroup, trapSender.configuration.DescriptionTemplate)
if err != nil {
	return nil, err
}

trapOid, _ := snmpgo.NewOid(alertGroup.OID)
varBinds = addUpTime(varBinds)
varBinds = append(varBinds, snmpgo.NewVarBind(snmpgo.OidSnmpTrap, trapOid))
varBinds = addStringSubOid(varBinds, alertGroup.OID, "1", trapUniqueID)
varBinds = addStringSubOid(varBinds, alertGroup.OID, "2", alertGroup.Severity)
varBinds = addStringSubOid(varBinds, alertGroup.OID, "3", *descriptions)

return varBinds, nil

}

@maxwo Here your code is adding 3 var-binds only. For our requirement, we need to handle more var-binds/SubOids. How can we do that? and when this feature can be assumed to added?

Is an IPv6 target supported?

I'm trying to use 1.2.1 with an ipv6 enabled snmptrapd target and can't get the notifier to send traps to the ipv6 address.

I've tried --snmp.destination=[fe80::250:56ff:fe83:e581]:162
log shows: level=error msg="502 Bad Gateway: err=dial udp [fe80::250:56ff:fe83:e581]:162: connect: invalid argument

--snmp.destination=udp6:[fe80::250:56ff:fe83:e581]:162
fails "too colons in address"

likewise for tcp6[fe80::250:56ff:fe83:e581]:162

All the tests in the code appear to be IPv4 only - so is ipv6 to the snmp destination supported?

Multiple destinations to send traps to

It does not seem to be possible to configure snmp_notifier to send the same trap to several destinations. --snmp.destination can only be specified once. Would it make sense to extend snmp_notifier to support sending traps to several destinations?

Using varbinds with common OID

Hello, just wondering if there is a way to create all alarms with the SAME OID and send the alarm details in the varbinds.

e.g. with the OID defined in the prometheusrules we get:

Alarm Number one OID 1.3.6.1.4.1.47984.2.3.1.2.1

iso.3.6.1.4.1.47984.2.3.1.2.1.1 = STRING: "1.3.6.1.4.1.47984.2.3.1.2.1[]"
iso.3.6.1.4.1.47984.2.3.1.2.1.2 = STRING: "warning"
iso.3.6.1.4.1.47984.2.3.1.2.1.3 = STRING: "Status: warning

Alarm Number two OID 1.3.6.1.4.1.47984.2.3.1.2.2

iso.3.6.1.4.1.47984.2.3.1.2.2.1 = STRING: "1.3.6.1.4.1.47984.2.3.1.2.2[]"
iso.3.6.1.4.1.47984.2.3.1.2.2.2 = STRING: "warning"
iso.3.6.1.4.1.47984.2.3.1.2.2.3 = STRING: "Status: warning

As we see the OID sent matches the OID in varbind #1

If a monitoring system is parsing alarms manually based on the OID it would be helpful to have a common OID (so not every OID requires an extra parsing rule)

e.g.

Alarm Number one OID 1.3.6.1.4.1.32804.1.6.2.2.1

iso.3.6.1.4.1.32804.1.6.2.1 = STRING: "1.3.6.1.4.1.32804.1.6.2.2.1[]"
iso.3.6.1.4.1.32804.1.6.2.2 = STRING: "warning"
iso.3.6.1.4.1.32804.1.6.2.3 = STRING: "Status: warning

Alarm Number two OID 1.3.6.1.4.1.32804.1.6.2.2.2

iso.3.6.1.4.1.32804.1.6.2.1 = STRING: "1.3.6.1.4.1.32804.1.6.2.2.2[]"
iso.3.6.1.4.1.32804.1.6.2.2 = STRING: "warning"
iso.3.6.1.4.1.32804.1.6.2.3 = STRING: "Status: warning

Is there something like this available by default?

We currently solved it in a kind of hacky was by changing: trapsender/trap_sender.go

trapOid, _ := snmpgo.NewOid(alertGroup.OID)
snmpTrapParam := ".1.3.6.1.4.1.32804.1.6.2"
varBinds = addUpTime(varBinds)
varBinds = append(varBinds, snmpgo.NewVarBind(snmpgo.OidSnmpTrap, trapOid))
varBinds = addStringSubOid(varBinds, snmpTrapParam,, "1", trapUniqueID)
varBinds = addStringSubOid(varBinds, snmpTrapParam,, "2", alertGroup.Severity)
varBinds = addStringSubOid(varBinds, snmpTrapParam,, "3", *descriptions)

Template for ID, similar as for Description

As for version 1.0.0 Description varbind is configurable via template, however ID is hardcoded.

It would be good to have templating mechanism for ID field too, with some way to filter out unwanted messages by setting it to empty for example and do not send trap in such case. This will make this tool much more flexible and powerful.

An example use cases:

  • remapping known OIDs to some more meaningful/nicer/shorter name. If I use only default OID, then putting it in ID field is not needed at all and I will be able to skip it
  • get rid of known garbage (if I group only on alertname on AlertManager, then "[alertname=" and "]" are also garbage.
  • filtering out OIDs which are not on white list
  • filtering out OIDs which are on blacklist

Event with basic comparison and regex it would be powerful.

Traps are not sent to SNMP Trap listener in 1.0

What did you do?
We are trying to forward the Prometheus Alert Manager Alerts to SNMP Agent Via this Maxwo/snmp_notifier.
We downloaded the binary from release history page. Version snmp_notifier-1.0.0.linux-amd64.tar.gz

Alerts are process / received by SNMP Notifier, but it is not sent to the SNMP Trap listener agent.

[xxxxxr@jumphost snmp_notifier-1.0.0.linux-amd64]$ ./snmp_notifier --snmp.trap-description-template=description-template.tpl --snmp.destination=x.x.x.x:162
INFO[0000] Preparing to listen on: :9464 source="http_server.go:104"
10.0.x.x - - [03/Dec/2020:09:41:09 -0500] "POST /alerts HTTP/1.1" 200 0
10.0.x.x - - [03/Dec/2020:09:41:58 -0500] "POST /alerts HTTP/1.1" 200 0
10.0.x.x - - [03/Dec/2020:09:42:28 -0500] "POST /alerts HTTP/1.1" 200 0
10.0.x.x - - [03/Dec/2020:09:46:09 -0500] "POST /alerts HTTP/1.1" 200 0

Dependabot can't resolve your Go dependency files

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

github.com/maxwo/snmp_notifier/alertparser: cannot find module providing package github.com/maxwo/snmp_notifier/alertparser
	github.com/maxwo/snmp_notifier/configuration: cannot find module providing package github.com/maxwo/snmp_notifier/configuration
	github.com/maxwo/snmp_notifier/httpserver: cannot find module providing package github.com/maxwo/snmp_notifier/httpserver
	github.com/maxwo/snmp_notifier/telemetry: cannot find module providing package github.com/maxwo/snmp_notifier/telemetry
	github.com/maxwo/snmp_notifier/trapsender: cannot find module providing package github.com/maxwo/snmp_notifier/trapsender

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

502 BAD GATEWAY

What did you do?
Using webhooks in alertmanager on OpenShift to send data to snmp notifier.
What did you see instead? Under which circumstances?
Getting:
DEBU[0783] Handling /alerts webhook request source="http_server.go:76"
ERRO[0783] 502 Bad Gateway: err=template: description-template.tpl:1:7: executing "description-template.tpl" at <(len .Alerts) gt 0>: can't give argument to non-function len .Alerts data=&{Receiver:occluster-webhook-receiver Status:firing Alerts:[{Status:firing Labels:map[alertname:KubeNodeUnreachable effect:NoSchedule endpoint:https-main instance:IPADDR:8443 job:kube-state-metrics key:node.kubernetes.io/unreachable namespace:openshift-monitoring node: $nodename pod:kube-state-metrics-55f99f49d7-lp9pb prometheus:openshift-monitoring/k8s service:kube-state-metrics severity:warning]

Wondering why i'm getting this.. Any ideas?

  • System information:
    Running snmp_notifier on CentOS 7 VM.

  • SNMP notifier version:

snmp_notifier, version 1.0.0 (branch: master, revision: 011a200)

  • SNMP notifier command line:
./snmp_notifier --snmp.destination=$IP_ADDRESS:162 --snmp.trap-description-template=description-template.tpl --log.level="debug"

snmp_notifier does not forward tag information of alertmanager alerts

Following is the captured snmp trap with snmptrapd service

iso.3.6.1.2.1.1.3.0 = Timeticks: (11256000) 1 day, 7:16:00.00 iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.98789.0.1 iso.3.6.1.4.1.98789.0.1.1 = STRING: "1.3.6.1.4.1.98789.0.1[alertname=node_filesystem_free_bytes]" iso.3.6.1.4.1.98789.0.1.2 = STRING: "warning" iso.3.6.1.4.1.98789.0.1.3 = STRING: "Status: warning
Alert: node_filesystem_free_bytes
Summary: Test Alert from Prometheus
Description: This is a test alert from Prometheus"

I also attach the alertmanager alert snapshot from alertmanager gui. As we can see. the snmp trap lose all the labels information
alertmanager

Extra fields doesn't do templating on resolved alerts

What did you do?
I've been trying to match output of SNMP Notifier with a 3rd party tool that listen for SNMP trap, almost all of the progress seems great except that we need resolved alert to do templating so we can distinguish the source of that trap and resolve it on 3rd party tool end.

My use case is that there is one alert about Prometheus target down. I've been using extra field to tell 3rd party tool to know that the source can be get from specific oid generated from extra field.

Firing alerts seems to do templating perfectly, but when it is resolved alert all extra fields seems to be empty. The only place I can get data is the label oid which the 3rd party tool doesn't expect that will be how we resolve our alert, so if we can adjust SNMP Notifier to support templating on alert resolved that could be great.

For now I'll open an issue first, I'm not a Go expert but I could take a look at the code and make some contribution but it could take awhile. If there are anyone that can make this adjustment I really appreciate it.

What did you expect to see?
I expect resolved alert to do templating on extra variables.
Here are the example I got from tcpdump on my lab.

# Firing alert
C="demo" V2Trap(612)
E:98789.0.1032.1="1.3.6.1.4.1.98789.0.1032[alertname=NodeExporterDown,alerter=ruler,group=Demo,hostname=demo01,instance=10.153.73.18:9100,job=node_exporter,oid=1.3.6.1.4.1.98789.0.1032,severity=critical,site=demo,system=demoSystem]"
E:98789.0.1032.2="critical" 
E:98789.0.1032.3="demo01/10.153.73.18:9100: Node Exporter down" 
E:98789.0.1032.7="NodeExporterDown" 
E:98789.0.1032.8="2021-06-10 11:30:51.209908121 +0000 UTC" 
E:98789.0.1032.9="critical" 
E:98789.0.1032.4="demo01" 
E:98789.0.1032.5="10.153.73.18:9100" 
E:98789.0.1032.6="demoSystem"

# Resolved alert
C="demo" V2Trap(489)
E:98789.0.1032.1="1.3.6.1.4.1.98789.0.1032[alertname=NodeExporterDown,alerter=ruler,group=Demo,hostname=demo01,instance=10.153.73.18:9100,job=node_exporter,oid=1.3.6.1.4.1.98789.0.1032,severity=critical,site=demo,system=demoSystem]" 
E:98789.0.1032.2="info" 
E:98789.0.1032.3="Status: OK" 
E:98789.0.1032.9="" 
E:98789.0.1032.4=""
E:98789.0.1032.5=""
E:98789.0.1032.6=""
E:98789.0.1032.7=""
E:98789.0.1032.8=""

What did you see instead? Under which circumstances?
Resolved trap seems to not do any templating for extra variables at all.

I'm running on SNMP Notifier 1.1.0.
I see that version 1.1.1 only change is to force SNMPv3 to have username in config so I didn't upgrade yet.

If I'm missing any info please tell me.

Switch build system to Github Actions

Use Github Actions to build/release the project.

Reuse the same actions as the official Prometheus repository & build system to ensure consistency.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.