search

mikaku / Monitorix

Monitorix is a free, open source, lightweight system monitoring tool.
https://www.monitorix.org
GNU General Public License v2.0
1.12k stars 167 forks source link

Missing Monthly Section in conf #11

Closed ethanpil closed 11 years ago

ethanpil commented 11 years ago

Hi,

I followed the basic instructions and installed RPM from rpm -ivh http://www.monitorix.org/monitorix-n.n.n-1.noarch.rpm

As I am going through my /etc/monitorix.conf and comparing to http://www.monitorix.org/documentation.html#33

I see you dont have the monthly section defined in the sample conf. I also checked the master repo conf file and its also missing.

Am I missing something?

Thanks for your great work.

mikaku commented 11 years ago

Hi,

The monthly section belongs to the traffact graph and it's enclosed in the subsection called <reports> as you can see bellow:

<traffacct>
        enabled = n
        max = 10
        graphs_per_row = 2
        list = pc101, pc102, pc103, pc104
        <desc>
                0 = 192.168.1.101/32, ace@example.com
                1 = 192.168.1.102/32, gene@example.com
                2 = 192.168.1.103/32, paul@example.com
                3 = 192.168.1.104/32, peter@example.com
        </desc>
        <reports>
                enabled = n
                language = en
                default_mail = root@localhost
                smtp_hostname = localhost
                from_address = noreply@example.com
        </reports>
        rigid = 0
        limit = 100
</traffacct>

Hope that helped you.

ethanpil commented 11 years ago

Ahh, i see now. The documentation format seems to imply that its its own section, as you have given it a heading equal to all of the other modules, I didnt realize it was a submodule. Thanks for the quick reply.

It seems you already have a mechanism for reporting, why not make a general module for monthly (weekly or daily) summary reports of all collected data?

mikaku commented 11 years ago

Yes, you're right. The format looked like it has it's own section because the level of the header is the same as the rest. I've made a little changes to help to the reader that monthly reports are part of the Traffic Accounting graph. Thanks for pointing this out.

Regarding your question, you mean a report of any value of any graph? can you elaborate a bit?

ethanpil commented 11 years ago

What I meant in my request was that currently you have a mechanism for monthly report for bandwidth (per our discussion above). You also have a mechanism for an alert based on a trigger condition (running a bash script when resources are at a certain level).

Personally I think both of these are extremely useful. However, what would make this the ultimate free tool is automated reporting. So, what I mean is since we have these values stored in the database, why not [optionally] send a monthy (or weekly, or daily) report with graphs to the admins email address.

Avg Min Max CPU Usage Avg Min Max Disk Free Avg Min Max Network Traffic Days etc etc.

It will help admin check the email and know if some issues are creeping up over time... (Set and forget!! :)))

What do you think about it?

mikaku commented 11 years ago

So, if I understand it correctly, what you suggest is to add a new feature to send automatically a (yearly, monthly, weekly and/or daily) graph of any of the services being monitored to an email address (or even a list of email addresses)?

ethanpil commented 11 years ago

Exactly.

Of course it would be nice to make everything configurable because many admins are picky about what and when to monitor as well as notifications.

I propose a configuration something like this in monitorix.conf which would allow me to configure reporting as I may need it depending on server. Does it make sense to you, if not I can explain more...

    # Email Reporting
    # -----------------------------------------------------------------------------

    <email_reports>

        #Global switch for all email reports
        enabled = y

        #The time to send the report emails
        email_time = 03:00

        to = email@domain.com, email2@domain.com, email3@domain.com
        subject = [title] - Monitorix Report for [period]

        <email_daily>   
            #Enable the daily email
            enable = y

            #Choose the graphs to include in the emails
            graphs = system, kern, proc, port, disk, apache, mysql, ftp

            #Also include basic log analysis below each graph
            avg = y #Show the average value for the period of this email (day)
            min = y #Show the highest value and date/time for the period of this email (day)
            max = y #Show the lowest value and date/time for the period of this email (day)
            compare_previous = y #Show a comparison of above values to the previous period (yesterday)                  
        </email_daily>

        <email_weekly>

            enable = y
            graphs = system, kern, proc, port, disk, apache, mysql, ftp

            avg = y #Show the average value for the period of this email (week)
            min = y #Show the highest value and date/time for the period of this email (week)
            max = y #Show the lowest value and date/time for the period of this email (week)
            compare_previous = y #Show a comparison of above values to the previous period (last week)
        </email_weekly>

        <email_monthly>
            enable = y
            graphs = system, kern, proc, port, disk, apache, mysql, ftp

            avg = y 
            min = y
            max = y
            compare_previous = y #Show a comparison of above values to the previous period (last month)         
        </email_monthly>

        <email_yearly>
            enable = y
            graphs = system, kern, proc, port, disk, apache, mysql, ftp

            avg = y
            min = y
            max = y
            compare_previous = y #Show a comparison of above values to the previous period (last year)      
        </email_yearly> 
    </email_reports>
