@gw-tools/gw 0.63.0-beta.73.1 → 0.63.0-beta.73.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +86 -85
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -403,114 +403,115 @@ Local config is merged on top of `config.json` (shallow merge, local wins). Usef
|
|
|
403
403
|
|
|
404
404
|
## Telemetry (OpenTelemetry & Dash0)
|
|
405
405
|
|
|
406
|
-
`gw` can
|
|
407
|
-
|
|
408
|
-
|
|
409
|
-
|
|
406
|
+
`gw` can send anonymous usage data to the maintainer's
|
|
407
|
+
[Dash0](https://www.dash0.com/) instance so aggregate usage can be observed and
|
|
408
|
+
releases correlated with error spikes. Telemetry is **opt-in and disabled by
|
|
409
|
+
default** — nothing leaves your machine until you explicitly enable it.
|
|
410
410
|
|
|
411
|
-
###
|
|
411
|
+
### Opting in and out
|
|
412
412
|
|
|
413
|
-
|
|
413
|
+
```bash
|
|
414
|
+
gw telemetry on # enable on this machine
|
|
415
|
+
gw telemetry off # disable on this machine
|
|
416
|
+
gw telemetry status # show current effective state
|
|
417
|
+
```
|
|
414
418
|
|
|
415
|
-
|
|
416
|
-
|
|
417
|
-
- **One log record** — `INFO` on success, `ERROR` (with `error.message`) on
|
|
418
|
-
failure.
|
|
419
|
+
`gw telemetry on/off` writes to `.gw/config.local.json`, which is gitignored,
|
|
420
|
+
so your choice stays local and never affects other people who clone the repo.
|
|
419
421
|
|
|
420
|
-
|
|
421
|
-
|
|
422
|
-
what lets Dash0 line up "a new version shipped" with "errors started".
|
|
422
|
+
You can also use the env var `GW_TELEMETRY=1` to enable or `GW_TELEMETRY=0` to
|
|
423
|
+
disable for a single session without touching any config file.
|
|
423
424
|
|
|
424
|
-
`gw`
|
|
425
|
-
|
|
426
|
-
|
|
425
|
+
`gw init` writes a `"telemetry": { "enabled": false }` block into your
|
|
426
|
+
`.gw/config.json` so the option is easy to discover. Note that `enabled` in the
|
|
427
|
+
committed `config.json` has no effect — opt-in is per-machine only (use
|
|
428
|
+
`gw telemetry on` or `GW_TELEMETRY=1`).
|
|
427
429
|
|
|
428
|
-
|
|
429
|
-
> and never slows down or breaks a command, and nothing is ever written to
|
|
430
|
-
> stdout (so shell-eval commands like `gw cd` stay safe).
|
|
430
|
+
### What gets sent
|
|
431
431
|
|
|
432
|
-
|
|
432
|
+
When enabled, each command emits **one span** and **one log record** via
|
|
433
|
+
OTLP/HTTP to the maintainer's Dash0 instance:
|
|
433
434
|
|
|
434
|
-
|
|
435
|
-
|
|
436
|
-
|
|
437
|
-
|
|
435
|
+
- **Span attributes:** `gw.command`, `gw.command.exit_code`,
|
|
436
|
+
`gw.command.duration_ms`, `service.version`
|
|
437
|
+
- **Log level:** `INFO` on success, `ERROR` on failure (with a redacted
|
|
438
|
+
`error.message`)
|
|
439
|
+
- **Resource attributes:** `service.name`, `service.version`,
|
|
440
|
+
`deployment.environment.name` (if configured)
|
|
438
441
|
|
|
439
|
-
|
|
442
|
+
**What is NOT sent:** branch names, repository paths, file names, user identity,
|
|
443
|
+
or any personally identifiable information. Error messages are client-side
|
|
444
|
+
redacted before transmission — absolute paths, git refs, long hex SHAs, and
|
|
445
|
+
`KEY=value` patterns are replaced with `<path>`, `<ref>`, `<sha>`, and
|
|
446
|
+
`KEY=<redacted>` respectively.
|
|
440
447
|
|
|
441
|
-
|
|
442
|
-
|
|
443
|
-
|
|
444
|
-
"enabled": true,
|
|
445
|
-
"endpoint": "http://localhost:4318", // local OTel Collector
|
|
446
|
-
"environment": "production" // deployment.environment.name
|
|
447
|
-
}
|
|
448
|
-
}
|
|
449
|
-
```
|
|
448
|
+
> **Fail-open design:** any export error is silently swallowed and never slows
|
|
449
|
+
> down or breaks a command. Nothing is ever written to stdout (so shell-eval
|
|
450
|
+
> commands like `gw cd` stay safe).
|
|
450
451
|
|
|
451
|
-
|
|
452
|
-
|
|
453
|
-
|
|
454
|
-
|
|
455
|
-
|
|
456
|
-
|
|
457
|
-
|
|
458
|
-
|
|
459
|
-
http: { endpoint: 0.0.0.0:4318 }
|
|
460
|
-
exporters:
|
|
461
|
-
otlp/dash0:
|
|
462
|
-
endpoint: ${env:DASH0_OTLP_ENDPOINT} # e.g. ingress.<region>.aws.dash0.com:4317
|
|
463
|
-
headers:
|
|
464
|
-
Authorization: Bearer ${env:DASH0_AUTH_TOKEN}
|
|
465
|
-
Dash0-Dataset: ${env:DASH0_DATASET}
|
|
466
|
-
service:
|
|
467
|
-
pipelines:
|
|
468
|
-
traces: { receivers: [otlp], exporters: [otlp/dash0] }
|
|
469
|
-
logs: { receivers: [otlp], exporters: [otlp/dash0] }
|
|
470
|
-
```
|
|
452
|
+
### Privacy and the threat model
|
|
453
|
+
|
|
454
|
+
The compiled `gw` binary bundles the maintainer's Dash0 ingest endpoint and a
|
|
455
|
+
scoped ingest token. This is the same approach used by Sentry DSNs, Vercel CLI
|
|
456
|
+
analytics, and Deno's own telemetry. The token is scoped to the `gw-cli`
|
|
457
|
+
dataset and subject to ingest quotas — it cannot read back data or access other
|
|
458
|
+
Dash0 resources. Anyone who disassembles the binary could extract the token, but
|
|
459
|
+
the worst-case impact is noise in a single dataset, not a data breach.
|
|
471
460
|
|
|
472
|
-
|
|
461
|
+
To completely opt out: `gw telemetry off` (or `GW_TELEMETRY=0`). The telemetry
|
|
462
|
+
code path is never entered when disabled.
|
|
473
463
|
|
|
474
|
-
|
|
475
|
-
|
|
476
|
-
|
|
464
|
+
### Routing to your own backend
|
|
465
|
+
|
|
466
|
+
Power users can override the maintainer's endpoint and route telemetry to their
|
|
467
|
+
own OTel backend instead. The precedence is: \*\*env vars > `.gw/config.local.json`
|
|
468
|
+
|
|
469
|
+
> committed `.gw/config.json` > build defaults\*\*.
|
|
477
470
|
|
|
478
471
|
```bash
|
|
479
|
-
|
|
480
|
-
export OTEL_EXPORTER_OTLP_ENDPOINT="
|
|
481
|
-
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <token>,Dash0-Dataset=
|
|
472
|
+
# Route to a local Collector
|
|
473
|
+
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318"
|
|
474
|
+
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <token>,Dash0-Dataset=my-dataset"
|
|
475
|
+
gw telemetry on
|
|
482
476
|
```
|
|
483
477
|
|
|
484
|
-
|
|
478
|
+
Or in `.gw/config.local.json` (gitignored):
|
|
485
479
|
|
|
486
|
-
|
|
487
|
-
|
|
488
|
-
|
|
489
|
-
|
|
490
|
-
|
|
491
|
-
|
|
492
|
-
|
|
493
|
-
|
|
480
|
+
```jsonc
|
|
481
|
+
{
|
|
482
|
+
"telemetry": {
|
|
483
|
+
"enabled": true,
|
|
484
|
+
"endpoint": "http://localhost:4318",
|
|
485
|
+
"headers": { "Authorization": "Bearer <token>", "Dash0-Dataset": "my-dataset" },
|
|
486
|
+
},
|
|
487
|
+
}
|
|
488
|
+
```
|
|
494
489
|
|
|
495
|
-
`
|
|
496
|
-
|
|
490
|
+
**Note:** `telemetry.enabled` in the committed `.gw/config.json` has no effect.
|
|
491
|
+
Opt-in is per-machine only (local config or env var). This prevents repo
|
|
492
|
+
maintainers from silently enrolling everyone who clones the repo.
|
|
497
493
|
|
|
498
|
-
###
|
|
494
|
+
### Configuration reference
|
|
499
495
|
|
|
500
|
-
|
|
501
|
-
|
|
502
|
-
`
|
|
503
|
-
|
|
504
|
-
|
|
496
|
+
| Setting | `config.local.json` key | Env override | Default |
|
|
497
|
+
| ------------- | ----------------------- | ----------------------------- | ----------------- |
|
|
498
|
+
| Enable | `telemetry.enabled` | `GW_TELEMETRY` (`1`/`0`) | `false` |
|
|
499
|
+
| Endpoint | `telemetry.endpoint` | `OTEL_EXPORTER_OTLP_ENDPOINT` | _(build default)_ |
|
|
500
|
+
| Environment | `telemetry.environment` | `OTEL_RESOURCE_ATTRIBUTES` | _(unset)_ |
|
|
501
|
+
| Service name | `telemetry.serviceName` | `OTEL_SERVICE_NAME` | `gw` |
|
|
502
|
+
| Headers | `telemetry.headers` | `OTEL_EXPORTER_OTLP_HEADERS` | _(build default)_ |
|
|
503
|
+
| Flush timeout | `telemetry.timeoutMs` | — | `1500` |
|
|
505
504
|
|
|
506
|
-
|
|
505
|
+
`OTEL_SDK_DISABLED=true` is honoured as a hard kill switch regardless of other
|
|
506
|
+
settings. Set `GW_TELEMETRY_DEBUG=1` to log export problems to stderr.
|
|
507
507
|
|
|
508
|
-
|
|
509
|
-
|
|
510
|
-
|
|
511
|
-
|
|
512
|
-
|
|
513
|
-
|
|
508
|
+
### Correlating deployments with errors
|
|
509
|
+
|
|
510
|
+
The release pipeline (`scripts/release-ci.sh`) sends a `deployment.success`
|
|
511
|
+
event to Dash0 after each publish, tagged with `service.version` and the git
|
|
512
|
+
commit SHA. Because runtime error signals carry the same `service.version`,
|
|
513
|
+
Dash0 can display a deployment marker on the error timeline and compare error
|
|
514
|
+
rates before and after each release.
|
|
514
515
|
|
|
515
516
|
## Commands
|
|
516
517
|
|