ERROR: failure writing Metrics to Influx (points outside retention policy)

[Gill-Bates]

When Running Docker, I receive following error:

``INFO: Received exit signal SIGTERM...
INFO: Cancelling 4 outstanding tasks
INFO: Closed FritzBox TR-069 connection
INFO: Closed FritzBox Lua connection
INFO: Closed InfluxDB session
INFO: Successfully shutdown fritzinfluxdb
INFO: Starting fritzinfluxdb v1.2.4 (2024-10-15)
INFO: Successfully parsed config
INFO: Connection to InfluxDB v2.7.12 established and bucket is 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 AX (DSL) - FW: 8.2
INFO: Starting main loop
INFO: Service 'Cable Info (Fritz!OS 7.29 - latest)' not applicable for this FritzBox Model Link type 'DSL'
INFO: Service 'Cable Channel Info (Fritz!OS 7.58 - latest)' not applicable for this FritzBox Model Link type 'DSL'`

ERROR Message

ERROR: Failed to write to InfluxDB 'influx.example.com': 422: failure writing points to database: partial write: dropped 276 points outside retention policy of duration 8760h0m0s - oldest point fritzbox,box=fritz.box,uid=9d215d03e682ccbbfc2d5826b8346de0 at 2024-04-15T11:52:00Z dropped because it violates a Retention Policy Lower Bound at 2024-06-22T13:42:31.053084875Z, newest point fritzbox,box=fritz.box,uid=782a9608e242af92a74411cb4402dbee at 2024-06-16T12:20:00Z dropped because it violates a Retention Policy Lower Bound at 2024-06-22T13:42:31.053084875Z dropped=276 for database: 294264dce2933599 for retention policy: autogen

My Bucket Retention Period: 365 Days
Docker Timezone the same as my FritzBox.

I am wondering why the FritzBox is delivering Data older than 1 year?!

[bb-Ricardo]

Hi,

This might happen for entries in your phone log. Have a look at the oldest entries.

[Gill-Bates]

@bb-Ricardo Interesting. Wouldn't it be better if the script only sent data to Influx whose timestamp falls within the retention period?

[bb-Ricardo]

Hey,

Good point, no idea why I didn't implement it that way. I can't remember if you also get the retention period for that bucket when requesting if it exists.

[senpro-ingwersenk]

ISP updated a customer's box from 7.x to 8.x and subsequently had us update the image. Now we no longer get most metrics. x)

2025-07-02T12:19:28.619499000Z  ERROR: Failed to write to InfluxDB 'influxdb-de-01.ourcompany.tld': 422: failure writing points to database: partial write: dropped 14 points outside retention policy of duration 4320h0m0s - oldest point fritzbox,box=DSL1,uid=2ed382a97d7f1c71feccd36016df1754 at 2024-07-22T05:35:00Z dropped because it violates a Retention Policy Lower Bound at 2025-01-03T12:19:28.614929391Z, newest point fritzbox,box=DSL1,uid=112f92763c037f52552f1babac86799a at 2024-08-21T08:02:00Z dropped because it violates a Retention Policy Lower Bound at 2025-01-03T12:19:28.614929391Z dropped=14 for database: 3b899adac358d3f9 for retention policy: autogen

Still looking to just increase retention for the time being, but this will probably happen to several boxes over the coming weeks - and we do not have the biggest disks in our NAS x)

[bb-Ricardo]

ISP updated a customer's box from 7.x to 8.x and subsequently had us update the image. Now we no longer get most metrics. x)

2025-07-02T12:19:28.619499000Z  ERROR: Failed to write to InfluxDB 'influxdb-de-01.ourcompany.tld': 422: failure writing points to database: partial write: dropped 14 points outside retention policy of duration 4320h0m0s - oldest point fritzbox,box=DSL1,uid=2ed382a97d7f1c71feccd36016df1754 at 2024-07-22T05:35:00Z dropped because it violates a Retention Policy Lower Bound at 2025-01-03T12:19:28.614929391Z, newest point fritzbox,box=DSL1,uid=112f92763c037f52552f1babac86799a at 2024-08-21T08:02:00Z dropped because it violates a Retention Policy Lower Bound at 2025-01-03T12:19:28.614929391Z dropped=14 for database: 3b899adac358d3f9 for retention policy: autogen

Still looking to just increase retention for the time being, but this will probably happen to several boxes over the coming weeks - and we do not have the biggest disks in our NAS x)

Hi,

are you also using influxDB 2.X?

[senpro-ziegerl]

ISP updated a customer's box from 7.x to 8.x and subsequently had us update the image. Now we no longer get most metrics. x)

2025-07-02T12:19:28.619499000Z  ERROR: Failed to write to InfluxDB 'influxdb-de-01.ourcompany.tld': 422: failure writing points to database: partial write: dropped 14 points outside retention policy of duration 4320h0m0s - oldest point fritzbox,box=DSL1,uid=2ed382a97d7f1c71feccd36016df1754 at 2024-07-22T05:35:00Z dropped because it violates a Retention Policy Lower Bound at 2025-01-03T12:19:28.614929391Z, newest point fritzbox,box=DSL1,uid=112f92763c037f52552f1babac86799a at 2024-08-21T08:02:00Z dropped because it violates a Retention Policy Lower Bound at 2025-01-03T12:19:28.614929391Z dropped=14 for database: 3b899adac358d3f9 for retention policy: autogen

Still looking to just increase retention for the time being, but this will probably happen to several boxes over the coming weeks - and we do not have the biggest disks in our NAS x)

Hi,

are you also using influxDB 2.X?

my colleague is off this week so i'll respond for him - yes, we are using influxDB v2.7.12

[DanielH80]

Hi, I had the same problem, and it turned out to be a very old list of calls that hadn't been used. As the calls were from an old Fritzbox backup, they were way older than my retention policy. This also stopped all the other metrics from being written. I deleted the list of calls and it worked again.
This issue started happening after we updated to FritzOS 8.03.

[bb-Ricardo]

Thank you for the hint. It should discard old entries which are past the retention policy. Maybe there were some changes. Need to look into that.

[senpro-ingwersenk]

As a temporary workaround, we flatlined the call logs. Two entries, both way outside of the retention policy - and in fact, the only two. I also looked into the code but there was no method to just disable call log querying either. Hence why we just flatlined that log alltogether. And... so far, it works. But - that will only last so long untill other customers' boxes get updated as well and will perhaps need the same "fix"...

Anything I can help with, perhaps?

[Bond246]

Hello,

i've only a retention policy about 40 days.
So i have this problem every 1,2 months for call logs and also for system-events. If i reboot my Box within that time it lasts longer ;-)
My software version is 8.20.

Are there any ideas about it?

[bb-Ricardo]

sorry, have not looked into this. Still in my backlog