Monitorix
Monitorix copied to clipboard
mikaku
Send e-mail report even if monitorix was not running at time specified
Monitorix is mostly running on my desktop systems and laptops to keep track of the resource usage. Only couple of these systems are running 24/7, yet - I would like to receive weekly/monthly report for each of them. It is my understanding that if I have a monthly report configured I would only get the report if the monitored system was up on the first day of month and time configured in the config file which could be a challenge for systems used only sporadically.
Thinking about it.. maybe an option to generate and send reports independently as a one-shot task would be a great help here. Then I could set up arbitrary schedule via systemd timers for instance or as part of the init scripts.
If you want to get a complete graph of the last month, that is from day 1 until day 30/31, you must generate such graph on day 1 of the current month, otherwise you'll get the graph of the last month starting counting from the day when you generated it.
As you can see in monitorix line 843, the parameter 1month is used in emailreports.pm in line 102 to generate the graph.
I understand your problem, but I don't see a way to generate a complete graph of a very past month. The time frames created by Monitorix are hourly (optional), daily, weekly, monthly, yearly, and optionally 2 years, 3 years, etc. If you try to render a graph out from these time frames you'll get a graph with squared values and very inaccurate.
For instance, try to generate a graph of the past two days with http://localhost:8080/monitorix-cgi/monitorix.cgi?mode=localhost&graph=_system1&when=2day&color=black, and you'll see what I meant.
Frankly, the "last 30 days" graph would be more than enough for my needs. With desktop systems not running 24/7 it's not really important to have it aligned to the first day of month. As I mentioned above perhaps the option to generate and e-mail reports via a HTTP call would be all that is needed and I could do the rest only with a help of a simple shell script + systemd timers (with OnUnitActiveSec directive)
As I mentioned above perhaps the option to generate and e-mail reports via a HTTP call would be all that is needed
Yes, the URL could be something like http://localhost:8080/monitorix/emailreports. The problem with this solution is that some one that guessed this is enabled in your server might abuse it.
I guess this would need two extra options in <emailreports> called hosts_allow and hosts_deny.
Abused in sense that (s)he could spam your e-mail with unnecessary reports? Then perhaps the return of http://localhost:8080/monitorix/emailreports could not be the action (= sent email) but a MIME-formatted e-mail. It would be the responsibility of the caller to forward the message wherever needed (e. g. via sendmail RECIPIENT < email-report)
Then perhaps the return of http://localhost:8080/monitorix/emailreports could not be the action (= sent email) but a MIME- formatted e-mail.
No, nobody expects to receive a MIME-formatted e-mail as a return of a URL.
I need to think more on this...
Perhaps a signal sent to Monitorix could be like a trigger to generate the report. I mean, I could create a new option called on_sigusr1 and you can define it like this on_sigusr1 = monthly. So it means that when Monitorix receives the USR1 signal it will generate a monthly report.
No, nobody expects to receive a MIME-formatted e-mail as a return of a URL.
If it's just that: return JSON with the proper fields to turn it into an email. Basially (very much abstracted):
{
'header': '<header part of the mail>',
'body': <the report>
}
Expecting an URL returning JSON? Plenty of examples :rofl:
Expecting an URL returning JSON?
That's another story.
You mean that Monitorix should return a complete email which includes all the headers and the graphs in PNG converted to Base64?
Don't get me wrong, I'm just asking. :smiley:
You mean that Monitorix should return a complete email which includes all the headers and the graphs in PNG converted to Base64?
Nah, I think that is not a good idea either. Maybe this should be treated a special case and therefore we should assume there is a shell account on the server which can call perl directly. emailreports.pm would then be split into 2 modules - one generating the e-mail message and sending it to stdout in MIME format, the other one doing the actual delivery.
This would give an advanced user to generate e-mail reports independently of the main schedule, send to different e-mail addresses/groups etc. Does that sound reasonable?
You mean that Monitorix should return a complete email which includes all the headers and the graphs in PNG converted to Base64?
:scream: :zipper_mouth_face: :dash:
As stated in the documentation of Perl MIME::Lite, I can write the whole message (or even the body only) to a file. I think that this could be added to the current option method, so it would also accept a path to a file, like this:
method = /path/to/file.eml
But I'm not sure if saving a complete formatted email to a file is useful for later sending it. I mean, what type of tool do you would use to send a .eml file?
The user @khcassidy just opened a new issue with the same feature request, and that made me think that I completely forgot to implement all this. Sorry for that.
I'll try to work on this in the next days.
But I'm not sure if saving a complete formatted email to a file is useful for later sending it. I mean, what type of tool do you would use to send a
.emlfile?
Couple ways are mentioned at https://stackoverflow.com/questions/1306115/send-eml-files-saved-on-disk
@jose1711
Thinking about it.. maybe an option to generate and send reports independently as a one-shot task would be a great help here. Then I could set up arbitrary schedule via systemd timers for instance or as part of the init scripts.
I'll focus on the one-shot solution as it seems more natural to me, and also it will cover the current requests.
We can explore the .eml case in the future.
This last commit adds the one-shot solution to send email reports at any time. You don't need to stop your current Monitorix instance, just execute a new one with the new parameter -e and once the job is done it will terminate itself.
The following is an example to force emailreports.pm module to send an email without schedule. You must need to have configured this module previously.
# monitorix -c <path/to/your/config.conf> -e report=daily,graphs=system+kern+hptemp,[email protected]
Let me know if it works as expected.
Alternatively, you might consider apply the recent commits 50757dd and 8a4c7e4 that fixes emailreports.pm to support the CSS white theme.
Hi Mikaku, This works perfectly. I have to apply the additional fixes too. Thanks a lot for this feature.