[wrangler] Add metrics export configuration - #15112
Conversation
…r-metrics-export-config # Conflicts: # packages/deploy-helpers/src/deploy/deploy.ts # packages/deploy-helpers/src/preview/preview.ts # packages/workers-utils/src/config/validation.ts # packages/wrangler/src/__tests__/preview.test.ts
🦋 Changeset detectedLatest commit: 6261c79 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
@cloudflare/autoconfig
@cloudflare/build-output-utils
@cloudflare/config
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-functions
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
| @@ -545,7 +546,7 @@ async function maybePatchSettings( | |||
| logpush: config.logpush, | |||
| tail_consumers: config.tail_consumers, | |||
| streaming_tail_consumers: config.streaming_tail_consumers, | |||
| observability: config.observability, // TODO reconcile with how regular deploy handles empty state | |||
| observability: withoutMetricsExportConfig(config.observability), // TODO reconcile with how regular deploy handles empty state | |||
There was a problem hiding this comment.
Is this TODO something worth fixing now?
There was a problem hiding this comment.
I don’t think we should address this in this PR. The TODO predates the metrics change and concerns broader differences in how regular and versions deploys clear non-versioned observability settings. This PR only preserves existing behavior while stripping the metrics-only configuration from versions deploys. I’d keep this as follow-up work, what do you think?
| .optional(), | ||
| metrics: z | ||
| .strictObject({ | ||
| enabled: z.boolean(), |
There was a problem hiding this comment.
So the metrics object is optional but the enabled field is always required?
There was a problem hiding this comment.
Correct, this is intentional. Metrics export is optional, but once the block is present we require an explicit enabled: true or enabled: false. This prevents destinations-only configurations from being silently ignored and gives users an explicit way to clear existing export configuration. Do it make sense?
| WorkerMetadataBinding, | ||
| } from "@cloudflare/workers-utils"; | ||
|
|
||
| export function withoutMetricsExportConfig( |
There was a problem hiding this comment.
Nit pick: Can we add some JSDoc comments to these functions with a brief description of what they do.
| @@ -336,9 +351,21 @@ describe("wrangler preview", () => { | |||
| ); | |||
| }); | |||
|
|
|||
| test("should create a new preview with defaults applied", async ({ | |||
| test("should ignore metrics export and create a new preview", async ({ | |||
There was a problem hiding this comment.
The title implies we're ignoring the metrics export but all we do is write a Wrangler config but not actually check anything after to validate metrics exports were ignored?
Unless I am missing something here?
There was a problem hiding this comment.
Yes, good catch. There is a separate unit test covering assemblePreviewScriptSettings, but this integration test does not explicitly verify the preview request or absence of a metrics API call. I’ll add assertions that metrics are excluded from the preview payload and that no metrics reconciliation is attempted.
| writeWranglerConfig({ | ||
| observability: { metrics: { enabled: false } }, | ||
| }); |
There was a problem hiding this comment.
Is this really needed if we already have a fallback to disable metrics?
There was a problem hiding this comment.
The metrics block is needed because cleanup is intentionally gated on its presence, avoiding calls to the allowlist-restricted endpoint for unrelated deletes. However, enabled: false is misleading in this test. I’ll use enabled: true and rename the test to make clear that it verifies post-delete cleanup of an actively configured export.
| --- | ||
| "@cloudflare/config": minor | ||
| "@cloudflare/workers-auth": minor | ||
| "@cloudflare/workers-utils": minor | ||
| "wrangler": minor | ||
| --- |
There was a problem hiding this comment.
🟡 Release notes leave out one of the packages that was changed
The release note file (.changeset/fuzzy-metrics-export.md:1-6) lists only four packages even though the deploy helper package was also modified, so that package will not get a version bump or changelog entry when the release is cut.
Impact: The published deploy-helpers package stays on its old version without the metrics-export code, and its changelog omits this change.
Why the missing entry matters for the release pipeline
packages/deploy-helpers is a published (non-private, version 0.6.6) workspace package and is not in the changesets ignore list (.changeset/config.json). This PR adds packages/deploy-helpers/src/deploy/helpers/metrics-export.ts and modifies packages/deploy-helpers/src/deploy/deploy.ts, src/preview/shared.ts, and src/index.ts, but the changeset front-matter only bumps @cloudflare/config, @cloudflare/workers-auth, @cloudflare/workers-utils, and wrangler. Repository rules (AGENTS.md / CONTRIBUTING.md) state that every change to package code requires a changeset, and @cloudflare/deploy-helpers is routinely included in changesets elsewhere in the repo history.
| --- | |
| "@cloudflare/config": minor | |
| "@cloudflare/workers-auth": minor | |
| "@cloudflare/workers-utils": minor | |
| "wrangler": minor | |
| --- | |
| --- | |
| "@cloudflare/config": minor | |
| "@cloudflare/deploy-helpers": minor | |
| "@cloudflare/workers-auth": minor | |
| "@cloudflare/workers-utils": minor | |
| "wrangler": minor | |
| --- |
Was this helpful? React with 👍 or 👎 to provide feedback.
This reverts commit 6e80b65.
Fixes https://jira.cfdata.org/browse/WO-1037.
Purpose
This PR makes metrics export a first-class Wrangler configuration under
observability.metrics, alongside the existingobservability.logsandobservability.tracessettings.Users can declare whether metrics export is enabled and which destinations should receive metrics directly in their
wrangler.jsoncfile:{ "$schema": "node_modules/wrangler/config-schema.json", "name": "metrics-worker", "main": "src/index.ts", "compatibility_date": "2026-08-10", "observability": { "logs": { "enabled": true }, "traces": { "enabled": true }, "metrics": { "enabled": true, "destinations": ["opentelemetry-metrics"] } }, "d1_databases": [ { "binding": "DB", "database_name": "metrics-database", "database_id": "11111111-1111-1111-1111-111111111111" } ], "r2_buckets": [ { "binding": "BUCKET", "bucket_name": "metrics-bucket" } ] }The same destinations are applied to the Worker and its supported bound resources.
Metrics export can be explicitly disabled without removing the configuration block:
{ "observability": { "metrics": { "enabled": false } } }Supported resources
This initial implementation supports:
Wrangler resolves canonical D1 and R2 identifiers from local configuration or deployed Worker settings. Other resource types are not included in the reconciliation request.
Lifecycle coverage
wrangler deploywrangler deletewrangler versions deploywrangler versions uploadNative Logs and Traces settings continue through their existing upload and script-settings paths. Adding a metrics-only block does not enable, disable, or otherwise change Logs or Traces.
Validation
When
observability.metricsis present:enabledmust be explicitly set totrueorfalse.destinationsis required and must be non-empty when enabled.Implementation
Metrics export uses a separate API from the native Worker observability settings. Wrangler therefore removes
metricsfrom Worker upload, preview, and script-settings payloads before reconciling it independently.The reconciliation request identifies the Worker as the requester and includes the supported Worker, D1, and R2 resources. Transient API failures are retried. Configuration errors, such as unresolved bindings, retain their actionable error messages.
If reconciliation fails during a regular deployment, Wrangler warns that the primary Worker deployment succeeded but metrics export configuration was not applied. The completed Worker deployment still returns successfully.
Configuration removal semantics
Removing the entire
observabilitysection or onlyobservability.metricsintentionally leaves any existing metrics export active. Wrangler does not call the Portal/metricsexportAPI when the metrics block is absent. This prevents every normal deployment, including projects that never adopted metrics export, from calling an API that is currently restricted to allowlisted accounts.To stop an existing export, users must explicitly deploy
observability.metrics.enabled: false. This differs from native Workers Logs and Traces, which are disabled when their observability configuration is removed. We plan to revisit this behavior when Wrangler can distinguish existing metrics-export state without calling the Portal API for unrelated deployments.Rollout
The metrics export API is currently behind a Flagship rollout flag and is available only to whitelisted accounts. The internal Flagship flag name is intentionally not exposed here.