Prepare for Monitoring with Prometheus

[cimnine]

Related Issue: n/a

New Behavior

Adds the foundations for monitoring with Prometheus, which is the built-in monitoring solution for Netbox.
The complete setup does not ship by default and has to be configuration by the user.
Such a system configuration is now documented in our wiki: https://github.com/netbox-community/netbox-docker/wiki/Monitoring.

Contrast to Current Behavior

Some files have to be overwritten (i.e. gunicorn_config.py and nginx.conf) in order to get proper monitoring ready.
This functionality is now backed-in and ready to be used.

Discussion: Benefits and Drawbacks

The main question is: Do we want to take on the additional maintenance work?

By moving most of the components to the wiki they are no longer part of the main distribution.
Therefore we don't have to maintain and test the monitoring as part of our release process.

Changes to the Wiki

A new page has been set-up: https://github.com/netbox-community/netbox-docker/wiki/Monitoring

Proposed Release Note Entry

Preparations for Monitoring with Prometheus #344

This project does now contain all changes that would be necessary to monitor Netbox Docker using Prometheus.
See https://github.com/netbox-community/netbox-docker/wiki/Monitoring for a sample setup.

Double Check

• I have read the comments and followed the PR template.
• I have explained my PR according to the information in the comments.
• My PR targets the develop branch.

[madnutter56]

I think that this somewhat reduces the value of this repository, in that it turns on prometheus/grafana by default. Environments that already have monitoring infrastructure set up and scaled will have issues with this setup, and there's no good way to override the extra stuff in compose.override.

I would suggest having override templates that include the additional containers to enable this, but not enabling it in the default compose.

[cimnine]

Thank you for your feedback @madnutter56. What do you think of adding these services in an additional docker-compose file, like docker-compose.monitoring.yml instead of the main docker-compose.yml?

One could then start the monitoring part separately, like docker-compose -f docker-compose.monitoring.yml up
Or if one wants to start everything together docker-compose -f docker-compose.yml -f docker-compose.monitoring.yml up would work.

[madnutter56]

Part of me wonders if it should be a separate repository entirely? Running the service and monitoring are distinctly different services after all. I'm not sure though, I think multiple compose files seems like a reasonable workaround.

[cimnine]

I think finally I'll just keep the changes to the nginx configuration in this PR and move everything else to a new wiki page.

[cimnine]

The scope of this PR was reduced. Most of the cleverness was moved to https://github.com/netbox-community/netbox-docker/wiki/Monitoring. The PR description was updated accordingly.

[tobiasge]

I would squash those commit, because I don't think the commit history is important in our develop / release branches.
Otherwise it good to merge.