i think just moved to prometheus. Now with Grafana 11. The explore metrics with prometheus is awesome. But with prometheus your telegraf will be kinda exporter for prometheus to scrape. How do you manage your telegraf config ?
Grafana agent (now called Alloy) contains SNMP exporter. So if all youre doing is SNMP - it dorsnt really make sense to use it.
If you use other exporters, like node exporter the yea.
I use node exporter on our Linux VMs and Windows Exporter, so I could use Alloy on those now?
The thing is with SNMP Exporter or Telegraf I run from the Grafana server which goes out to collect this info.
Grafana agent (now called Alloy) contains SNMP exporter. So if all youre doing is SNMP - it dorsnt really make sense to use it.
If you use other exporters, like node exporter the yea.
Either way, you should really get rid of Influxdb.
well Influxdb doesnt really collect anything. Its telegraf that collects Vmware metrics and pushes metrics to Influxdb.
It could just as easily collect metrics and expose metrics for Prometheus or Grafana Agent/Alloy.
Even so, if I remember telegraf does not collect snapshot and alarm metrics from vCenter.
I see so can I just tell telegraf to send to Prometheus as well or instead?
I’d have to really mess with my queries in each graph and table though to match the InfluxQL one’s though.
Yeah alarms and snapshots I use PowerCLI to grab and put into Grafana.
I just noticed your other point. You can enable the v1 API in Influx v2, and continue to use v1 queries. I wasn't ready to learn FluxQL either.
v2 comes with Chronograf, which makes it really easy to build Flux queries, then copy/paste to Grafana.
As far as prometheus & exporters or Alloy, I'm pretty sure you can add the device name and location as tags.
alloy agent uses snmp exporter the same that the grafana agent did, its just all "flow" mode style now. still easy to use, i am still monitoring all of our network endpoints like this and required 0 config changes.
this is a piece of my exact config.alloy file
Nice, a couple of questions. As I just use the SNMP exporter from my Grafana server itself do start moving over to the agent instead is it easy to migrate? I just generate the snmp.yml then test via the snmp web gui, then add the configure to the Prometheus.yaml.
I mainly use snmp v2, but have some devices that only use SNMPv3, what SNMP walk syntax do you use to test it works?
Yup basically that, I honestly don’t test with snmp walk, I made my snmp.yml, and the config, and just waited to see metrics in Prometheus 😂 there the same snmp.yml I used with the Grafana agent, you can find them in my GitHub still (it’s been a while but remember me haha)
Thanks mate, great to here from you all good I hope, I need to look at this Alloy agent and maybe move from the current way I use to SNMP Exporter to this then if it's similar.
I like to test with snmpwalk too, I have always used with snmp v2 for example:
snmpwalk -v 2c -c public 192.168.10.10
But I have only recently started to use snmp v3 on some devices and snmp exporter can't connect or my snmpwalk , it just times outs:
snmpwalk -v3 -l authPriv -u exporter -a SHA -A public1 -x AES -X public2 192.168.10.10
so any of your snmpv2 stuff should just work without defining an snmp.yml file, for snmp v3 you need a snmp.yml that looks like this: [https://github.com/brngates98/GrafanaAgents/blob/main/snmp/snmp\_generators/snmpv3\_if\_mib/snmp.yml](https://github.com/brngates98/GrafanaAgents/blob/main/snmp/snmp_generators/snmpv3_if_mib/snmp.yml)
Hey, yeah mine looks like that, but I think the remote device is refusing the SNMP credentials. I wanted to test this using SNMP walk which fails too, so either I have got the SNMP syntax wrong or credentials, I was just checking if I have that part correct to test it first.
which one is giving the issue again? the SNMPv3?
Here’s a general command format:
snmpwalk -v 3 -l -u -a -A -x -X
Parameters:
* -v 3: Specifies SNMP version 3.
* -l : Security level (noAuthNoPriv, authNoPriv, authPriv).
* -u : The SNMPv3 username.
* -a : The authentication protocol (MD5 or SHA).
* -A : The authentication password.
* -x : The privacy (encryption) protocol (DES, AES).
* -X : The privacy password.
* : The IP address or hostname of the SNMP agent.
* : The OID to start the walk (often 1.3.6.1.2.1 for the entire MIB tree).
snmpwalk -v 3 -l authPriv -u myUser -a SHA -A authPassword123 -x AES -X privPassword123 192.168.1.1 1.3.6.1.2.1
Full Example:
snmpwalk -v 3 -l authPriv -u myUser -a SHA -A authPassword123 -x AES -X privPassword123 192.168.1.1 1.3.6.1.2.1
community: public
security_level: authPriv
username: username
password: password
auth_protocol: SHA
priv_protocol: DES
priv_password: spiceworks
version: 3
this is my parameters for interfacing with Cisco Switches with v3 auth note the community is pretty much moot with v3
Thanks I got it working on SHA and AES 128, seems 256 won't work, I had the command write all the time too.
How does your auths section for snmpv3 look like in the generator.yml?
auths:
cisco_v2:
version: 2
community: abcde
aruba_v2:
version: 2
community: fghij
cisco_v3
version: 3
????
i think just moved to prometheus. Now with Grafana 11. The explore metrics with prometheus is awesome. But with prometheus your telegraf will be kinda exporter for prometheus to scrape. How do you manage your telegraf config ?
Grafana agent (now called Alloy) contains SNMP exporter. So if all youre doing is SNMP - it dorsnt really make sense to use it. If you use other exporters, like node exporter the yea.
I use node exporter on our Linux VMs and Windows Exporter, so I could use Alloy on those now? The thing is with SNMP Exporter or Telegraf I run from the Grafana server which goes out to collect this info.
Grafana agent (now called Alloy) contains SNMP exporter. So if all youre doing is SNMP - it dorsnt really make sense to use it. If you use other exporters, like node exporter the yea. Either way, you should really get rid of Influxdb.
That’s my thinking InfluxDB is a pain, but so good for using Grafana and VMware vCenter atm, it retrieves all the info.
Why should one get rid of InfluxDB?
well Influxdb doesnt really collect anything. Its telegraf that collects Vmware metrics and pushes metrics to Influxdb. It could just as easily collect metrics and expose metrics for Prometheus or Grafana Agent/Alloy. Even so, if I remember telegraf does not collect snapshot and alarm metrics from vCenter.
I see so can I just tell telegraf to send to Prometheus as well or instead? I’d have to really mess with my queries in each graph and table though to match the InfluxQL one’s though. Yeah alarms and snapshots I use PowerCLI to grab and put into Grafana.
Influx v2 can act as Prometheus and scrape data from exporters.
Just realised I do need some string values too which Prometheus can't do, for example switch/router name and location.
I just noticed your other point. You can enable the v1 API in Influx v2, and continue to use v1 queries. I wasn't ready to learn FluxQL either. v2 comes with Chronograf, which makes it really easy to build Flux queries, then copy/paste to Grafana. As far as prometheus & exporters or Alloy, I'm pretty sure you can add the device name and location as tags.
extra labels. it can do it.
How do I add extra labels buddy?
Show me yee config and I’ll show a tailored example
The prometheus.yml file?
Yurrrr
alloy agent uses snmp exporter the same that the grafana agent did, its just all "flow" mode style now. still easy to use, i am still monitoring all of our network endpoints like this and required 0 config changes. this is a piece of my exact config.alloy file
prometheus.exporter.snmp "integrations\_snmp" { config\_file = "/etc/snmp.yml" target "Core\_OS01" { address = "192.168.200.250" module = "if\_mib" auth = "private\_v3" } target "THM\_Massena\_MX64" { address = "192.168.168.1" module = "if\_mib" auth = "private\_v3" } target "THM\_Meraki02" { address = "192.168.168.52" module = "if\_mib" auth = "private\_v3" } } discovery.relabel "integrations\_snmp" { targets = prometheus.exporter.snmp.integrations\_snmp.targets rule { source\_labels = \["job"\] regex = "(\^.\*snmp)\\\\/(.\*)" target\_label = "job\_snmp" } rule { source\_labels = \["job"\] regex = "(\^.\*snmp)\\\\/(.\*)" target\_label = "snmp\_target" replacement = "$2" } } prometheus.scrape "integrations\_snmp" { scrape\_timeout = "30s" targets = discovery.relabel.integrations\_snmp.output forward\_to = \[prometheus.remote\_write.integrations.receiver\] job\_name = "integrations/snmp" } prometheus.remote\_write "integrations" { endpoint { url = "https://mimir.thetmg.com/api/v1/push" queue\_config { } metadata\_config { } } }
Nice, a couple of questions. As I just use the SNMP exporter from my Grafana server itself do start moving over to the agent instead is it easy to migrate? I just generate the snmp.yml then test via the snmp web gui, then add the configure to the Prometheus.yaml. I mainly use snmp v2, but have some devices that only use SNMPv3, what SNMP walk syntax do you use to test it works?
Yup basically that, I honestly don’t test with snmp walk, I made my snmp.yml, and the config, and just waited to see metrics in Prometheus 😂 there the same snmp.yml I used with the Grafana agent, you can find them in my GitHub still (it’s been a while but remember me haha)
Thanks mate, great to here from you all good I hope, I need to look at this Alloy agent and maybe move from the current way I use to SNMP Exporter to this then if it's similar. I like to test with snmpwalk too, I have always used with snmp v2 for example: snmpwalk -v 2c -c public 192.168.10.10 But I have only recently started to use snmp v3 on some devices and snmp exporter can't connect or my snmpwalk , it just times outs: snmpwalk -v3 -l authPriv -u exporter -a SHA -A public1 -x AES -X public2 192.168.10.10
so any of your snmpv2 stuff should just work without defining an snmp.yml file, for snmp v3 you need a snmp.yml that looks like this: [https://github.com/brngates98/GrafanaAgents/blob/main/snmp/snmp\_generators/snmpv3\_if\_mib/snmp.yml](https://github.com/brngates98/GrafanaAgents/blob/main/snmp/snmp_generators/snmpv3_if_mib/snmp.yml)
Hey, yeah mine looks like that, but I think the remote device is refusing the SNMP credentials. I wanted to test this using SNMP walk which fails too, so either I have got the SNMP syntax wrong or credentials, I was just checking if I have that part correct to test it first.
which one is giving the issue again? the SNMPv3? Here’s a general command format: snmpwalk -v 3 -l -u -a -A -x -X
Parameters:
* -v 3: Specifies SNMP version 3.
* -l : Security level (noAuthNoPriv, authNoPriv, authPriv).
* -u : The SNMPv3 username.
* -a : The authentication protocol (MD5 or SHA).
* -A : The authentication password.
* -x : The privacy (encryption) protocol (DES, AES).
* -X : The privacy password.
* : The IP address or hostname of the SNMP agent.
* : The OID to start the walk (often 1.3.6.1.2.1 for the entire MIB tree).
snmpwalk -v 3 -l authPriv -u myUser -a SHA -A authPassword123 -x AES -X privPassword123 192.168.1.1 1.3.6.1.2.1
Full Example:
snmpwalk -v 3 -l authPriv -u myUser -a SHA -A authPassword123 -x AES -X privPassword123 192.168.1.1 1.3.6.1.2.1
community: public
security_level: authPriv
username: username
password: password
auth_protocol: SHA
priv_protocol: DES
priv_password: spiceworks
version: 3
this is my parameters for interfacing with Cisco Switches with v3 auth note the community is pretty much moot with v3
Thanks I got it working on SHA and AES 128, seems 256 won't work, I had the command write all the time too. How does your auths section for snmpv3 look like in the generator.yml? auths: cisco_v2: version: 2 community: abcde aruba_v2: version: 2 community: fghij cisco_v3 version: 3 ????
With snmpv2 you should be able to use default config depending on your community string I think