Technical Library | Support

Go to the table of contents Go to the previous page Go to the next page View or print as PDF
Log Server Troubleshooting Guide : Incorrect or missing data in reports
Incorrect or missing data in reports
Web Protection Solutions, v8.2.x, v8.3.x | 10-Dec-2016
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
*
Look for problems on the Log Server machine
*
Check for Log Database problems
*
Run Log Server in debug mode
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.
Make sure that Filtering Service is running.
*
Windows: Use the Services tool (Start > Administrative Tools > Services or Server Manager > 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 the Web module of the TRITON Manager and click Check Status to verify that Log Server is 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.
*
Make sure no firewall is blocking the port (55805, by default).
*
Open a Windows Command Prompt or PowerShell on the Log Server machine and run the following command to verify that Log Server is listening on the port:
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.
Verify that Content Gateway, Network Agent, or a third-party integration product has been properly configured to communicate with Filtering Service, and that Internet traffic is being seen.
If all of the following are true:
a.
You have either deployed TRITON AP-WEB or integrated Web Filter & Security with a third-party product.
b.
Users requests are being managed correctly.
c.
No records are being sent to Log Server.
Stop 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 Network Agent Quick Start paper for information about how to position Network Agent in your network.
4.
Make sure that Filtering Service is associated with a Policy Server that has its own Log Server instance (is configured for logging), and that data is not being diverted to the TestLogServer utility for troubleshooting purposes.
*
In Web module of the TRITON Manager, make sure the expected Policy Server IP address appears in the toolbar, and that there is no alert indicating that no Log Server is installed for the Policy Server.
*
If TestLogServer has been started, make sure it has been set up to forward records to Log Server. (See Using TestLogServe r for Troubleshooting for more information.)
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\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 communication:
1.
In the Web module of the TRITON Manager, 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.
*
If your deployment includes appliances, the Log Server IP address must be used.
*
Make sure that the actual IP address appears, and not 127.0.0.1.
2.
Check for firewalls that might be blocking the logging port (55805, by default).
3.
Make sure the Log Server executable version is correct:
a.
Navigate to the bin directory on the Log Server machine (C:\Program Files\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 web protection product version. Find current version information on the Help > About TRITON Manager page in the TRITON Manager.
4.
Check the file paths set up for cache and BCP files on the Settings > Reporting > Log Server page to make sure the folders exist, and that Log Server has permission to write to them.
5.
If TestLogServer is being used, make sure it is set up to forward data to Log Server. (See Using TestLogSe rver forTroubleshooting for more information.)
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 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.
If the Log Database was installed using Windows Authentication, make sure Log Server is running as a trusted user.
3.
Make sure no other applications, such as antivirus software, a backup utility, or log file analyzers, are running that might be locking the temporary files.
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 tool, and the alert "Service was not found" appears, follow the steps listed in 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.
Make sure that there is enough disk space for the ETL (Extract, Transfer, and Load) job to create a new standard logging partition when rollover conditions occur.
*
If necessary, add additional disk space to the machine.
Remember to change the File Path entries on the Settings > Reporting > Log Database page in the Web module of the TRITON Manager if this process changes the database location.
*
Use the Settings > Reporting > Log Database page 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.
*
As a temporary fix, until more disk space can be added, shrink all standard logging partitions except the current active partition. This does impact reporting speed.
*
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 applications 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.
Verify that the ETL job has the correct SQL Server permissions to create the database (see Log Database permissions.
4.
In order to ensure that the ETL job can create a new standard logging partition make sure that:
*
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.
*
The SQL Server service instance hosting the Log Database has write permissions on the File Path folders.
5.
Verify that there is at least one current, active partition (a partition neither disabled nor marked for deletion) listed on the Settings > Reporting > Log Database page.
6.
Make sure there are no other processes running that use significant resources (such as an antivirus scan).
7.
If you are using Microsoft SQL Server Standard or Enterprise, verify that the SQL Agent jobs (Websense_AMT_ETL_wslogdb70, Websense_ETL_Job_wslogdb70, Websense_IBT_DRIVER_wslogdb70, Websense_Maintenance_Job_wslogdb70, and Websense_Trend_DRIVER_wslogdb7) exist and are running.
*
If one or more jobs is not running, see Database jobs are not running.
*
If the jobs are running, but the error "Could not obtain information about Windows NT group/user 'server\admininstrator'" appears, see Database jobs are running, but an error appears.
Database jobs are not running
If the ETL job (Websense_ETL_Job_wslogdb70) is not running:
1.
Use SQL Server Management Studio to make sure the current, active logging partition is not flagged as "suspect."
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 Web > Settings > Reporting > Log Database page.
2.
Verify that the retention values are not all zero.
3.
Make sure the trend job has the correct SQL Server permissions to update the database. (See Log Database permissions.)
Database jobs are 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.
Log on to SQL Server Management Studio.
2.
Expand the SQL Serer Agent tree.
3.
Right-click a web protection database job, then select Properties.
4.
Look for the value in the Owner field.
Refer to the instructions for your SQL Server version to change the owner of all web protection jobs to the trusted account used by the 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.
On the Log Server machine, open the Windows Services tool (Start > Administrative Tools > Services or Server Manager > Tools > Services).
2.
Locate Websense Log Server service.
3.
Right-click the service name, then select Properties.
4.
On the General tab, click Stop.
5.
In the Start Parameters box, enter -debug.
6.
Click Start, then close the Properties window.
Log Server starts and creates the file debug.txt in the bin directory (C:\Program Files\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 runs.
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 tool 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
Log Server Troubleshooting Guide : Incorrect or missing data in reports
Copyright 2016 Forcepoint LLC. All rights reserved.