Expose native resource attributes config in logfire-node

[dhimmel]

@pydantic/logfire-node.configure() exposes first-class options for serviceName, serviceVersion, environment, and codeSource, but does not appear to expose a typed way to set arbitrary OpenTelemetry resource attributes such as:

• service.namespace
• service.instance.id
• process.pid
• app.installation.id

Logfire has native columns for values like process_pid, service_instance_id, and service_namespace, but the practical way to set them today is to mutate process.env.OTEL_RESOURCE_ATTRIBUTES before calling logfire.configure().

That works because Logfire’s Node SDK uses OpenTelemetry’s env detector, but it is less ergonomic and less type-safe than a direct API. It also requires callers to manually serialize/percent-encode values and reason about inherited process env vars.

Possible API shape:

logfire.configure({
  serviceName: 'my-app',
  serviceVersion: '1.2.3',
  environment: 'production',
  resourceAttributes: {
    'service.namespace': 'my-company',
    'service.instance.id': crypto.randomUUID(),
    'process.pid': process.pid,
    'app.installation.id': installationId,
  },
})

Potentially also useful: an option to enable standard OTel resource detectors, e.g. processDetector, serviceInstanceIdDetector, hostDetector, and osDetector, without replacing Logfire’s defaults.

The goal is not new semantics, just exposing the native OpenTelemetry resource path through Logfire’s public config API instead of requiring OTEL_RESOURCE_ATTRIBUTES.

Current workaround

process.env.OTEL_RESOURCE_ATTRIBUTES = [
  process.env.OTEL_RESOURCE_ATTRIBUTES,
  [
    `service.namespace=${encodeURIComponent('my-company')}`,
    `service.instance.id=${encodeURIComponent(crypto.randomUUID())}`,
    `app.installation.id=${encodeURIComponent(installationId)}`,
    `process.pid=${process.pid}`,
  ].join(','),
]
  .filter(Boolean)
  .join(',')

logfire.configure({
  serviceName: 'my-app',
  serviceVersion: '1.2.3',
  environment: 'production',
})

[petyosi]

@dhimmel I added the options you refer to. The resource detectors are an interesting idea, most likely needs a separate thought, so I'm leaving the issue open.