interpreter/php: use structured logging

[lucasly-ba]

Part of #891

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: lucasly-ba / name: Lucas Ly Ba (02dd27e)

[fabled]

log messages should start with capital letter (error message with small); keep also the PHP as context in the message

Suggested change

	log.Debug("an error occurred while determining the VM kind",
	log.Debug("An error occurred while determining the PHP VM kind",

[fabled]

Suggested change

	log.Debug("an error occurred while determining the return address for execute_ex",
	log.Debug("An error occurred while determining the return address for PHP execute_ex",

[fabled]

Since this is first of these translations, I'm raising some questions for other maintainers:

• should the version be more specific, like php_version?
• should there be an additional subsystem or module or similar tag to indicate it's php related?

Suggested change

	"version", version, "error", err)
	"php_version", version, "error", err)

[christos68k]

We should have a separate key (e.g. subsystem or module or package) for the main components and then additional keys like php_version wouldn't need the extra qualifier, so module:php, version:xyz would retain interpretability.

I think it'd be nice to have some basic guidelines for structured logging (e.g. in doc/logging-dev.md) before we start rewriting our existing logging en masse. We'd want to do that primarily for consistency which enables better UX on the consumer who'd be able to filter based on known keys.

@lucasly-ba Would you be interested in taking a crack at this?

A relevant issue is #417 which structured logging could also address by splitting the values with '/'. For example, we could have a module key with reporter, processmanager, tracer, collector and so on but logging code that requires an additional level of grouping could introduce its own nesting, e.g. going back to #417 we could have module:processmanager/pid and module:reporter/pdata.

[lucasly-ba]

Yes of course ! Will do it in quite a long time but ill ping you when i dig more into this

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on reviewers · refreshed 2026-09-10 22:26 UTC

Review the latest changes.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.