Open xavier-hernandez opened 11 months ago
Based on the feature request above, just another idea for possible future features...
Maybe a new environment variable could be introduced, with a name like LOG_SCOPE
. That would allow the user to compose the log scope (for systems that support that) to be composed of separate arguments.
So LOG_TYPE
would only define the type of logs - but LOG_SCOPE
would define which log files are included, and which "routes" (like "/redirection" ) will be generated.
For example:
The user sets the LOG_TYPE
= NPM
. That only implies we are dealing with NPM-style logs.
The user can then set LOG_SCOPE
to any of the following, since the value is composed of flags for an NPM system:
A
= "A"ccess logs, aggregated. It makes an /access
route available. (Works like the current NPM
LOG_TYPE.) E
= "E"rror logs, aggregated. It makes an /error
route available. (Works like current NPM+ALL
LOG_TYPE, but without redirection logs.)R
= "R"edirection logs, aggregated. It makes a /redirection
route available. (Works like the current NPM+ALL
LOG_TYPE, but without error logs.) a
= "a"ccess logs, separate per host. It makes an /access-n
route(s) available, e.g. access-42
for the access logs of host with id of 42. Also generates /access-fallback
for the error logs of the NPM fallback host.e
= "e"rror logs, separate per host. It makes an /error-n
route(s) available, e.g. error-42
for the error logs of host with id of 42. Also generates /error-fallback
for the error logs of the NPM fallback host.r
= "r"edirection logs, separate per host. It makes an /redirection-n
route(s) available, e.g. redirection-42
for the redirection logs of redirection-host with id of 42. So, then the user can set LOG_SCOPE
to any combination of flags such as:
LOG_SCOPE
= A
(the same as the current NPM
setting)LOG_SCOPE
= A,R
(the current NPM+R
setting)LOG_SCOPE
= A,R,E
(the current NPM+ALL
setting)LOG_SCOPE
= a,E
(separate access logs per host - but just one aggregate error logs report)A
, R
, E
, a
, r
, e
That would give users complete control of which logs get processed (for NPM, at least).
@xavier-hernandez Hello, I think you mentioned a while ago that you had a chance to implement some of this (I think you mentioned it in the Discussions).
Have you made a release with a similar feature yet, or maybe have another repo available that I can test?
@wernerm currently there is nothing that divides it up like your asking but I'll look into what you're asking. Creating that LOG_SCOPE for A,R,E shouldn't be that difficult however separating them would. I'm not sure who that would impact a PC though :) running all those instances.
@wernerm I can spinoff a branch/tag for you test if you'd like. We can see how it turns out?
@wernerm I can spinoff a branch/tag for you test if you'd like. We can see how it turns out?
Hi @xavier-hernandez that is a good idea, if you can find the time. We will help test it!
@wernerm currently there is nothing that divides it up like your asking but I'll look into what you're asking. Creating that LOG_SCOPE for A,R,E shouldn't be that difficult however separating them would. I'm not sure who that would impact a PC though :) running all those instances.
Well, the "A","R","E" would work almost like the existing options, just including or excluding some log types. So it's just more specific.
However, yes, I totally agree that the proposed things like "a","r","e" could get intense if there are many busy hosts... Maybe something like "host filters" could be introduced, but that would complicate things even more... (Where does one stop the madness? Everyone will need to read the README
more carefully :) ) On the other hand that's the nice thing - the end-user can decide how to configure the instances and what options to choose to enable, depending on their deployment scenario? (The new options we propose should exactly give more fine-grained control in some instances).
Discussed in https://github.com/xavier-hernandez/goaccess-for-nginxproxymanager/discussions/161