The query internallogs command fetches the debug log of a running Falcon LogScale Collector through the local API.

Here's how to run the commands:

Linux:

logscale-collector query internallogs --cfg /etc/humio-log-collector/config.yaml

Windows:

"C:\Program Files (x86)\CrowdStrike\Humio Log Collector\humio-log-collector.exe" query internallogs --cfg "C:\Program Files (x86)\CrowdStrike\Humio Log Collector\config.yaml"

Output Format

The command returns newline-delimited JSON (NDJSON), where each line is a self-contained JSON log event. Note that this is not a JSON array. If you intend to parse the output programmatically, your parser should handle one JSON object per line.

The debug log via the local API is unfiltered by default, and is not affected by logLevel, or the internal debug log sender feature, so the output generated can be extremely verbose. This means that a short capture window on an active collector might produce thousands of events, the majority of which will be repeating patterns of normal internal activity at trace and debug level.

To help with this, you can limit the output to a specific log level by passing --log-level to the command.

Here's how:

Linux:

logscale-collector query internallogs --cfg <path to config> --log-level error

Windows:

"C:\Program Files\LogScale Collector\LogScale Collector.exe" query internallogs --cfg "C:\Program Files\LogScale Collector\config.yaml" --log-level error

This can be particularly useful for reducing the volume of output when investigating a specific issue.

Common Fields

Every event contains the following fields:

Sample Output

Beyond the common fields shown above, each event includes additional fields specific to the component that produced it. The sections below describe the main component types and their associated fields, including one representative event for each major component type.

Common fields are omitted for brevity; in the actual output every event will include the full set of common fields described above.

Queue Statistics

Reports the current state of the memory queue, including event and batch counts:

{
  "level": "debug",
  "queueName": "logscaleSink",
  "queueType": "memory",
  "queued-EventCount": 780,
  "queued-BatchCount": 572,
  "message": "popOldestFromFlushList: flushList statistics after popping"
}

Consumer Activity

Reports batch retrieval activity as the consumer reads from the queue:

{
  "level": "debug",
  "queueName": "logscaleSink",
  "queueType": "memory",
  "message": "Consumer receives 1 batches from the Queue"
}

Source Event Processing

Reports activity at the source level. Fields vary by source type. The example below is from a wineventlog source:

{
  "level": "trace",
  "sourceName": "windowsEvents",
  "sourceType": "wineventlog",
  "module": "wineventlog",
  "eventID": 16,
  "providerName": "Microsoft-Windows-Kernel-General",
  "message": "Processing event"
}

Sink Transmission

Reports the result of a completed transmission to the sink. This is one of the more 'information-rich' event types:

{
  "level": "debug",
  "sinkName": "logscaleSink",
  "sinkType": "humio",
  "count": 3411,
  "fields": 137078,
  "sizeRawData": 9253581,
  "compressionMethod": "gzip",
  "attempts": 1,
  "timeToSend": 509.4168,
  "bytesCompressed": 433529,
  "bytesUncompressed": 10333093,
  "compressionRatio": 23.83,
  "message": "Sent events to sink"
}

Acknowledgement Tracking

Reports the state of the acknowledgement loop, which tracks successful delivery of events:

{
  "level": "debug",
  "queueName": "logscaleSink",
  "queueType": "memory",
  "ack-eventCount": 24395,
  "message": "total pending ack count after receiving new acks"
}

Checkpoint Flush

Reports that the collector has written its current position to persistent storage. This occurs periodically and allows the collector to resume from the correct position after a restart:

{
  "level": "trace",
  "count": 1,
  "message": "Flushed checkpoints"
}

Warn and Error Events

The examples above are from a healthy collector and do not include warn or error level events.

These follow the same JSON structure as other events, but with "level": "warn" or "level": "error" and message fields appropriate to the condition encountered. If you are using internallogs to investigate a problem, filtering for these levels (as shown in the example above) is a good starting point.