search

sparky8512 / starlink-grpc-tools

Random scripts and other bits for interacting with the SpaceX Starlink user terminal hardware
The Unlicense
482 stars 64 forks source link

Add periodic loop option to all polling scripts #9

Closed sparky8512 closed 3 years ago

sparky8512 commented 3 years ago

The dishStatusInflux.py script implements status info polling in a periodic loop (although it can now be run in one-shot mode, too, by passing -t 0 option).

The other status and history stats polling scripts are all currently one-shot only.

They should all implement an interval timing loop to (optionally) poll and report info periodically. And they should all default to the same behavior, which would mean either changing dishStatusInflux.py to be one-shot by default or changing the others to poll every 30 seconds by default. Probably the former.

The loop in dishStatusInflux.py got a little messy, but that's mostly due to keeping the grpc channel open (as well as the InfluxDB client). That's not strictly necessary.

neurocis commented 3 years ago

Can you double check that one shot with -t 0? I have been meaning to ask but is the 5-loop queue before flush to Influx necessary?

Equinox- commented 3 years ago

It's not necessary to batch the measurements before submitting to Influx. But for my use case the InlufxDB server is not accessible over LAN so batching (and especially retrying in the next batch) is necessary if I want to get metrics after downtime windows.

sparky8512 commented 3 years ago

Right. It'll still flush the single data point with -t 0 in the finally clause on the way out, though. That's mostly how I've been testing.

@Equinox- : It's good you mentioned that use case, as I've been testing on a local InfluxDB instance, so hadn't really been thinking in those terms. I guess that's a good motivation for running in a loop vs running one-shot via cron or whatever. It sounds like the important part is the queuing and retrying on failure vs always batching requests, though? Any reason not to just always try to commit on every loop iteration?

Equinox- commented 3 years ago

Not any particular reason, besides it generally being good practice to batch writes to time series DBs

sparky8512 commented 3 years ago

OK, thanks. It being "generally good practice" is a good enough reason to keep it, then, it's only a few lines of code. I dropped usage of SeriesHelper from the history script because it was just getting in the way and I was wondering how import that was.