System monitoring and reporting with Jenkins
having "ab"used Jenkins to be many things, the most sensible (IMHO) you can do is expose monitoring dashboards via build report page.
I think you should not even put Jenkins and monitoring under the same url, due to the "who will guard the guard" problem.

Also, nowadays monitoring tools are too versatile and have too many "faces" (a face for each characteristic user, and some specific users prefer to have their own personal "face" to monitoring)
About "reporting" I don't know what do you mean. if its reporting of builds statuses - READ ON.
Also there are other things to let user go through (logs, alerts, test reports)

So what I would suggest to address monitoring visibility is:


monitor your Jenkins in your monitoring :) (builds, statuses, etc.)
define monitoring url inside Jenkins (e.g. as Global Env Variable)
let's assume you have a job that deploys service $svc on environment $env. using Groovy you can generate:


generate a url to point at that monitoring service "dashboard" for that service in that env. let's call it serviceMonitorUrl
environmentMonitorUrl, and others
using addSummary and related stuff you can add to the build report a list of links to monitoring
you can decorate your build history column with "labels" pointing at branch, env, hash, whatever
your userdom will get build page with those links, and will be able to "click" them.



Having said that, there are Jenkins pipelines visualizations you can also use to visualize Jenkins jobs statuses, etc. e.g. this one.

Generally:
Jenkins is good for CI related scheduling.
But the truth is - CI should not be the focal point of users.
CI should be "transparent" until something is broken.
Thus making users "aware" of Jenkins (CI), and doing everything through it, unless business requirement is met by it (like company's product is being controlled/operated though Jenkins) - you should not do this. This kind of "knowledge" is not really serving the users.
They need to be able to see where to look for information easily, not be specific application's advanced users.

Think what happens when you decide to migrate from Jenkins to something else. you are hooked now.

(it isn't necessarily bad, just be aware of it)