Project: Vector (Observability and Analysis / Observability)
File: 2023-02-28-0-28-0-upgrade-guide.md

date: "2023-02-18" title: "0.28 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.28.0" authors: ["spencergilbert", "neuronull"] release: "0.28.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.28.0 release includes breaking changes: and deprecations: and potentially impactful changes: We cover them below to help you upgrade quickly: The `units` option had been replaced by `include_units` in the `0.10` release. This release marks the final removal of this option, please update your configurations to use the `include_units` option instead. Vector `0.25.0` introduced new metadata path syntax available in VRL which points directly to event metadata. That meant the metadata functions were no longer necessary and were deprecated. They are now being removed. The table below shows you how to convert VRL code from the method calls to the new path syntax. If you are running Vector `0.25.0` or later, you will also receive warnings which will provide you with the correct syntax to use to migrate. | | before | after | |--||--| | get | getmetadatafield(.foo.bar) | %foo.bar | | set | setmetadatafield(.foo.bar, "value") | %foo.bar = "value" | | delete | removemetadatafield(.foo.bar) | del(%foo.bar) | The `apex` sink has been removed from Vector. This follows the EOL of the Apex service that took effect in December 2022. The deprecated `disk_v1` buffer type was removed. Users using this buffer type should use Vector v0.27.1 to migrate their buffers to the new disk buffer implementation by switching to the `disk` buffer type before upgrading to v0.28.0 which had the migration behavior removed. ```diff -type = "disk_v1" +type = "disk" ``` The change should be transparent. See [the blog post about the promotion of the new disk buffers to the default for `type = "disk"`](/highlights/2022-04-06-disk-buffer-v2-stable/) for details about this migration. Also see [the blog post about the introduction of the new disk buffer implementation](/highlights/2022-02-08-disk-buffer-v2-beta/) for the reasons the new disk buffer implementation was

In the `datadog_logs` sink, if an event contained the `host` key from either the global log schema, or the host path of the event, it was renamed to `host`. This was changed to rename it to `hostname`, to match the Datadog Agent intake API. To maintain consistent naming with other Vector sinks, the `url` option in the `redis` sink has been renamed to `endpoint`. `url` will still work, but has been deprecated and will be removed in due course. The `strategy` option has been hidden on the documentation for the `aws_s3` source. `sqs` is currently the only value for this option, and is currently the default. If additional strategies are added for this source, we will expose this option again. No changes need to be made by users of this source, it is a documentation only change. Previously this sink used the global `log_schema` to provide the value for this header, however the actual implementation always ensured an event's timestamp was stored at `@timestamp`. In this release we've hardcoded this header to match the underlying implementation. The `apikey` option has been hidden on the documentation for the `datadoglogs` and `datadog_metrics` sinks for a few releases now, with the documented name for that setting being `defaultapikey`. The `api_key` is now formally deprecated and will be removed in the `0.29.0` release. In this release, Vector's AWS integrations had their TLS implementation swapped from to OpenSSL. We don't expect any user visible impact, but if this change causes you any issues. We made this change primarily since most of Vector's dependencies use OpenSSL and so it reduces our maintenance burden caused by any variances in the implementation. We may re-evaluate in the future as more of the Rust ecosystem supports `rustls`. Previously this sink would include a properly formatted timestamp at a path determined by the `log_schema` as well as setting a `time-generated-field` header with a value of that path. Azure Monitor will use the contained value to populate the . In this release we've added a `timegeneratedkey` option that determines where this field is encoded, this field defaults to the value set in `log_schema` if unset.