Solution

I'm using the Bluecoat Reporter client to connect to Reporter, but I am seeing a GZ error - 5 in the journals. What do they mean?

Using the techniques to discover journal errors in Reporter, outlined in KB3460, I can see that my streaming log source connection is showing a GZ error -5. What does this mean?

Cause

Resolution

With the streaming configuration ( Bluecoat reporter client ) the ProxySG sends gzip'd access log data in many small gzip segments which are only a few hundred to a couple thousand bytes per segment. These segments never appear as a file on the REporter server, but , rather, get directly injected into the database as soon as they arrive. A "Z_BUF_ERROR (-5)" typically means the ProxySG sent a gzip byte stream that did not begin with a proper gzip header. This error is generally only seen when the ProxySG re-creates a broken SGP connection with Reporter, and suddenly, and unexpectedly for Reporter, begins sending the rest of a gzip segment that was originally started right at the end of the previous closed connection.

NOTE: As the frequency of TCP connections being created and closed increases, there is a greater chance you will see this error.

Reporter, version 9.X, will forgive the first gzip failure but, as it is virtually impossible to start up in the middle of a gzip stream and begin deflating the rest of the encoded byte stream, it cannot forgive any other breaks in the stream. Thus, Reporter must search the byte stream for the next gzip segment header, tossing any data that was in the remainder of the decapitated segment. The -5 error lets everyone know that Reporter has had to drop a small amount of access log data, in order to catch up with the gzip segments. The older version of Reporter- version 8.x- had the exact same logic, only it stayed quiet about the dropped data and forgiven error. Once the next header is found, the continuing byte stream containing multiple gzip segments will be continuously deflated without further incident.

NOTE: Reporter 9.2, which is in open beta right now, will only forgive an initial gzip error if it occurs in the first packet after the connection is established.)

1: If this GZIP occurs at daily intervals when the "rotate" trigger is scheduled at the SG, then it's a known issue, and can be solved by upgrading your SG operating system. Please call support, and mention this KB article, for the exact version of SG you need. See KB3489 for details on how to check what your trigger time value is.

2: The second cause of this connection oscillation is caused by a corrupt gzip byte stream. The ProxySG saves its access log data locally while the connection to Reporter is down. I have seen occasions where once a stable connection is made to Reporter, the accrued gzip data being sent by the ProxySG is no longer correct. In this case, reporter forgives any decapitated segment with a -5 journal message (strike 1), but the continuing corrupted byte stream coming from the ProxySG then causes the Z_DATA_ERROR (-3) error (strike 2). At this point, it is Reporter forcing the connection to close due to corrupt data. The journal messages are clear about which side caused the connection to close. As long as the ProxySG keeps sending corrupt gzip data, the journal will be full of the connect/error -5/error -3/fatal-close messages. More details on the GZ error -3 is documented in 000011659

NOTE: For a detailed discussion on general troubleshooting tips for a streaming connection see KB3489

NOTE: For reasons why you might see a GZip error on a FTP log source, see 000013828