2.22.0 -> 2.23.0 upgrade broke 'map_values' configuration

[jkachmar]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Start a GCE VM with image Ubuntu 22.04 LTS
2. Install the latest Ops Agent version (2.23.0, at the time of writing) according to the documentation
3. Customize the agent with config.yaml [see below] and restart the agent
4. See error

Expected behavior
Google Cloud Ops Agent should parse the map_values directive and apply the configuration

Environment (please complete the following information):

• VM distro / OS: Ubuntu 22.04
• Ops Agent version: 2.23.0
• Ops Agent configuration: [see config.yaml below]
• Ops Agent log: [see log.txt below]

Additional context

config.yaml

logging:
  receivers:
    journald:
      type: systemd_journald

  processors:
    # Add labels according to syslog facility codes.
    #
    # cf. https://wiki.archlinux.org/title/Systemd/Journal#Facility
    label_journald:
      type: modify_fields
      fields:
        labels.facility:
          copy_from: jsonPayload.SYSLOG_FACILITY
          map_values:
            '0': kernel
            '1': user
            '2': mail
            '3': daemon
            '4': auth
            '5': syslog
            '9': systemd-timesyncd
            '10': auth
            '15': cron

  service:
    pipelines:
      default_pipeline:
        receivers: [journald]
        processors: [label_journald]

log.txt

Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]: 2022/11/18 10:00:23 The agent config file is not valid. Detailed error: [65:18] unexpected key name
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]:   62 |           type: ""
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]:   63 |           omit_if: ""
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]:   64 |           map_values:
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]: > 65 |             "0": kernel
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]:   66 |             "1": user
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]:                         ^
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]:   67 |             "10": auth
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]:   68 |             "15": cron
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]:   69 |             "2": mail
Nov 18 10:00:23 2204-test google_cloud_ops_agent_engine[59591]:   70 |
Nov 18 10:00:23 2204-test systemd[1]: google-cloud-ops-agent.service: Control process exited, code=exited, status=1/FAILURE
Nov 18 10:00:23 2204-test systemd[1]: google-cloud-ops-agent.service: Failed with result 'exit-code'.
Nov 18 10:00:23 2204-test systemd[1]: Failed to start Google Cloud Ops Agent.

[qingling128]

Thank you for reporting the bug. We're looking into reverting the dependency. Note that we are in a holiday freeze from today to Nov 29. So the fix won't be released till then. For now, please downgrade to the previous agent version to bypass this issue.

Note to our team: We have an integration test case here (

ops-agent/integration_test/ops_agent_test.go

Line 1242 in 5203675

func TestModifyFields(t *testing.T) {

). We could probably add some field(s) that do similar mapping as this bug report to help prevent the same regressions in the future.

[jkachmar]

Thanks so much for the quick response; we just edited the config to remove that section for now (it was really only a nicety, nothing critical), but I appreciate the follow-up.

Feel free to close this issue as resolved if you'd like; I don't need it to stay open until a new version is released.

Hope y'all enjoy the holidays!

[braydonk]

I've started investigating this issue upstream at goccy/go-yaml#301

[braydonk]

Made the PR upstream, hopefully the maintainer is okay with my solution. goccy/go-yaml#327

[braydonk]

This fix was released in go-yaml 1.9.7, which we just upgraded to! We unfortunately are in a freeze and can't release at the moment, but next release will contain the fix. Thanks for your patience!

[jjmirks]

@jkachmar did this end up working for you? The Ops Agent is starting but the values aren't getting remapped for me. I'm on version 2.28.0.

processors:
  set-severity:
    type: modify_fields
    fields:
      jsonPayLoad.severityTest:
        copy_from: jsonPayload.alert.severity
        map_values:
          '1': ERROR
          '2': WARNING
          '3': NOTICE

The value gets copied to jsonPayload.severityTest but does not get remapped