## TL;DR
The client update changed log field names and the parser broke silently. Tag parsers by client version, detect the version at parse time, and fall back to raw log attachment when parsing fails.

## The query
```text
agent could not parse the globalprotect log: log format changed after client update
```

## Use this when
- log parsing broke after a GlobalProtect update
- the agent reports no data from valid logs
- field names changed in the log format

## Not for
- GlobalProtect connection failures
- missing log files
- log collection problems

## Steps
1. Diff the old and new log samples to find the renamed or moved fields. Expected output: the format change is documented.
2. Version-tag the parser and select the grammar by detected client version. Expected output: each version parses correctly.
3. Add a fallback: when parsing fails, attach the raw log and flag it for human review. Expected output: no log is silently dropped.
4. Test the parser against samples from every supported client version. Expected output: a passing matrix across versions.
5. Pin the parser update to the client rollout so they ship together. Expected output: format and parser stay in sync.

## Applies to
Palo Alto GlobalProtect logs, log-parsing agents, client versions 5.x and 6.x.

## Variant phrasings
### Format changed in a hotfix, not a major
Version detection must include build numbers, not just major versions.

### Multiple client versions in the fleet
The version-tagged parser handles the mix; a single grammar cannot.

## Why it happens
Vendors change log formats without notice. A parser written for one version is a latent bug waiting for the next update.

## Edge cases
- Keep raw log samples per version in the test suite.
- Alert on parse-failure rate; a spike means a new format shipped.
- Prefer structured log output from the client where the option exists.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_c0dZFoeDc_tr5Aj07iX0ag