I have three switches (16 port, 8 port, 8 port). Fetching these metrics using prometheus creates a lot of network traffic of up to 70 megabyte per second. I wonder how these metrics could create such a traffic spike?

Hi,

first of all, thanks for the exporter! It works great in my home network.
Ideally though it would follow Prometheus' best practices of using base units: https://prometheus.io/docs/practices/naming/#base-units

That would mean changing prosafe_link_speed to prosafe_link_speed_bytes, similarly to the node-exporter's node_network_speed_bytes.

I can submit a PR to change this if this is acceptable.

Hello,

I have an issue, I have no metrics concerning the switch.

I deployed the exporter inside a docker container, with the following configuration:

prosafe_exporter version from commit b3747c2 from master

docker-compose.yml:

[...]
  prosafe-exporter:
    build: ./prosafe_exporter
    container_name: prosafe-exporter
    restart: unless-stopped
    expose:
      - 9493
    networks:
      - monitoring
    command:
      - '--verbose'
[...]

prometheus.yml:

[...]
- job_name: "prosafe"
    static_configs:
      - targets: ["192.168.1.8:*"]
    metrics_path: /probe
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: "prosafe-exporter:9493"
[...]

Switch product name: GS108Ev3
Switch bootloader version: V2.06.03
Switch firmware version: V2.06.14EN
Switch Management Mode: Configured on "Web browser and Plus Utility"

I can ping the switch from inside the conatiner with sudo docker exec prosafe-exporter ping 192.168.1.8

But with sudo docker exec prosafe-exporter wget -O - localhost:9493/probe I have only the following metrics:

# HELP prosafe_build_info A metric with a constant '1' value labeled by version, revision and rustversion.
# TYPE prosafe_build_info gauge
prosafe_build_info{revision="",rustversion="1.63.0",version="0.2.9-pre"} 1

Logs from container:

Server started: 0.0.0.0:9493

Did I missed something? Maybe there are an issue with docker networking?

Thanks a lot for your work!

Hi there,

thanks for building this exporter. In our setup we have two Prometheus instances (for redundancy), both with identical configuration, which scrape the prosafe_exporter that is deployed as a single instance on our network (close to the switches).

Everything works fine as long as only a single Prometheus instance is scraping the exporter. As soon as we start the second instance, the prosafe_up metric very often comes back as 0 and the other metrics are missing.

Could it be that the prosafe_exporter is not thread-safe?

Thanks,
Thilo

P.S.: Our current workaround is to deploy two instances, one for each Prometheus instance.

ex. 192.168.0.10:eth0, switch0:eno1

I am trying to run this exporter in kubernetes.

For some reason within kubernetes it does not show collect metrics from my prosafe switch. This happens even if I run the container with hostNetwork mode.

This is the output at my workstation:

~ >>> curl -v "http://127.0.0.1:9493/probe?target=192.168.178.4:eth0"                                                                                                                                  
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9493 (#0)
> GET /probe?target=192.168.178.4:eth0 HTTP/1.1
> Host: 127.0.0.1:9493
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-length: 3323
< date: Sun, 05 May 2019 19:03:02 GMT
< 
# HELP prosafe_build_info A metric with a constant '1' value labeled by version, revision and rustversion.
# TYPE prosafe_build_info gauge
prosafe_build_info{revision="",rustversion="",version="0.2.5-pre"} 1
# HELP prosafe_error_packets_total Transfer error in packets.
# TYPE prosafe_error_packets_total gauge
prosafe_error_packets_total{port="1"} 0
prosafe_error_packets_total{port="10"} 0
prosafe_error_packets_total{port="11"} 0
prosafe_error_packets_total{port="12"} 0
..l.

This is the same output against my container running in the cluster:

$ curl -v "http://10.43.85.247:9493/probe?target=192.168.178.4:eth0"
*   Trying 10.43.85.247...
* TCP_NODELAY set
* Connected to 10.43.85.247 (10.43.85.247) port 9493 (#0)
> GET /probe?target=192.168.178.4:eth0 HTTP/1.1
> Host: 10.43.85.247:9493
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-length: 293
< date: Sun, 05 May 2019 19:01:55 GMT
< 
# HELP prosafe_build_info A metric with a constant '1' value labeled by version, revision and rustversion.
# TYPE prosafe_build_info gauge
prosafe_build_info{revision="",rustversion="",version="0.2.5-pre"} 1
# HELP prosafe_up The last query is successful.
# TYPE prosafe_up gauge
prosafe_up 0
* Curl_http_done: called premature == 0
* Connection #0 to host 10.43.85.247 left intact

This is my helm chart for the prosafe exporter:
https://github.com/runningman84/helm-charts/tree/master/prosafe-exporter

Would it be possible to add a build for use on Raspberry Pi OS 64-bit?

Hi there,

I am attempting to build prosafe_exporter for arm64/aarch64. Unfortunately, this fails due to an incompatibility in nix 0.10.0, which gets pulled in via interfaces2:

[...]
   Compiling tokio-buf v0.1.1
   Compiling string v0.2.1
   Compiling rand_chacha v0.2.2
   Compiling url v2.2.0
error[E0425]: cannot find value `MAP_32BIT` in crate `libc`
  --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/nix-0.10.0/src/sys/mman.rs:49:9
   |
49 |         MAP_32BIT;
   |         ^^^^^^^^^ not found in `libc`
   Compiling toml v0.5.7
   Compiling bincode v1.3.1
   Compiling tokio-timer v0.2.13
   Compiling tokio-current-thread v0.1.7
error: aborting due to previous error
For more information about this error, try `rustc --explain E0425`.
error: could not compile `nix`
To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

I would have opened an issue over there, but interfaces2 has disabled the issue tracker... Maybe you have an idea how to work around this issue or avoid the usage of interfaces2.

Thanks!