Starting in hsflowd version 2.0.50-3, the mod_dbus module can be asked for the current sFlow agent-address along with other stats, and the example "telemetry" and "telemetry.py" scripts in the repo under src/Linux/scripts/ have both been updated. So if you wanted to offer a "show sflow" CLI command then you might adapt one or other of those scripts to extract the information from the running hsflowd process. The steps would be:

(1) make deb FEATURES="PCAP DROPMON DBUS"

(2) add "dbus{}" line to hsflowd.conf

(3) have "show sflow" call something like the "telemetry.py" script. Example output:

hsflowd version is: 2.0.50
hsflowd agent IP address is: 10.0.0.117
packet samples dropped internally = 0
packet samples sent = 855
counter samples sent = 7842
datagrams sent = 2484

The telemetry.py script is here:
https://github.com/sflow/host-sflow/blob/master/src/Linux/scripts/telemetry.py

PR https://github.com/vyos/vyos-build/pull/329

PR https://github.com/vyos/vyos-1x/pull/1927
Formatted output:

vyos@r14:~$ show sflow 
--------------------------  -----------------------------------
Agent address               192.168.122.14
sFlow interfaces            ['eth0', 'eth1']
sFlow servers               ['192.168.122.1', '192.168.122.11']
Datagrams sent              306
Packet samples sent         18
Packet samples dropped      0
Counter samples sent        917
Flow samples suppressed     0
Counter samples suppressed  0
--------------------------  -----------------------------------
vyos@r14:~$

Raw output:

vyos@r14:~$ sudo /usr/libexec/vyos/op_mode/sflow.py show --raw
{
    "agent_address": "192.168.122.14",
    "sflow_interfaces": [
        "eth0",
        "eth1"
    ],
    "sflow_servers": [
        "192.168.122.1",
        "192.168.122.11"
    ],
    "counter_samples_sent": 1077,
    "datagrams_sent": 359,
    "packet_samples_dropped": 0,
    "packet_samples_sent": 19,
    "rtmetric_samples": 0,
    "flow_samples_suppressed": 0,
    "counter_samples_suppressed": 0,
    "hsflowd_version": "2.0.50"
}
vyos@r14:~$

I think there should be one more metric - the number of packet-drop-events sent. I just checked in a change that adds to the example telemetry.py script:
https://github.com/sflow/host-sflow/commit/5b01779abf21a7553e07188ff2f54850c568f786

But we should also expose the number of drops that were suppressed by the mod_dropmon rate limit. I'll check in 2.0.50-4 later today to add that option too.

In T5125#146162, @neilmckee wrote:

I think there should be one more metric - the number of packet-drop-events sent. I just checked in a change that adds to the example telemetry.py script:
https://github.com/sflow/host-sflow/commit/5b01779abf21a7553e07188ff2f54850c568f786

But we should also expose the number of drops that were suppressed by the mod_dropmon rate limit. I'll check in 2.0.50-4 later today to add that option too.

Could you check tags? 20.0.50-4 vs 2.0.50-4

Apologies. I believe it is corrected now.

PR https://github.com/vyos/vyos-1x/pull/1929

vyos@vyos2:~$ show sflow 
--------------------------  ------------------------
Agent address               127.0.2.5
sFlow interfaces            ['eth4', 'eth3', 'eth2']
sFlow servers               ['127.0.0.1']
Counter samples sent        235
Datagrams sent              247
Packet samples sent         12
Packet samples dropped      0
Samples drop events sent    0
Flow samples suppressed     0
Counter samples suppressed  0
--------------------------  ------------------------
vyos@vyos2:~$

The packet-drop events are not really samples in the same way as the packets are random-samples and the counters are time-samples. Even if there is only 1 dropped packet it will be sent. So it might be better to change the wording from “Samples drop events sent” to something like “Packet drop events sent” or just “Packet drops sent”. Make sense?

And then I also suggest you add the DBUS “event_samples_suppressed” telemetry counter and call it “Packet drop events suppressed” or just “Packet drops suppressed”. That one will increment if the configured rate-limit on packet drops kicks in, so it is interesting. I think you set the default rate limit to 50, so a router dropping more than 50 packets/sec will increment this number quickly.

PR https://github.com/vyos/vyos-1x/pull/1932

vyos@r14:~$ show sflow 
--------------------------  -----------------------------------
Agent address               192.168.122.14
sFlow interfaces            ['eth0', 'eth1']
sFlow servers               ['192.168.122.1', '192.168.122.11']
Counter samples sent        159
Datagrams sent              949
Packet samples sent         124
Packet samples dropped      0
Packet drops sent           815
Packet drops suppressed     0
Flow samples suppressed     0
Counter samples suppressed  0
--------------------------  -----------------------------------
vyos@r14:~$

@neilmckee Is it correct that drop event samples sent uses "event_samples"

Yes. Packet drops are classed as "event_samples" internally. Definitions for telemetry counters are here:
https://github.com/sflow/host-sflow/blob/v2.0.50-4/src/Linux/hsflowd.h#L460-L486

And mod_dropmon increments event_samples here:
https://github.com/sflow/host-sflow/blob/v2.0.50-4/src/Linux/mod_dropmon.c#L907-L910

And mod_dropmon increments event_samples_suppressed (rate-limit) here:
https://github.com/sflow/host-sflow/blob/v2.0.50-4/src/Linux/mod_dropmon.c#L865-L871

@neilmckee Thanks.
If output looks good we can close the task