-
Notifications
You must be signed in to change notification settings - Fork 80
Open
Labels
no-staleExempt this issue/PR from the staleness botExempt this issue/PR from the staleness bot
Description
Describe the bug
Not sure if this should be considered as a bug, but if I use second level jsonPayload JSON childs with modify_fields and omit_if, first level JSON child (parent of second level child) then is not omitted.
To Reproduce
Steps to reproduce the behavior:
- Start a GCE VM with image 'rocky-linux-9-v20240515'
- Install Ops Agent version 'google-cloud-ops-agent-2.55.0-1.el9.x86_64.rpm'
- Customize the agent with the following configuration' and restart the agent
logging:
receivers:
test_log:
type: tcp
format: json
processors:
add_context:
type: modify_fields
fields:
jsonPayload.serviceContext.service:
static_value: 'my-service'
omit_if: jsonPayload.exception = ""
service:
pipelines:
default_pipeline:
processors: [add_context]
receivers: [test_log]
This will leave empty serviceContext: {} in jsonPayload when exception field is empty.
The workaround I found is to use second processor to remove empty serviceContext:
logging:
receivers:
test_log:
type: tcp
format: json
processors:
omit_empty_context:
type: modify_fields
fields:
jsonPayload.serviceContext:
move_from: jsonPayload.serviceContext
omit_if: jsonPayload.exception = ""
add_context:
type: modify_fields
fields:
jsonPayload.serviceContext.service:
static_value: 'my-service'
omit_if: jsonPayload.exception = ""
service:
pipelines:
default_pipeline:
processors: [add_context, omit_empty_context]
receivers: [test_log]
This correctly doesn't produce serviceContext when exception is empty at all.
Expected behavior
It would be great if modify_fields could omit the field completely.
Environment (please complete the following information):
- VM distro / OS: Rocky Linux 9.5
- Ops Agent version 2.55.0
Metadata
Metadata
Assignees
Labels
no-staleExempt this issue/PR from the staleness botExempt this issue/PR from the staleness bot