Log Data Verification

Check for missing log data by either:

• Reviewing recent log performance statistics.
• Looking for gaps in the sequential number reported by each Real-Time Log Delivery software agent.

Checking for Sequence Number Gaps #

Use the following information when assessing whether there is a gap in the sequential number reported by each Real-Time Log Delivery software agent.

• A software agent’s unique ID is reported within the:

  • Log file name (AgentID) - AWS S3, Azure Blob Storage, and Google Cloud Storage only

  • JSON payload (agent-id)

• A software agent’s sequence number is reported within the:

  • Log file name (SequenceNumber) - AWS S3, Azure Blob Storage, and Google Cloud Storage only

  • JSON payload (seq-num)

• The sequential number reported for each software agent starts at 0.

• This sequential number resets to 0 at the start of a new day (UTC). The date on which log data was generated is reported within the:

  • Log file name (DateStamp) - AWS S3, Azure Blob Storage, and Google Cloud Storage only
  • JSON payload (date-stamp)

• If a software agent stops running, then it will be assigned a new unique ID.

If log data uses either the JSON Array or JSON Lines log format, then you will be unable to use the JSON payload to check for sequence number gaps. This means that you will be unable to check for sequence gaps when delivering log data to your web server(s), Splunk Enterprise, Sumo Logic, Datadog, or New Relic.

Log File Example #

Let’s assume that your AWS S3 bucket, Azure Blob container, or Google Cloud Storage bucket contains the following log files:

1wpc_0001_123_0114_0000000000000123_0.json.gz
2wpc_0001_123_0114_0000000000000123_1.json.gz
3wpc_0001_123_0114_0000000000000123_3.json.gz

In this situation, we can tell that there is missing log data. Specifically, the log entries associated with the following log file are missing:

wpc_0001_123_0114_0000000000000123_2.json.gz