Protocol / Query log / Statistics - recommended history duration?

[Michel-0]

Hi there,

first off - i want to say a big thanks to the whole AdGuard team for developing and publishing such a great product!
As a friend told me about it i first said no way such a thing exists - installed it immediately on my raspberry and since then totally amazed about it.

Back on topic - there are 2 configuration settings i'm a little confused about.
On the Web UI they're called "Log configuration" and "Statistics configuration".
In the AdGuardHome.yaml they might be called statistics_interval and querylog_<...>, aren't they?

First thing i'm confused about is the default query log configuration beeing set to 90 days.
It seems to be saved to a uncompressed JSON file ./data/querylog.json?
My system is running now for ~1 day. The current usage extrapolated up to 90 days would be ~1,200,000 data entries in a ~450MB JSON file...?
That sounds completely unprocessable / unhandleable / simply too big for a raspberry with 1GB RAM and quad-core 900MHz CPU?

• Why didn't you guys decide to use a database-type storage?
  Like SQLite or maybe provide a MySQL interface? Is something like that planned?
• What if i turn querylog_file_enabled to false?
  This github wiki doesn't say anything about that - where does it get saved then?
• What if the file gets bigger than querylog_size_memory?
  Can AdGuard handle this and split it up in parts or even separate JSON files or something?
• What if the query log is smaller than the statistics log?
  Are the statistics calculated based on the query log so query log must always be greater or equal to the statistics log?

I tend to simply set statistics = 2d and query = 1d...

Keep up the good work,
kind regards,

Michel-0

AdGuard Home Version: v0.106.3
Raspberry PI 2 Model B v1.1
Raspbian GNU/Linux 11 (bullseye) Kernel: Linux 5.10.63-v7+
Setup as DNS server for my DSL Router
Used for installation: AdGuardHome_linux_armv7.tar.gz

[ainar-g]

Hello. You're basically enumerating reasons why we are planning to replace the current query log storage with a better one in the nearest future, heh. See #2290. Custom log sizes are also on the roadmap, once this is done.

[Michel-0]

Hello. You're basically enumerating reasons why we are planning to replace the current query log storage with a better one in the nearest future, heh. See #2290. Custom log sizes are also on the roadmap, once this is done.

Thanks for the clarification, can't wait to see what you guys will come up with.

If you decide to use SQLite, please also consider an optional, configurable MySQL interface.