bb-Ricardo/fritzinfluxdb

A new retention policy "1year" override my existing default retention policy "90_days"

Closed this issue · 4 comments

Hi Ricardo

I use Docker compose to start my monitoring stack (InfluxDB v1.8.10, Grafana, Telegraf, Mosquitto and FritzInfluxDB). With the latest release from today. Now I'm facing following issue.

I created the fritzbox database in before, with a retention policy "90_days" and set it as default. When I now start the containers, a new retention policy "1year" will created and set as default, so that all data will be stored there.

Remark: I didn't face this issue with the container I build 5 months ago.

 INFO: Starting fritzinfluxdb v1.1.0 (2022-11-02)
 INFO: Done reading config files
 INFO: Successfully parsed config
 ERROR: Failed to connect to InfluxDB: HTTPConnectionPool(host='127.0.0.1', port=8086): Max retries exceeded with url: /ping (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f886ea4f0>: Failed to establish a new connection: [Errno 111] Connection refused'))
 INFO: Successfully established FritzBox TR-069 session
 INFO: Successfully established FritzBox Lua session
 ERROR: Initializing connection to InfluxDB failed
 INFO: Starting fritzinfluxdb v1.1.0 (2022-11-02)
 INFO: Done reading config files
 INFO: Successfully parsed config
 ERROR: Failed to connect to InfluxDB: HTTPConnectionPool(host='127.0.0.1', port=8086): Max retries exceeded with url: /ping (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f7f9db220>: Failed to establish a new connection: [Errno 111] Connection refused'))
 INFO: Successfully established FritzBox TR-069 session
 INFO: Successfully established FritzBox Lua session
 ERROR: Initializing connection to InfluxDB failed
 INFO: Starting fritzinfluxdb v1.1.0 (2022-11-02)
 INFO: Done reading config files
 INFO: Successfully parsed config
 INFO: Connection to InfluxDB 1.8.10 established and database present
 INFO: Successfully established FritzBox TR-069 session
 INFO: Successfully established FritzBox Lua session
 INFO: Successfully connected to FritzBox '192.168.178.1' (fritz.box) Model: FRITZ!Box 7590 (DSL) - FW: 7.29
 INFO: Starting main loop
 ERROR: Unable to perform request to 'http://192.168.178.1/data.lua': HTTPConnectionPool(host='192.168.178.1', port=80): Read timed out. (read timeout=10)
 ERROR: Unable to request FritzBox Lua service 'System logs', no data returned
 INFO: FritzBox Lua service 'System logs' will be disabled.
 ERROR: Failed to write to InfluxDB '127.0.0.1': HTTPConnectionPool(host='127.0.0.1', port=8086): Read timed out. (read timeout=2)
 INFO: Connection to influxDB '127.0.0.1' restored.
 INFO: Flushing '3184' measurements to InfluxDB
 INFO: Purging '528' measurements which are older (2021-12-01 12:06:00+01:00) then the InfluxDB configured retention period
 
InfluxDB shell version: 1.8.10
> use fritzbox
Using database fritzbox
> show retention policies
name    duration  shardGroupDuration replicaN default
----    --------  ------------------ -------- -------
90_days 2160h0m0s 24h0m0s            1        false
1year   8760h0m0s 24h0m0s            1        true

Also when I alter the retention policy and drop the "1year", it will come up again with the next restart.

It would be great, if you can take a look why this happens, so that I don't have to copy every time the data from 1year to my 90_days and alter the retention policy.

I am also irritated by the fact, that fritzinfluxdb discards data older than 01.12.2021. Where does they come from?

Best Regrads
Ronald

Hi @ronaldn1969

Thank you for this issue. This should not be default. But the script usually doesn't check the current retention period. I have to add a check for that.

The metrics which our older then your retention period are usually entries from your phone call log. They are stored with the timestampnthe call occurred. The FritzBox usually keeps call records for long period of time. This is nothing unusual but maybe I should add a hint to the log message.

Hey @ronaldn1969,

I added a change to the next-release branch. can you test if the behaviour still persists?

Thank you.

Hey @bb-Ricardo

looks good... dropped the 1year retention policy and set up a new database with 90 days and it is still there and default... No new 1year retention policy appeared.

thanks a lot!!

Great, thank you for testing.