mikaku commented 11 years ago

Well, I think that the idea is fine but I still have some parts that either I don't understand or doesn't make sense to me.

#The time to send the report emails
email_time = 03:00

That option is also valid for weekly and monthly reports? and what would be the right week-day and month-day to send their corresponding reports?

subject = [title] - Monitorix Report for [period] Assuming that a report could contain different graphs, what would be the title?

#Choose the graphs to include in the emails
graphs = system, kern, proc, port, disk, apache, mysql, ftp

Besides the fact that each email would have a considerable size, you won't have the zoom feature to see a more detailed view, so in some circumstances, you'd still end up browsing directly to the remote server.

#Also include basic log analysis below each graph
avg = y #Show the average value for the period of this email (day)
min = y #Show the highest value and date/time for the period of this email (day)
max = y #Show the lowest value and date/time for the period of this email (day)

I definitively don't understand this. Most graphs already have these values in their own legend. Moreover, the graphs are generated in a static way in their corresponding Perl module, meaning that it's not possible to change how they appear. Changing that would indeed represent a major change in Monitorix.

compare_previous = y #Show a comparison of above values to the previous period (last week) Same as above, graphs are generated statically so they aren't able to include on-demand values. Changing that would also indeed represent a major change in Monitorix.

In all, I think that the idea is not bad for passive sysadmins who prefer receiving selected graphs instead of browsing to the servers every day/week/month. If that's the objective, of course.

ethanpil commented 11 years ago

That option is also valid for weekly and monthly reports? and what would be the right week-day and month-day to send their corresponding reports?

Yes, its just to determine what time of day all of the automated emails are sent. It can help with offset if the server timezone is different from the user's timezone and also if some people are particular about what time they want the report email...

Assuming that a report could contain different graphs, what would be the title?

I was thinking that this is the same as the [title] as set at the top of monitorix.conf

Besides the fact that each email would have a considerable size, you won't have the zoom feature to see a more detailed view, so in some circumstances, you'd still end up browsing directly to the remote server.

I dont think zoom is important in the emails. We can set the image size a bit larger (maybe 600 or 800 pixels wide) and if the admin wants to see more details he will just login to the console. Its not for interactive data, just a quick summary.

I definitively don't understand this. Most graphs already have these values in their own legend. Moreover, the graphs are generated in a static way in their corresponding Perl module, meaning that it's not possible to change how they appear. Changing that would indeed represent a major change in Monitorix.

If its in the legend then I guess its not important here. I just figured that the script could easily query the DB and add these values as text below or above the graph in the body of the email. But even just the graphs would be quite useful without the text...

Same as above, graphs are generated statically so they aren't able to include on-demand values. Changing that would also indeed represent a major change in Monitorix.

Again, I thought it can be a simple query from the DB and static text in the email... If its not too much work.

In all, I think that the idea is not bad for passive sysadmins who prefer receiving selected graphs instead of browsing to the servers every day/week/month. If that's the objective, of course.

Exactly. I think many people (myself included) run their servers this way. Maybe its not the best way, but based on time and resources it is often the only possible way.

I think Monitorix is one of the best and easiest systems to setup. Its very flexible and isnt bloated with tons of useless modules for the basic system admin (unlike cactus, nagios, etc).

This suggestion, IMHO, would make it indispensable for me.

mikaku commented 11 years ago

I'm currently working introducing restricted access in the built-in HTTP server, once I've concluded this part I'll start taking in consideration your idea.

Stay tuned in case I need some things to discuss with your. Many thanks.

ethanpil commented 11 years ago

Thanks for considering this. Please let me know if I can help. Although I am not a Perl expert, maybe I can try to help if you would like.

mikaku commented 11 years ago

ethanpil,

I've committed a first implementation of your 'Email Reports' suggestion which includes the following new options in the monitorix.conf file:

# Email Reports
# -----------------------------------------------------------------------------
<emailreports>
        enabled = n
        url_prefix = http://localhost:8080
        smtp_hostname = localhost
        from_address = noreply@example.com
        <daily>
                enabled = n
                graphs = system, fs
                to = ace@example.com
        </daily>
        <weekly>
                enabled = n
                graphs = system, fs
                to = gene@example.com
        </weekly>
        <monthly>
                enabled = n
                graphs = system, fs
                to = paul@example.com
        </monthly>
        <yearly>
                enabled = n
                graphs = system, fs
                to = peter@example.com
        </yearly>
</emailreports>

As you can see it includes some global and some per-timeframe options which makes it easy to choose different types of configurations.

The reports are sent based on this:

Right now only daily reports are working, the rest will be developed in the next commits. Please, test this new feature downloading the devel branch and let me know if you miss something.