Sure, writing directly into syslog is only meant for those who don't want a log file. This has neither been possible so far nor will it become the default. I perfectly agree any debugging isn't meant to happen in this place.
I'm not sure I understand what you are doing exactly. You don't want to log directly into syslog but into the log file. Then you import this file into syslog? You set the tag in this case, like:
so I don't see the need for a pihole-FTL string in the pihole-FTL.log file as you specify the tag here.
is something I don't really understand because you still know from which file you are reading.
I checked but didn't find any other products having specific log files themselves (I checked apt, cups, mosquitto, and lighttpd on my local Pi-hole) mentioning which process is logging here. Why should they? Better not to create double content where users are mislead into using this - instead of a proper selector like the file you are reading from.
OK, I can live with that, maybe unbound is overdoing it...
I don't import the file (message) in syslog. What I'm doing is:
use imfile to instruct syslog to watch a log (that log, for example unbound.log contains all messages).
if the message contains error or warning, I use a syslog action to write the message to a separate file, this new file will thus only contain error and warning messages.
I use fswatch to monitor that new file (fswatch monitors all files in the target directory), as soon as the file changes, a script is triggered by fswatch, that reads the new message(s) and sends (socat) the message to a syslog server, running on an android tablet.
Not as good as push notifications, but the syslog screen on the tablet is always on, so I'm immediately notified if an error or warning occurs. This already helped me resolve some issues I never noticed before, example, SURICATA rules reload triggered unbound to restart. It isn't always beneficial (gpgconf)...
If something goes horribly wrong (I had this a few times), you get a few hundred mails. Tried it, not funny... The script I now use ensures this doesn't happen (consolidated mail if the syslog server isn't reachable - that's why I use socat, as opposed to nc, nc isn't always able to detect if the remote port is available).
Also tried omprog, this syslog feature doesn't always work (lots of omprog errors in the syslog).