Enable telemetry control from env vars #605
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Enables this client to support logs, metrics, and tracing signals from the diagnostics-nodejs library, making them available already initialized. Additionally, this change enables registration of built-in and community instrumentation.
Remove unused parameters and use logClient already initialized
Refactor client types to use Types.LogClient for consistency
Improve telemetry client initialization using Promise.all to optimize asynchronous calls
Adds OpenTelemetry dependencies for host metrics and Koa instrumentation
Updates startApp function to initialize telemetry beforehand and uses dynamic imports for startMaster and startWorker. This ensures that telemetry clients and libraries are proper initialized so they can use hooks with application libraries that will be loaded later
Add getMetricClient function to make the client available and creates the asynchronous initialization function to retrieve it
This commit creates a middleware for request metrics using OpenTelemetry instruments. This change is inspired by `requestMetricsMiddleware.ts` and follows the same logic, only changing the way it is instrumented to use OTel standard
Add the use of OpenTelemetry metrics middleware for request monitoring
Add Koa instrumentation to the list of instruments that will be registered and used by the telemetry client. This enables automatic instrumentation for the Koa module, as well as automatic collection and export of telemetry data.
This commit creates a wrapper for the host-metrics module, which provides automatic collection for system metrics - such as CPU, memory, and network
Refactors the instrument initialization logic to improve readability and code structure
Refactor MetricClient to use Singleton pattern for improved client management
Refactor OTel instruments initialization to use singleton pattern
This commit creates new constants based on environment variables that will be used to proper configure diagnostics-nodejs on node-vtex-api
Make the new constants available on clients.ts file, which is responsible for create telemetry client.
This commit replaces and updates the telemetry clients to utilize the OTEL_EXPORTER_OTLP_ENDPOINT constant for exporting telemetry data
Small change on parameter to follow o11y team guidelines regarding this field
Updates parameters on telemetry client creation, making use of APPLICATION_ID and adding new additional attributes. Also, we remove unused constant CLIENT_NAME.
This update adds console logging for diagnostics configuration and checks if telemetry is enabled before registering instrumentations. It ensures that the telemetry client operates correctly based on the DIAGNOSTICS_TELEMETRY_ENABLED constant. Also, whenever the app vendor is not enabled it will use a no-op client for diagnostics, meaning any telemetry signal will be ignored
daniyelnnr
requested review from
arturpimentel,
filafb,
iagoaraujo,
juliobguedes and
silvadenisaraujo
|
Depends on #596 |
silvadenisaraujo
approved these changes
Sep 3, 2025
| const telemetryClient = await NewTelemetryClient( | ||
| APPLICATION_ID, | ||
| CLIENT_NAME, | ||
| DK_APP_ID, |
There was a problem hiding this comment.
Wha is the role of this DK app id here?
There was a problem hiding this comment.
This was a request from o11y team, the proper identifier for this first parameter should be the DK app id instead of the composite id (vendor, app name and version) that we were using here - that's the reason why I opened #602 and proper onboard node-vtex-api.
This change modifies the DK_APP_ID constant to default to 'apps-team' instead of 'apps'
Replace negative warning message when telemetry is disabled with positive confirmation message when enabled. This change aligns with the principle of treating disabled telemetry as the default state.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the purpose of this pull request?
This pull request updates the diagnostics integration to improve configuration flexibility and control over telemetry behavior.
What problem is this solving?
The main changes include upgrading the diagnostics package, introducing new environment-based configuration options, and ensuring telemetry can be conditionally enabled or disabled.
Summary of the changes
Telemetry configuration and control:
@vtex/diagnostics-nodejsdependency to version0.1.0-io-beta.20inpackage.jsonfor latest telemetry features and bug fixes.src/constants.tsto control telemetry:OTEL_EXPORTER_OTLP_ENDPOINT(endpoint for telemetry exporter),DK_APP_ID(application ID override), andDIAGNOSTICS_TELEMETRY_ENABLED(flag to enable/disable telemetry via environment variable).Telemetry client initialization improvements:
src/service/telemetry/client.tsto use the new constants for exporter endpoint and app ID, and to pass anoopflag to disable telemetry whenDIAGNOSTICS_TELEMETRY_ENABLEDis false. Also logs a warning when telemetry is disabled. [1] [2] [3]Logger initialization:
initLogClientis always called in theLoggerconstructor insrc/service/logger/logger.ts, aligning with the updated telemetry client logic.How should this be manually tested?
Screenshots or example usage
Types of changes