Total reporting failure from set date

Every month, I use the monitor to generate me a few graphs with response times from URL checks. It's not the most reliable way to monitor response times of websites, of course, but it does give you a general idea.



Now, since I do this monthly, last reports generated by myself were from begin to end June. Today, I tried to generate begin to end July, but all graphs come out as blanks. The average, lowest, highest etc all come out as -1 (which cannot be displayed on the graphs). I'd love to believe my servers are performing so well that they're generating -1 ms response times, but I'm afraid we'd be breaking a few laws of physics.

This started for ALL url monitors from 30 June 23:30. They all go to -1. For other monitors they just don't show anything.



Anyhow, the monitoring software seems fine, since it correctly reports ups and downs I've triggered myself and the "Last Up" times are very recent. I've rebooted the computer running the app, but the reporting graphs still come out the same.



Is there something wrong with the way the database stores the figures (since it's a round robin database system with automated data consolidation, it might just have stopped going round )? But if it's a database issue, how can it still know when the last up was and correctly increment the total amount of checks?





Win XP Pro

ServersCheck 7.15.7

-1 means that there is no data recorder.



Make sure that the s-graphs.exe is running and verify that the graphs/queue subfolder is empty



You can also upgrade to the latest release 7.15.10



Optionally you can store data in an ODBC database where it stores the value at each monitor cycle. You can then use a BI tool to create custom graphs and link it to other data sources.

Yes, I gathered as much that -1 means no value (from past experience).

The graphs and graphs/queue folders are empty (with the exception of an empty .log file in graphs). s-graphs.exe is running (and I can generate graphs with old stored data).



I'll try to update today if I can fit it into the working schedule.



Any particular update procedures I should be aware of if I don't want to loose any settings or data between versions .7 and .10?

See knowledge base article on performing manual upgrade procedure.



If you have standard value graphs that are generated for those monitors, then the issue is your graph definition and not the data.

Updated per KB article, but reporting still doesn't work (backed up necessary files, uninstalled, rebooted, installed, rebooted again to be safe, started the services, tested the old config, seems to load correctly).

But even for new data from monitors that ran in a period after the upgrade it gives empty graphs. (waited for more than the prescribed 10 minutes before generating the Trend Analysis)



Graphs are generated by doing the following:

reporting -> trend analysis -> add an url monitor -> select 'value' -> select graph color -> input name fields -> select time range (or 'last x')



Comes out a blank graph with -1 values (null in this context). Same happens to Ping and other monitors.

Finally had time to get back on this issue.



Turns out that the reporting failure after the update wasn't due to no data being stored in the db, but rather because the prerequisite 10 minutes of data before being able to pull a trend analysis wasn't reached. I waited 10 minutes, but it seems that the monitoring_thread2.exe crashed after less time, thus not giving enough information for me to draw a report.

monitoring_thread2.exe crashed but did NOT restart (which it should, since the watcher process was active).



I've now had 2 instances since the previous post where I reboot the machine, monitoring picks up as expected and monitoring_thread2.exe crashes after the first round of checks (& doesn't restart). No error dialogue pops up, only an entry is added to the app log (the known perl58.dll issue). No AV is running on the machine, as stipulated by ServersCheck.



Software version is 7.15.10, as downloaded from your site last week.