Web Filtering Counter reports wrong information

Which version?

How many places, and where specifically, are you seeing questionable counts?

If you're not seeing all this activity in the Web Filtering Live Log, I fear you have something misconfigured.  Is this version 9.203-3?

Cheers - Bob

I can see all activity in the Live Log, but I dont see that in reporting and main dashboard. This is Version 203-3.

What happens if you try with Firefox instead of IE?  Is the correct information reflected in Logging & Reporting?

Cheers - Bob

Nope. Unfortunately not.

For 9.113-1 (I don't have 9.2xx handy) the number in the dashboard comes from /var/log/reporting/inline/dashboard.ph which I think is generated by /usr/local/bin/gen_inline_reporting_data.plx.

Compare (adjust for date as needed):

psql reporting -U reporting -c "SELECT sum(requests) FROM websecurity WHERE logday:[:D]ate = '2014-06-26';"

grep web_requests /var/log/reporting/inline/dashboard.ph

Note the dashboard is only updated every 15 minutes with a +2 minute offset (2, 17, 32 and 47) so there is likely a relatively small discrepancy between the "live" database results and the variably "stale" inline/dashboard number.

 loginuser@fw:/home/login > psql reporting -U reporting -c "SELECT sum(requests) FROM websecurity WHERE logday:[:D]ate = '2014-06-27';"
 sum
-----
 90
(1 row)

 loginuser@fw:/home/login > grep web_requests /var/log/reporting/inline/dashboard.ph
          'web_requests' => '90',

The question is: does /usr/local/bin/gen_inline_reporting_data.plx get data from http.log?

 loginuser@fw:/home/login > wc -l /var/log/http.log
338770 /var/log/http.log
 loginuser@fw:/home/login >

I stopped with 9.2 shortly after the beta licenses came to an end so my information is based on 9.1:

I think the inline reporting results comes (exclusively?) from the reporting database - debugging output seems a little inconsistent.

With such a small number (90 at that count) it might be worth reviewing the requests in the database:

psql reporting -U reporting -c "SELECT * FROM websecurity WHERE logday:[:D]ate = '2014-06-27';" | less -S

Depending upon your configuration various prior dates could be reviewed as well.

A synopsis of the websecurity reporting config, including retention  (cc requires root):

# cc get reporting | grep websecurity

How much do you care about any historical reporting data?  Enough to scour the database and system?  Do you primarily care for potentially better reliability on this UTM going forward?

It may be worth pursing a support case - though if it is "a corrupt reporting database" I don't know if they'll go beyond "rebuild the database" willingly.

Even if one gets no further a database rebuild with support it is potentially worth having the support case logged to make sure Sophos is not unaware of potential problems with reporting.

Vendors typically seem at least mildly more interested when concerns raised outside support can reference verifiable support cases.

I know little about the dashboard summary.  If I recall correctly it is done somewhat differently from other reports.

I think it's important to understand how deep the problem is.

Can you check the following four places and tell me whether you think the data is correct?
1) Dashboard "Web Filtering is active, x requests served today"
2) Web Protection summary page (top menu item)
3) Logging and Reporting, Web Protection, Sites report
4) /var/log/http.log

To answer a question above:  For web, the logging goes into syslog which splits it.  One stream goes into the reporting system and another into the log file.  Therefore the reporting system does not work "off of" the log file but gets the exact same data as the log file.

Now it works. I did not do anything. Suddenly it works. It shows now real Information...