pi-hole / FTL

The Pi-hole FTL engine
https://pi-hole.net
Other
1.34k stars 187 forks source link

Improve Query Log suggestions #2001

Open DL6ER opened 6 days ago

DL6ER commented 6 days ago

What does this implement/fix?

Implement actual TOP suggestions for the Query Log by ensuring the most relevant domains and clients are returned (sorted by the most active being at the top) by the API /api/queries/suggestions endpoint. The result of this is used in the dropdown menus on the Query Log Advanced Filtering box:

image


Related issue or feature (if applicable): Discourse

Pull request in docs with documentation (if applicable): N/A


By submitting this pull request, I confirm the following:

  1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
  2. I have commented my proposed changes within the code.
  3. I am willing to help maintain this change if there are issues with it later.
  4. It is compatible with the EUPL 1.2 license
  5. I have squashed any insignificant commits. (git rebase)

Checklist:

pralor-bot commented 6 days ago

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/unable-to-select-correct-client-by-name-in-advanced-filter/70863/20

DL6ER commented 4 days ago

Confirmed working by OP on Discourse

DL6ER commented 2 days ago

But I think it should return both top allowed and top blocked domains.

Yes, we can make this return, e.g. 30 top permitted and 30 top blocked domains just to populate the dropdown.

maybe we could instead re-use the data we have for the top domains already (/stats/top_domain) and use those as suggestions instead?

This endpoint still uses the internal data structure and does not use the database. On the one hand, this data is already pre-processed and accessing it is fast, on the other hand, accessing this data blocks DNS resolution during the time it is accessed and is not very flexible. I will think about this, maybe we just don't need any flexibility here.