How to interpret topic gateway/{GWID}/event/stats: txPacketsReceived,txPacketsEmitted drop to 0

ChirpStack Gateway OS
1

At our ChirpStack deployment, we set up an InfluxDB database and a custom process that extracts fields from the gateway/{GATEWAY_ID}/event/stats JSON payloads for all of our gateways, and writes them to the database. The fields we are extracting are:

rxPacketsReceived
rxPacketsReceivedOk
txPacketsReceived
txPacketsEmitted

Among our gateways, there are two of them that cover overlapping regions. On one of them, we have seen that the historical values up until a particular timestamp were all non-zero. However, after a brief loss of communication (detection and logging of which is why we set up the InfluxDB server in the first place), the payload logging resumed, but both txPacketsReceived and txPacketsEmitted are now 0. The other gateway lost communication a few minutes later, then resumed, and its own counters remained nonzero up until now. Both gateway devices are RPI4 and their uptime remained normal through the internet blackout.

Here is one example payload from the anomalous device:

{
    "gatewayID":"3KYy//6Vytw=",
    "ip":"192.168.117.10",
    "time":"2024-10-15T08:51:31Z",
    "location":null,
    "configVersion":"",
    "rxPacketsReceived":123,
    "rxPacketsReceivedOK":110,
    "txPacketsReceived":0,
    "txPacketsEmitted":0,
    "metaData":{},
    "statsID":"fr7Wt6UHTTmralR9XLLj9g=="
}

How should we interpret the counters? Should we be worried that the tx counters dropped to zero across the internet blackout?

One thing of note is that, for the same {GATEWAY_ID}, the topic gateway/{GATEWAY_ID}/command/down remains active and receiving payloads.

2

If I restart chirpstack-gateway-bridge.service at the affected gateway, the counters again show as nonzero while receiving downlinks. However, this is only a temporary fix.

I now suspect the service version is to blame. The affected gateway has chirpstack-gateway-bridge version 3.9.2. On the other gateway, which is not affected, it has version 3.14.6. I will try scheduling a package update to see if this fixes the problem for good.

3

Please note that in the current implementation, what you see is the count between two stats messages. To get the total, you need to add the counts.

One thing I would like to do in the future to always increment the counter, thus then the increment is calculated by previous stats count - current stats count.