Go to the table of contents Go to the previous page Go to the next page View or print as PDF
Web Security Log Server Troubleshooting Guide : Incorrect or missing data in Web Security reports
Incorrect or missing data in Web Security reports
Topic 50305 | Web Security Solutions | Updated 19-Sept-2013
If Log Server is installed and the Log Database was created successfully, but reports contain no data or no recent data, use the following steps to identify and address the problem:
*
*
*
*
Make sure Filtering Service is sending data
Log Server receives Internet usage data from Filtering Service. If there are problems with Filtering Service, data is not sent, and log records cannot be created.
1.
*
Windows: Use the Services dialog box (Start > Administrative Tools > Services) to verify that Websense Filtering Service is Started.
*
Linux: Use the /opt/Websense/WebsenseDaemonControl command to make sure that Filtering Service is running.
2.
Go to the Settings > General > Logging page in TRITON - Web Security and click Check Status to verify that Log Serveris listening at the specified IP address or hostname, and on the specified port.
If the status check fails:
*
Verify the Log Server IP address or hostname and port values. The values on the Settings > General > Logging page must match those on the Settings > Reporting > Log Server page.
*
*
netstat -ban > port.txt
Open port.txt and find LogServer.exe in the list. The logging port should be listed.
*
Use a utility like telnet or ping to verify that the Log Server and Filtering Service machines can communicate.
3.
If all of the following are true:
a.
b.
c.
Stop Websense Network Agent. If Log Server begins to receive Internet usage data, port spanning was not configured in your network, or port spanning was interrupted. See the Deployment and Installation Center for information about how to position Network Agent in your network.
4.
*
*
Look for problems on the Log Server machine
Log Server receives information from Filtering Service and stores it in temporary files before sending it to the Log Database. Problems on the Log Server machine can interfere with that process.
First, monitor the cache or BCP folder on the Log Server machine (C:\Program Files or Program Files (x86)\Websense\Web Security\bin\Cache or bin\Cache\BCP, by default) to verify that temporary files are being created. If temporary files are being created and processed normally, files appear in the directory only briefly before the data is processed into the Log Database and the temporary file is deleted.
If temporary files are not being created, and there are no problems with Filtering Service communcation:
1.
Verify that the Log Server IP address or hostname and port values on the Settings > General > Logging page are correct and match the IP address or hostname and port values shown on the Settings > Reporting > Log Server page.
*
*
2.
3.
a.
Navigate to the Websense bin directory on the Log Server machine (C:\Program Files (x86)\Websense\Web Security\bin, by default).
b.
Right-click the LogServer.exe file and select Properties.
c.
Select the Details tab, and verify that the Product Version matches your current Websense product version. Find current version information on the Help > About the TRITON Console page in the TRITON console.
4.
Check the file paths set up for cache and BCP files on the Settings > Reporting > Log Server page in TRITON - Web Security to make sure the folders exist, and that Log Server has permission to write to them.
5.
If Log Server is creating temporary files, but data is not being processed and sent to the Log Database:
1.
If Log Server has been configured to use BCP insertion, go to the Settings > Reporting > Log Server page in TRITON - Web Security and change the insertion method to ODBC.
This issue may occur if bcp.exe or one of its support files has been removed from the system. Correct the problem with bcp.exe to restore the ability to use BCP insertion.
2.
3.
4.
Make sure there is only one copy of BCP.exe on the Log Server machine.
5.
If the Websense Log Server service is listed as Started in the Windows Services dialog box, and the alert "Service was not found" appears, follow the steps listed in Web Security Log Server and Windows registration.
Check for Log Database problems
Some of the troubleshooting steps make changes to the Log Database. Back up the database before proceeding.
After backing up the database:
1.
*
Remember to change the File Path entries on the Settings > Reporting > Log Database page if this process changes the database location.
*
Use the Settings > Reporting > Log Database page in TRITON - Web Security to delete or move older partitions. To do this, scroll to Available Partitions, mark each partition to be deleted and click Delete.
Contact your Database Administrator or IT department if you want to keep the partitions but need to move them to free up disk space.
*
*
Make sure tempdb is not full. Tempdb filling up is often a symptom of other SQL Server problems. Check for SQL Server errors about tempdb to resolve the underlying issue. Once the issue is resolved, ask your Database Administrator or IT department to stop and restart the Microsoft SQL Server services to clear tempdb. (If the underlying issue is not resolved, tempdb may grow again very quickly.)
Be sure to determine the impact to other applicatinos before restarting SQL Server services.
2.
If you are using Microsoft SQL Server Standard or Enterprise, make sure the SQL Server Agent service is running for the database instance that hosts the Log Database.
3.
4.
*
The initial size (Init Size field value) for the data and log files (set on the Settings > Reporting > Log Database page) is not greater than maximum size set by your Database Administrator.
*
The File Path entries for the data and log files on the Settings > Reporting > Log Database page is correct and the folders exist.
*
5.
6.
7.
*
*
Database jobs are not running
If the ETL job (Websense_ETL_Job_wslogdb70) is not running:
1.
If the "suspect" flag appears, notify your Database Administrator or IT department and request that data and disk recovery be performed, if necessary. When the recovery process is complete, start the ETL job.
2.
Use SQL Management Studio to see if records exist in the dbo.incomingbuffer table under wslogdb70.
If there are records in dbo.incomingbuffer:
a.
Locate the dbo.wse_etl_config table.
b.
Right click the table name and select Edit top 200 rows or Select top 1000 rows.
c.
Check the value under max_buffer_size. If the value is negative, revert it to a positive value.
If the trend job (Websense_Trend_DRIVER_wslogdb70) is not running:
1.
Make sure you have enabled trend data retention on the Settings > Reporting > Log Database page in TRITON - Web Security.
2.
3.
Database jobs running, but an error appears
The error "Could not obtain information about Windows NT group/user 'server\admininstrator'" indicates a problem with the account that owns the Microsoft SQL Server jobs. If the jobs are running as a user other than the account used by the ODBC connection, there may be a problem authenticating the user.
To find out which account is used to run the database jobs in SQL Server Standard or Enterprise:
1.
2.
3.
4.
Refer to the instructions for your SQL Server version to change the owner of all Websense jobs to the trusted account used by the Websense ODBC connection (Log Server) or a standard SQL Server user (like sa).
Run Log Server in debug mode
If you are having issues with Log Server and are not able to identify or correct the problem using the steps offered in this guide, run the Log Server service in debug mode to collect additional information.
1.
2.
Locate Websense Log Server service.
3.
4.
5.
6.
Click Start, then close the Properties window.
Log Server starts and creates the file debug.txt in the Websense bin directory (C:\Program Files (x86)\Websense\Web Security\bin, by default). Log Server writes tracing data to the file. Open debug.txt in a text editor for information about any issues Log Server encounters as it starts and run.
If the problem is that Log Server continues to stop, the last entry of the file generally indicates the point of failure.
The debug.txt file can become very large if Log Server is left to run in debug mode. When you have finished troubleshooting your Log Server issue, Use the Windows Services dialog box to once again stop the service. Remove the "-debug" parameter, then start the service again.
Stopping and restarting Log Server does not remove an existing debug.txt file.

Go to the table of contents Go to the previous page Go to the next page View or print as PDF
Web Security Log Server Troubleshooting Guide : Incorrect or missing data in Web Security reports
Copyright 2016 Forcepoint LLC. All rights reserved.