Solutions

Blue Coat Reporter best practices guide:

Solutions ID:    KB1549
Version:    20.0
Status:    Published
Published date:    03/02/2009
Updated:    01/10/2014
 

Problem Description

Blue Coat Reporter best practices guide.

What are some best practices for Running Reporter, version 9.1.x?


You want to know about best practices for using Reporter, version 8.x.

Resolution

  • Use the sizing guide found at https://bto.bluecoat.com/doc/19582
  • Only send access  log files from the ProxySG in the optimized format- bcreportermain_X
  • See FAQ282 for a detailed list of the golden fields required in the access log and the various types of logs in this type of format.
  • Use only the support browsers, which are limited to Firefox 3.6.x, IE 7 and 8.  Chrome, Safari, and newer versions of Firefox are not supported.
  • Ensure only one type of logs are sent to each database - each of the below access logs should be in separate databases.
    • HTTP
    • HTTPS
    • Streaming media logs 
    • Proxy Client logs
    • See KB3682 for more information what type of access logs should be streamed, by the Bluecoat Reporter client, to Reporter.

NOTE: Version 9.X Reporter only supports Bluecoat HTTP,  HTTPS  and Proxy Client access logs.

  • Use 64-bit CPU hardware with the supporting operating systems.  Bluecoat can run on both Red hat enterprise Linux version 5, or Microsoft  Windows 2003 and 2008 servers. See the Bluecoat Reporter version 9.1.x readme file for the exact specifications. 
  • Do not run Reporter on a Windows Primary Domain controller. Some large database queries can consume so much CPU time that authentication requests start to slow down or even stall.

Disk space and placement of access logs:

  • Upload your access logs to a separate server, and pull them down via the FTP protocol to be processed into the databases. If you can't upload them to a seperate server, have them uploaded to a seperate mount point, or Drive on the server you run Reporter on.
    • Only upload them every hour to ensure you don't overload your servers file system.  To minimize load, we suggest you only process access logs once a day. By Default, Reporter is configured to check, and process, acess logs every ten minutes.
  • Create you database(s) on local mount points, or disk drives, on your server. If you create a database on a Disk drive, or Mount point (LINUX) other than the one the Reporter service runs on, it will not monitor it, and alert you when you run low on space.
  • Ensure you always test how long a Report takes to run before you schedule it.  This will ensure you allow appropriate time between scheduling each report.
  • Do not store more than 50,000 access logs in one folder.  Reporter has trouble with more than this amount, when it comes to having to re-process them all at once.
  • Schedule Reporter to process it's access logs at 2 AM every day to avoid running reports, and processing access logs at the same time.
  • Do not upload more than a year worth of access logs to the same folder.  By default, ProxySG does not write the year into the name of access log, so after a year, reporter will start seeing the same name log file in the folder. The rename occurs as Reporter moves or rename  the access logs once it has finished processing them . The file names will look like the following:

Origonal file name from the year before:  SG_main__2100316010000.log.gz
After an attempt to rename/move the access log file, it will name this file todup0001_SG_main__2100316010000.log.gz

Shutting down gracefully:

  • Ensure Reporter is shutdown gracefully, prior to stopping the Host operating system.
    • For LINUX, run the " /etc/init.d/bcreporter stop" command before stopping LINUX.
    • For Windows, run a "Net stop bcrervice"  as a script, prior to stopping Windows. 

 Scheduleing of Reports:

  • Every attempt should be made to schedule reports at different times.
  • Every attempt should be made to predict how long a report will run, and schedule large reports at staggered intervals from each other.
  • Every attempt should be made to schedule large reports at the slower times of the day such as after midnight.
  • Each report should be run manually to time how long it runs, before you schedule it.

VMware support:

  • To allow for future growth, install your application on VMware. This allows you to add disk space, and memory, as your database grows.

Links to other relevant articles:

For details on what Reporter is compatible with, see KB1549

For details on sizing for larger databases- beyond 2.5 billion log lines- see KB3674


Rate this Page

Please take a moment to complete this form to help us better serve you.

Did this document help answer your question?
 
 
If you are finished providing feedback, please click the RATE CONTENT button. Otherwise, please add more detail in the following text box and then click RATE CONTENT.
 
 

Your response will be used to improve our document content.

Ask a Question