Kaseya Community

Monitor Logs, Trend Reporting, and SQL Servers!

This question is not answered

Hi Everyone, I'm looking for some possible tips or solutions to trend reporting on disk drives.  I've seen a few old topics on this but no actual solutions.

First, there is a legacy Monitor Trends report but this has some big limitations.  You can only specify one drive letter at a time and  a 90 day chart stretches sideways across multiple screen sizes (lots of scrolling).  From what I can see, this report really can't be edited or customized much and in the end it is really hard to read.

What I'd like to do is get this information into our SQL server so we can do our own reporting and trend analysis.  Either have Kaseya relay the monitoring data somehow, or have SQL read and upload the KLOGS folder CSV files.  Has anyone tried this angle before?  Any success?  Other ideas?

I'd appreciate any comments or solutions to this, Kaseya support thus far hasn't been able to assist much other than to point me to the legacy monitor trend report I mentioned.

Note: We are currently on Kaseya 6.5 but are actively testing Kaseya 7.0 including KNM.

All Replies
  • When are we going to be able to do decent disk trending report graphs?  There was an active thread from 4 years ago promising it.  

  • We developed our own solution for this in our Smart Monitor suite. The Disk Capacity smart monitor does a couple of things -

    Identifies all local drives larger than a specific threshold and NOT containing specific words in the volume label. This allows us to ignore things like recovery partitions. It also allows monitoring of mounted volumes, not just volumes assigned to a drive letter.

    The drive size is checked and a low space threshold calculated. Thus, every volume of every agent has a custom disk capacity threshold applied.

    When the threshold is crossed, the remediation (disk cleanup) script is run automatically, but no alert generated. This will often resolve the issue without any further action.

    If the threshold remains crossed for 3 days, or the threshold is exceeded by 85%, the alert is sent to Kaseya. If the space is cleared to above the threshold within the 3-day period, no alert is generated.

    The first time that the check runs each day (it runs hourly), it updates a 30-day trend dataset, and then projects the utilization from the past 30 days out 30 more days - if it expects to cross the alert threshold during the projected timespan, a warning level alert is triggered. The trend data is maintained locally, but it would be easy to upload it to Kaseya as a CSV string for reporting and further analysis, or even longer-term tracking. 30-day tracking was chosen for the warning as it provides enough time to cleanup or add storage without making the logic overly complicated.

    Glenn