Palo Alto Network Firewall Logs Not Parsing

Have you confirmed whether the failing payloads are always the same Palo log type (Traffic, Threat, System, Config, etc.)? Also, is Strata batching multiple events into a single HTTP POST for the failures? If you compare a successful request with a failed one, do the failed payloads contain multiple top-level JSON objects or a JSON array? That would help determine whether this is a parser issue or a payload-format mismatch.

Hey, so it's a Payload-format mismatch for sure. The raw logs of the parsed logs are coming in as single events, and the failed parser logs are coming in as batched multiple events in one and contained top level JSON objects. 

I looked in Palo’s Strata logging and there is nothing around payload settings. 

We did configure the feed for it different than what Google had so that might also be an issue.
Under Google Secops → SIEM → Feed we selected webhook, got the api key from GCP’s API keys and added it to the webhook feed on the Google Secops side. Added the given webhook URL to Strata. 

Logs were coming in and being parsed so we thought it was good. but not sure if that is causing the issue.

We were trying to stay away from Service Account JSON keys.

That confirms it is probably message framing rather than the Palo log content itself.

If parsed events arrive as single JSON objects, but failed events arrive as multiple batched top-level JSON objects in one POST, the SecOps feed/parser may not be able to split them. A body like `{...}{...}{...}` is not one valid JSON document, even if each individual object is valid.

I would test with one failed raw payload:

1. Confirm whether the body is stacked JSON objects, a JSON array, or NDJSON.

2. Replay one object by itself into the same feed.

3. Replay the full batched body.

4. Compare parser behavior.

If the single object parses and the batch fails, the fix is likely one of:

- configure Strata to send one event per request if possible

- use an intermediary collector/Cloud Run/Function to split the batch before forwarding to SecOps

- switch to the Google-recommended feed/ingestion method for Palo Alto Strata if it handles batching differently

- confirm the SecOps feed type/parser is the Palo Alto/Strata parser and not a generic webhook parser

I do not think avoiding service account JSON keys is the root issue by itself. Since some events are ingesting and parsing, auth is probably fine. The main issue sounds like the payload shape being different between successful and failed requests.

As workaround for the JSON array issue:
Palo Alto via Strata logging supports also CEF.
The logs can be sent in CEF and in SECOPS configure -in the http feed- the log_type as ARCSIGHT_CEF.

Other alternatives could be relying on the unroll function of 3rd party tools (e.g. Cribl, Bindplane) to split the JSON.
But it might not make sense if you are self-hosting these solutions (breaking the SaaS to SaaS flow), and/or depending on the Paloalto log volumes (usually high) it will increase the cost significantly.

And as far as I know, Secops’ pipelines (based on Bindplane) don’t offer yet the unroll function.

Thanks, this confirms what we are seeing. The individual Palo Alto events are valid, but the Strata HTTP delivery batches them into a JSON array that Google SecOps does not split before parsing. We will test CEF with ARCSIGHT_CEF as the feed log type. Introducing Cribl or a separate Bindplane deployment would work technically, but likely adds unnecessary cost and complexity for this flow.

webhook + customer-managed GCP API keys mean ingestion via the “new” Secops endpoint, with a max event/batch size limit of 4MB.

Per the described symptoms I’m guessing when PA Strata is sending individual events the parser works fine but it fails when PA sends in batches (JSON array).

I barely know about Secops parsing, but there might be a way to handle this array via the parser, because if I’m not mistaken the AWS logs have a similar JSON array format.

Staying with this ingestion method, the options would be

-request Google to improve the prebuilt parser to handle properly the JSON array (recommended).

-fork your own custom parser (not recommended for well-known vendor products, because of the maintenance overhead).

-request PA to change the JSON array to NDJSON (unlikely to happen).

Last option is changing the destination endpoint to the one described in PA doc, the malachite endpoint aka the “old” or legacy endpoint. The max event size there is 1MB. And the Google-managed service account is required (downloadable in Secops settings). In this case the log_type ARCSIGHT_CEF is injected from the source, if I’m not mistaken.

My recommendation for the long term would be using the webhook feed (new endpoint), in JSON, as described by Google in their official doc. They need to fix the parser.

Thanks — this matches what I’m seeing.

The transport path appears healthy, and the failure seems isolated to how the new SecOps endpoint parses batched PA Strata payloads. Individual events succeed, while a valid JSON array fails, which points more toward a parser limitation than an ingestion or authentication issue.

I agree the best long-term fix is for Google to update the prebuilt parser to support the array format emitted by PA Strata. A custom parser would add unnecessary maintenance, and switching back to the legacy malachite endpoint would reduce the event-size limit and reintroduce the service-account dependency.

I’m going to compare:

Content-Type

single-event versus batched payload structure

exact parser error

whether newline-delimited JSON succeeds where a JSON array fails

That should give us enough evidence to determine whether this is a documented parser limitation or a reproducible defect worth escalating to Google.

Thank you let me know if this works 

I’d be happy to help validate this against the actual environment.

Please do not share API keys, service-account credentials, tenant identifiers, or sensitive log content.

The most useful artifacts would be:

one sanitized request that parses successfully

one sanitized batched request that fails

request headers, especially Content-Type and Content-Encoding

the exact SecOps parser error

the configured feed type and log_type

confirmation of whether the failed body is a JSON array, stacked objects, or NDJSON

If possible, we can then compare three controlled submissions:

one event as a single JSON object

the same events as a JSON array

the same events as newline-delimited JSON

That should isolate whether the failure occurs during HTTP ingestion, message framing, or the Palo Alto prebuilt parser.