Make logrotate configurable

[Apollon77]

Is your feature request related to a problem? Please describe.
I use nginx-proxy-manage rnow since 3 days and one logfile is already 6GB ... This is way too much.

I found #1140, but 1 weeks is simply looong ... I do not need that. a standard daily rotate for 7 days or such is completely sufficient for my usecase

Describe the solution you'd like
Allow lofgrotate settings to be configurable, at least the interval and generations

Describe alternatives you've considered
I thought about #183 (comment) but do not know if/how it interfers with the now integrated logrotate

I will for now increase storage, but I would like to see that only a temporary solution ...

[chaptergy]

If you want you can integrate new environment variables which generate a logrotate config on boot and create a PR for this.

You could also just mount a custom logrotate config into the container at /etc/logrotate.d/nginx-proxy-manager via your docker-compose. For reference, here is the current config.
However the logrotate binary is only called every two days, so that is the smalles possible rotation period possible without changing the source code.

[Apollon77]

@chaptergy I'm not experienced enough on docker side to make a PR and also for the other "mount custom config" I would need some more guidance ... sorry but in this regard I'm complete noob :-( ... every two days could work in general I think ... could you please provide an example on how to get that in via docker-compose?

[chaptergy]

Create a file on the machine running docker with your custom logrotate config. Then just add the following line to your docker-compose:

# version: "3"
# services:
#   app:
#     ...
#     volumes:
        - <path-to-your-config-file>:/etc/logrotate.d/nginx-proxy-manager
#     ...

The commented out lines are only there for reference so you know where to put it, the only relevant line to add is the uncommented one.

[Apollon77]

Ok, tried that for now, lets see how it goes. I will see in 2 days ... But I think allowing that to be configured would be a good idea or?!

[chaptergy]

Sure, its a good idea but I'm not really sure it would be worth the effort. The proxy would have to be very high traffic for the log to grow at this rate, and I think that's not the case for the vast majority of people. The goal of this project is to make it as simple as possible, and this comes at the cost of loosing flexibility.

Here is my calculation: a request in the access log is about 300 bytes in size (rounded up). That means to fill a gigabyte of storage, it would take 3.5 million requests (rounded down). A week has 604,800 seconds, so your proxy would have to answer about 6 requests per second (rounded up) for 24 hours a day to fill a gigabyte of disk space after a week. And if you have a proxy which has more than this amount of throughput it is most likely a production and public facing service. And I don't think services of this scale would want to loose all the flexibility you have to sacrifice when using npm. Even OpenStreetMaps, which is not small by any means, averages to 10-20 requests per second, and even wikipedia "only" has about 100 to 200 requests per second per server.

[Apollon77]

In our case it is mainly a "Sentry" Crash reporting service used in several adapters of the smart home system iobroker. Beside real crash reports it also collects "session" starts of users to allow statistics like "x% of your sessions was crash free" and these are not that less and yes it growed a lot recently. No idea how long that works, but even then is NPM a really cool and simpy solution and works like a charm.

Till now I used my Synology NAS as reverse proxy and ssl termination, but the CPU is not that powerful, so I moved it onto my Proxmox cluster ... and here we are :-)

[Encephala]

I also wanted to customise the logrotate functionality (I prefer rotating by filesize rather than by schedule) and found this issue. Agree with @chaptergy that mounting a custom logrotate file is the right solution here, but figured it'd be nice if the docs mentioned that too, hence #3422 :)

[Encephala]

Considering that PR got merged, I think this issue can be closed!