{"id":15137806,"url":"https://github.com/cap-js/telemetry","last_synced_at":"2025-10-23T13:30:50.855Z","repository":{"id":213085910,"uuid":"676894829","full_name":"cap-js/telemetry","owner":"cap-js","description":"CDS plugin providing observability features, incl. automatic OpenTelemetry instrumentation.","archived":false,"fork":false,"pushed_at":"2024-04-22T22:30:00.000Z","size":428,"stargazers_count":7,"open_issues_count":16,"forks_count":4,"subscribers_count":10,"default_branch":"main","last_synced_at":"2024-04-23T10:53:30.388Z","etag":null,"topics":["cap","cds","nodejs","observability","open-telemetry","opentelemetry","sap-btp","sap-cap"],"latest_commit_sha":null,"homepage":"https://cap.cloud.sap/docs","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cap-js.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2023-08-10T08:58:57.000Z","updated_at":"2024-08-09T23:20:12.774Z","dependencies_parsed_at":"2024-03-22T20:25:52.556Z","dependency_job_id":"24dd9db0-be14-4a76-a5aa-cdfc0a7349e6","html_url":"https://github.com/cap-js/telemetry","commit_stats":null,"previous_names":["cap-js/telemetry"],"tags_count":15,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cap-js%2Ftelemetry","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cap-js%2Ftelemetry/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cap-js%2Ftelemetry/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cap-js%2Ftelemetry/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cap-js","download_url":"https://codeload.github.com/cap-js/telemetry/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":237834601,"owners_count":19373757,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cap","cds","nodejs","observability","open-telemetry","opentelemetry","sap-btp","sap-cap"],"created_at":"2024-09-26T07:02:10.666Z","updated_at":"2025-10-23T13:30:50.843Z","avatar_url":"https://github.com/cap-js.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Welcome to @cap-js/telemetry\n\n[![REUSE status](https://api.reuse.software/badge/github.com/cap-js/telemetry)](https://api.reuse.software/info/github.com/cap-js/telemetry)\n\n\n\n\u003e [!WARNING]\n\u003e [OpenTelemetry SDK 2.0](https://github.com/open-telemetry/opentelemetry-js/releases/tag/v2.0.0) is not yet supported.\n\n\n\n## About This Project\n\n`@cap-js/telemetry` is a CDS plugin providing observability features, including [automatic OpenTelemetry instrumentation](https://opentelemetry.io/docs/concepts/instrumentation/automatic).\n\nDocumentation can be found at [cap.cloud.sap](https://cap.cloud.sap/docs) and [opentelemetry.io](https://opentelemetry.io/docs).\n\n\n\n## Table of Contents\n\n- [About This Project](#about-this-project)\n- [Requirements](#requirements)\n- [Setup](#setup)\n- [Telemetry Signals](#telemetry-signals)\n  - [Traces](#traces)\n  - [Metrics](#metrics)\n  - [Logs](#logs)\n- [Predefined Kinds](#predefined-kinds)\n  - [`telemetry-to-console`](#telemetry-to-console)\n  - [`telemetry-to-dynatrace`](#telemetry-to-dynatrace)\n  - [`telemetry-to-cloud-logging`](#telemetry-to-cloud-logging)\n  - [`telemetry-to-jaeger`](#telemetry-to-jaeger)\n  - [`telemetry-to-otlp`](#telemetry-to-otlp)\n- [Detailed Configuration Options](#detailed-configuration-options)\n  - [Configuration Pass Through](#configuration-pass-through)\n  - [Instrumentations](#instrumentations)\n  - [Sampler](#sampler)\n  - [Propagators](#propagators)\n  - [Exporters](#exporters)\n  - [High Resolution Timestamps (beta)](#high-resolution-timestamps-beta)\n  - [Environment Variables](#environment-variables)\n- [Custom Spans (beta)](#custom-spans-beta)\n- [Support, Feedback, Contributing](#support-feedback-contributing)\n- [Code of Conduct](#code-of-conduct)\n- [Licensing](#licensing)\n\n\n\n## Requirements\n\nSee [Getting Started](https://cap.cloud.sap/docs/get-started) on how to jumpstart your development and grow as you go with SAP Cloud Application Programming Model.\n\n\n\n## Setup\n\nSimply add `@cap-js/telemetry` to your dependencies via `npm add @cap-js/telemetry` and you will find telemetry output written to the console like so:\n\n```\n[odata] - GET /odata/v4/processor/Incidents \n[telemetry] - elapsed times:\n    0.00 →   2.85 =   2.85 ms  GET /odata/v4/processor/Incidents\n    0.47 →   1.24 =   0.76 ms    ProcessorService - READ ProcessorService.Incidents\n    0.78 →   1.17 =   0.38 ms      db - READ ProcessorService.Incidents\n    0.97 →   1.06 =   0.09 ms        @cap-js/sqlite - prepare SELECT json_object('ID',ID,'createdAt',createdAt,'creat…\n    1.10 →   1.13 =   0.03 ms        @cap-js/sqlite - stmt.all SELECT json_object('ID',ID,'createdAt',createdAt,'crea…\n    1.27 →   1.88 =   0.61 ms    ProcessorService - READ ProcessorService.Incidents.drafts\n    1.54 →   1.86 =   0.32 ms      db - READ ProcessorService.Incidents.drafts\n    1.74 →   1.78 =   0.04 ms        @cap-js/sqlite - prepare SELECT json_object('ID',ID,'DraftAdministrativeData_Dra…\n    1.81 →   1.85 =   0.04 ms        @cap-js/sqlite - stmt.all SELECT json_object('ID',ID,'DraftAdministrativeData_Dr…\n```\n\nSee [Predefined Kinds](#predefined-kinds) for additional dependencies you need to bring yourself as well as some additional setup steps you need to perform when exporting to Dynatrace, SAP Cloud Logging, Jaeger, etc.\n\nThe plugin can be disabled by setting environment variable `NO_TELEMETRY` to something truthy.\n\nDatabase tracing is limited to [@cap-js/cds-dbs](https://github.com/cap-js/cds-dbs)-based databases, such as [@cap-js/sqlite](https://www.npmjs.com/package/@cap-js/sqlite) and [@cap-js/hana](https://www.npmjs.com/package/@cap-js/hana).\n\n\n\n## Telemetry Signals\n\nThere are three categories of telemetry data, also referred to as _signals_.\nThe following briefly describes, how each is addressed in `@cap-js/telemetry`.\n\nFor more information on signals in general, please refer to https://opentelemetry.io/docs/concepts/signals.\n\n\n### Traces\n\nTraces allow you to analyze how a request, message, task, etc. is being processed throughout your distributed system.\nFor this, `@cap-js/telemetry` wraps all essential functions of `cds.Service` and its derivates.\nFor @cap-js databases (e.g., `@cap-js/sqlite`), this includes `prepare()` and subsequent `stmt.run()` and the likes.\n\nExample trace in Dynatrace:\n![Example trace in Dynatrace](docs/dynatrace.png)\n\nAn example trace printed to the console can be found in [`telemetry-to-console`](#telemetry-to-console).\n\nIn environments where Dynatrace OneAgent is installed (e.g., SAP BTP CF), no OpenTelemetry exporter is needed to transport the traces to Dynatrace.\n`@cap-js/telemetry` recognizes this and ignores any exporter config if the predefined kind [`telemetry-to-dynatrace`](#telemetry-to-dynatrace) is used.\n\n\n### Metrics\n\nMetrics are \"measurements captured at runtime\", which help you understand your app's health and performance.\n\nThe `@cap-js/telemetry` enables the observation of some metrics out of the box. \nThese include generic [`@opentelemetry/host-metrics`](https://www.npmjs.com/package/@opentelemetry/host-metrics) (if the package is found in the app's dependencies), \nmetrics regarding the app's database pool, namely the [pool info](https://www.npmjs.com/package/generic-pool#pool-info) statistics of `generic-pool`,\nas well as metrics regarding [CAP's Persistent Queue](https://cap.cloud.sap/docs/node.js/queue#persistent-queue).\n\n#### Host Metrics\n\nCurrently, there is no public config option to influence which metrics `@opentelemetry/host-metrics` collects.\nHowever, it is possible to instruct the meter provider during initialization, which metrics shall be ignored.\nBy default, this is done for all `system.*` metrics collected by `@opentelemetry/host-metrics`.\nThis can be disabled via environment variable `HOST_METRICS_RETAIN_SYSTEM=true`.\nAs these so-called *views* must be passed into the constructor, the above only applies in case `@cap-js/telemetry` initializes the meter provider.\n\nTo avoid spamming the console, only `process.*` metrics are printed by default, regardless of whether the `system.*` metrics are ignored or not.\nPrinting the `system.*` metrics (if not ignored) in the built-in console exporter can be enabled via environment variable `HOST_METRICS_LOG_SYSTEM=true`.\n\n##### Example `host metrics` outputs:\n\n```\n[telemetry] - host metrics:\n  Process Cpu time in seconds: { user: 1691.832, system: 218.223 }\n  Process Cpu usage time 0-1: { user: 82.07801878654074, system: 10.586932682237526 }\n  Process Memory usage in bytes: 141049856\n```\n\n#### Database Pool\n\nThe collection of `db.pool` metrics, can be disabled by setting `cds.requires.telemetry.metrics._db_pool` to `false`.\nPlease note, that the specific name and structure of this option should be considered `beta` and may well be subject to future change.\n\n##### Example `db.pool` output:\n\n```\n[telemetry] - db.pool:\n     size | available | pending\n      1/1 |       1/1 |       0\n```\n\n#### Queue\n\nTo capture measurements about CAP's persistent queue, interactions with and the current status of the relevant database table - `cds.outbox.Messages` - are observed.\nThe interaction-based metrics `incoming` and `outgoing` are observed per app instance, whereas the table-based metrics `cold`, `remaining` and `* storage times` are observed per database (but by each app instance, nevertheless).\nObservation for a specific queued service starts, once a message targeting that service is queued for the first time.\nAll observations of storage times are measured in seconds.\n\nThe collection of `queue` metrics, can be disabled by setting `cds.requires.telemetry.metrics._queue` to `false`.\nPlease note, that the specific name and structure of this option should be considered `beta` and may well be subject to future change.\nFurther, `queue` metrics are only available when using `@sap/cds \u003e= 9`.\n\n##### Example `queue` output:\n\n```\n[telemetry] - queue:\n     cold | remaining | min storage time | med storage time | max storage time | incoming | outgoing\n        2 |        32 |                2 |               16 |              128 |      256 |      512 \n```\n\n#### Custom Metrics\n\nFinally, custom metrics can be added as shown in the following example (tenant-aware request counting):\n```js\n// server.js\n\nconst cds = require('@sap/cds')\n\nlet counter\ncds.middlewares.add((req, _, next) =\u003e {\n  counter.add(1, { 'sap.tenancy.tenant_id': cds.context.tenant })\n  next()\n})\ncds.on('listening', () =\u003e {\n  const { metrics } = require('@opentelemetry/api')\n  const meter = metrics.getMeter('@capire/incidents:req.counter')\n  counter = meter.createCounter('req.counter')\n})\n\nmodule.exports = cds.server\n```\n\n\n### Logs\n\nExporting logs via OpenTelemetry is supported as an experimental opt-in feature.\nEnable it by adding section `logging` to `cds.requires.telemetry` as follows (using `grpc` as an example):\n```json\n\"logging\": {\n  \"exporter\": {\n    \"module\": \"@opentelemetry/exporter-logs-otlp-grpc\",\n    \"class\": \"OTLPLogExporter\"\n  }\n}\n```\n`cds.log()`'s custom fields configuration for SAP Cloud Logging determines the additional attributes added to the `LogRecord`.\nSee [`cds.log()` - Custom Fields](https://cap.cloud.sap/docs/node.js/cds-log#custom-fields) for details.\n\nPlease note that in order for logs to be exported via OpenTelemetry, `cds.log()`'s JSON log formatter must be active, which is the default in production but not in development.\n\n\n\n## Predefined Kinds\n\nThere are five predefined kinds as follows:\n\n\n### `telemetry-to-console`\n\nPrints traces and metrics to the console as previously depicted (traces in [Setup](#setup) and metrics in [Telemetry Signals - Metrics](#metrics)).\n\nNo additional dependencies are needed.\nThis is the default kind in both development and production.\n\n\n### `telemetry-to-dynatrace`\n\nExports traces and metrics to Dynatrace.\nHence, a Dynatrace instance is required and the app must be bound to that Dynatrace instance.\n\nUse via `cds.requires.telemetry.kind = 'to-dynatrace'`.\n\nRequired additional dependencies:\n- `@opentelemetry/exporter-trace-otlp-proto` (optional, see [Leveraging Dynatrace OneAgent](#leveraging-dynatrace-oneagent))\n- `@opentelemetry/exporter-metrics-otlp-proto`\n\nThe necessary scopes for exporting traces (`openTelemetryTrace.ingest`) and metrics (`metrics.ingest`) are not part of the standard `apitoken` and must be requested.\nThis can be done via parameterizing the binding to a \"managed service instance\" (i.e., not a user-provided service instance) as follows.\n\nExcerpt from example mta.yaml:\n```yaml\nrequires:\n  - name: my-dynatrace-instance\n    parameters:\n      config:\n        tokens:\n          - name: ingest_apitoken #\u003e default lookup name, configurable via cds.requires.telemetry.token_name\n            scopes:\n              - openTelemetryTrace.ingest\n              - metrics.ingest\n```\n\nIn the user-provided service case, you'll need to generate a token in Dynatrace with the necessary scopes, add it to the credentials of the user-provided service, and configure `cds.requires.telemetry.token_name` if the token's key in the credentials object is not `ingest_apitoken`.\n\nIn Dynatrace itself, you need to ensure that the following two features are enabled:\n1. OpenTelemetry Node.js Instrumentation agent support:\n    - From the Dynatrace menu, go to Settings \u003e Preferences \u003e OneAgent features.\n    - Find and turn on OpenTelemetry Node.js Instrumentation agent support.\n2. W3C Trace Context:\n    - From the Dynatrace menu, go to Settings \u003e Server-side service monitoring \u003e Deep monitoring \u003e Distributed tracing.\n    - Turn on Send W3C Trace Context HTTP headers.\n\n#### Leveraging Dynatrace OneAgent\n\nIf [Dynatrace OneAgent](https://www.dynatrace.com/platform/oneagent) is present, for example on SAP BTP CF, it will collect and transport the traces created by `@cap-js/telemetry` automatically.\n(Your app still needs to be bound to a Dynatrace instance, of course. However, `@dynatrace/oneagent-sdk` is not required.)\nHence, additional dependency `@opentelemetry/exporter-trace-otlp-proto` and scope `openTelemetryTrace.ingest` are not required.\n\nPlease note, however, that Dynatrace only exports traces triggered by incoming HTTP requests.\nThat is, traces for background tasks started by `cds.spawn`, for example, would not be exported.\n\nIf dependency `@opentelemetry/exporter-trace-otlp-proto` is present anyway, `@cap-js/telemetry` will export the traces via OpenTelemetry as well.\n\n\n### `telemetry-to-cloud-logging`\n\nExports traces and metrics to SAP Cloud Logging.\nHence, a SAP Cloud Logging instance is required and the app must be bound to that SAP Cloud Logging instance.\n\nUse via `cds.requires.telemetry.kind = 'to-cloud-logging'`.\n\nRequired additional dependencies:\n- `@grpc/grpc-js`\n- `@opentelemetry/exporter-trace-otlp-grpc`\n- `@opentelemetry/exporter-metrics-otlp-grpc`\n\nIn order to receive OpenTelemetry credentials in the binding to the SAP Cloud Logging instance, you need to include the following configuration while creating the SAP Cloud Logging instance (or by updating an existing instance):\n```json\n{\n  \"ingest_otlp\": {\n    \"enabled\": true\n  }\n}\n```\n\nIf you are binding your app to SAP Cloud Logging via a [user-provided service instance](https://docs.cloudfoundry.org/devguide/services/user-provided.html), make sure that it has either tag `cloud-logging` or `Cloud Logging`.\n\n### `telemetry-to-jaeger`\n\nExports traces to Jaeger.\n\nUse via `cds.requires.telemetry.kind = 'to-jaeger'`.\n\nRequired additional dependencies (As Jaeger does not support metrics, only a trace exporter is needed.):\n- `@opentelemetry/exporter-trace-otlp-proto`\n\nProvide custom credentials like so:\n```jsonc\n{\n  \"cds\": {\n    \"requires\": {\n      \"telemetry\": {\n        \"kind\": \"to-jaeger\",\n        \"tracing\": {\n          \"exporter\": {\n            \"config\": { //\u003e this object is passed into constructor as is\n              // add credentials here as decribed in\n              // https://www.npmjs.com/package/@opentelemetry/exporter-trace-otlp-proto\n            }\n          }\n        }\n      }\n    }\n  }\n}\n```\n\nRun Jaeger locally via [docker](https://www.docker.com):\n- Run `docker run -d --name jaeger -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 -e COLLECTOR_OTLP_ENABLED=true -p 6831:6831/udp -p 6832:6832/udp -p 5778:5778 -p 16686:16686 -p 4317:4317 -p 4318:4318 -p 14250:14250 -p 14268:14268 -p 14269:14269 -p 9411:9411 jaegertracing/all-in-one:latest`\n    - With this, no custom credentials are needed\n- Open `localhost:16686` to see the traces\n\n\n### `telemetry-to-otlp`\n\nExports traces and metrics to an OTLP/gRPC or OTLP/HTTP endpoint based on [environment variables](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter).\n\nUse via `cds.requires.telemetry.kind = 'to-otlp'`.\n\nRequired additional dependencies (`* = grpc|proto|http`):\n- `@grpc/grpc-js` (in case of OTLP/gRPC)\n- `@opentelemetry/exporter-trace-otlp-*`\n- `@opentelemetry/exporter-metrics-otlp-*`\n\nPlease note that `@cap-js/telemetry` does not validate the configuration via environment variables!\n\n\n\n## Detailed Configuration Options\n\n\n### Configuration Pass Through\n\nIn general, you can influence the configuration of a used module via the respective `config` node in `cds.env.requires.telemetry`.\nFor example, it is possible to specify the `temporalityPreference` setting of the respective metrics exporter like so:\n```jsonc\n{\n  \"cds\": {\n    \"requires\": {\n      \"telemetry\": {\n        \"metrics\": {\n          \"exporter\": {\n            \"config\": { //\u003e this object is passed into constructor as is\n              \"temporalityPreference\": \"DELTA\"\n            }\n          }\n        }\n      }\n    }\n  }\n}\n```\n\n\n### Instrumentations\n\nConfigure via `cds.requires.telemetry.instrumentations = { \u003cname\u003e: { module, class, config? } }`\n\nDefault:\n```json\n{\n  \"http\": {\n    \"module\": \"@opentelemetry/instrumentation-http\",\n    \"class\": \"HttpInstrumentation\"\n  }\n}\n```\n\n\n### Sampler\n\nConfigure via `cds.requires.telemetry.tracing.sampler = { kind, root?, ratio?, ignoreIncomingPaths? }`\n\nDefault:\n```json\n{\n  \"kind\": \"ParentBasedSampler\",\n  \"root\": \"AlwaysOnSampler\",\n  \"ignoreIncomingPaths\": [\n    \"/health\"\n  ]\n}\n```\n\n\n### Propagators\n\nConfigure via `cds.requires.telemetry.tracing.propagators = [\u003cname\u003e | { module, class, config? }]`\n\nDefault:\n```json\n[\"W3CTraceContextPropagator\"]\n```\n\n\n### Exporters\n\nConfigure via:\n- `cds.requires.telemetry.tracing.exporter = { module, class, config? }`\n- `cds.requires.telemetry.metrics.exporter = { module, class, config? }`\n\nDefault:\n```json\n{\n  {\n    \"kind\": \"telemetry-to-console\",\n    \"tracing\": {\n      \"module\": \"@cap-js/telemetry\",\n      \"class\": \"ConsoleSpanExporter\"\n    },\n    \"metrics\": {\n      \"module\": \"@cap-js/telemetry\",\n      \"class\": \"ConsoleMetricExporter\"\n    }\n  },\n  {\n    \"kind\": \"telemetry-to-dynatrace\",\n    \"tracing\": {\n      \"exporter\": {\n        \"module\": \"@opentelemetry/exporter-trace-otlp-proto\",\n        \"class\": \"OTLPTraceExporter\"\n      }\n    },\n    \"metrics\": {\n      \"exporter\": {\n        \"module\": \"@opentelemetry/exporter-metrics-otlp-proto\",\n        \"class\": \"OTLPMetricExporter\"\n      }\n    }\n  },\n  {\n    \"kind\": \"telemetry-to-cloud-logging\",\n    \"tracing\": {\n      \"exporter\": {\n        \"module\": \"@opentelemetry/exporter-trace-otlp-grpc\",\n        \"class\": \"OTLPTraceExporter\"\n      }\n    },\n    \"metrics\": {\n      \"exporter\": {\n        \"module\": \"@opentelemetry/exporter-metrics-otlp-grpc\",\n        \"class\": \"OTLPMetricExporter\"\n      }\n    }\n  },\n  {\n    \"kind\": \"telemetry-to-jaeger\",\n    \"tracing\": {\n      \"exporter\": {\n        \"module\": \"@opentelemetry/exporter-trace-otlp-proto\",\n        \"class\": \"OTLPTraceExporter\"\n      }\n    }\n  }\n}\n```\n\n#### Some Alternative Exporters\n\n1. For JSON output to the console, use:\n    ```json\n    {\n      \"tracing\": {\n        \"exporter\": {\n          \"module\": \"@opentelemetry/sdk-trace-base\",\n          \"class\": \"ConsoleSpanExporter\"\n        }\n      },\n      \"metrics\": {\n        \"exporter\": {\n          \"module\": \"@opentelemetry/sdk-metrics\",\n          \"class\": \"ConsoleMetricExporter\"\n        }\n      }\n    }\n    ```\n1. For HTTP, use:\n    ```json\n    {\n      \"tracing\": {\n        \"exporter\": {\n          \"module\": \"@opentelemetry/exporter-trace-otlp-http\",\n          \"class\": \"OTLPTraceExporter\"\n        }\n      },\n      \"metrics\": {\n        \"exporter\": {\n          \"module\": \"@opentelemetry/exporter-metrics-otlp-http\",\n          \"class\": \"OTLPMetricExporter\"\n        }\n      }\n    }\n    ```\n\n\n### High Resolution Timestamps (beta)\n\nBy default, the start time of a span is taken from `Date.now()` and, hence, has only millisecond resolution.\nVia `cds.requires.telemetry.tracing.hrtime = true`, you can instruct the plugin to specify the start and end times of spans, which it does with nanosecond resolution.\nThis may result in minor drifts, especially for spans created by other instrumentations such as `@opentelemetry/instrumentation-http`.\nHence, the `hrtime` mode is on by default in development but not in production.\n\n\n### Environment Variables\n\n- `NO_TELEMETRY`: Disables the plugin\n- `NO_LOCATE`: Disables function location in tracing\n- `SAP_PASSPORT`: Enables propagating W3C trace context to SAP HANA (experimental!)\n- `OTEL_LOG_LEVEL`: If not specified, the log level of cds logger `telemetry` is used\n- `OTEL_SERVICE_NAME`: If not specified, the name is determined from package.json (defaulting to \"CAP Application\")\n- `OTEL_SERVICE_VERSION`: If not specified, the version is determined from package.json (defaulting to \"1.0.0\")\n\nFor the complete list of environment variables supported by OpenTelemetry, see [Environment Variable Specification](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables).\n\nPlease note that `process.env.VCAP_APPLICATION` and `process.env.CF_INSTANCE_GUID`, if present, are used to determine some [Attributes](https://opentelemetry.io/docs/specs/otel/common/#attribute).\n\n\n\n## Custom Spans (beta)\n\nCustom spans can be added to the trace hierarchy via [`tracer.startActiveSpan()`](https://open-telemetry.github.io/opentelemetry-js/interfaces/_opentelemetry_api._opentelemetry_api.Tracer.html#startactivespan).\nFor this, you need to create your own tracer via [TraceAPI.getTracer()](https://open-telemetry.github.io/opentelemetry-js/classes/_opentelemetry_api._opentelemetry_api.TraceAPI.html#gettracer).\n\n\n\n## Support, Feedback, Contributing\n\nThis project is open to feature requests/suggestions, bug reports etc. via [GitHub issues](https://github.com/cap-js/telemetry/issues). Contribution and feedback are encouraged and always welcome. For more information about how to contribute, the project structure, as well as additional contribution information, see our [Contribution Guidelines](CONTRIBUTING.md).\n\n\n\n## Code of Conduct\n\nWe as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone. By participating in this project, you agree to abide by its [Code of Conduct](https://github.com/cap-js/.github/blob/main/CODE_OF_CONDUCT.md) at all times.\n\n\n## Licensing\n\nCopyright 2023 SAP SE or an SAP affiliate company and contributors. Please see our [LICENSE](LICENSE) for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available [via the REUSE tool](https://api.reuse.software/info/github.com/cap-js/telemetry).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcap-js%2Ftelemetry","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcap-js%2Ftelemetry","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcap-js%2Ftelemetry/lists"}