SNMP we already have, but it is likely to be much more limited than the other sources.
There are probably exporters and dashboards for this already we can use as a starting point, but it will need integrating.
As with other mixing/matching, same hostname data should be merged, e.g. if we have SNMP (and/or IPMI) and remote MySQL for the same server name, these should be treated as the same server. We need to figure out what to do if/when the same data is retrieved via, say, SNMP and IPMI, or IPMI and lm_sensors, which to use in preference for dashboard graphs (and whether to make it configurable on a per host basis, either from the web interface (we'd end up with both in prometheus) or on the server itself in ssm-client .conf files.
There are three ways we can get hardware monitoring information, such as:
1) IPMI (
ipmitool -I lanplus -H 192.168.1.2 -U user -P password sensor). 2) lm_sensors (sensors) 3) SNMP 4) smartctl -a /dev/disknameSNMP we already have, but it is likely to be much more limited than the other sources. There are probably exporters and dashboards for this already we can use as a starting point, but it will need integrating.
As with other mixing/matching, same hostname data should be merged, e.g. if we have SNMP (and/or IPMI) and remote MySQL for the same server name, these should be treated as the same server. We need to figure out what to do if/when the same data is retrieved via, say, SNMP and IPMI, or IPMI and lm_sensors, which to use in preference for dashboard graphs (and whether to make it configurable on a per host basis, either from the web interface (we'd end up with both in prometheus) or on the server itself in ssm-client .conf files.