Feature: Enable Telemetry for TRTMC

[linc-nv]

Request type

New capability

Problem and use case

Enable Telemetry in TRTMC

Goal: collect more info from community developer e.g., company, use case, platform, whether for production or not

Proposed outcome

Give the option to user whether they would like to turn on Telemetry to share more information with TRTMC
Once user enables the Telemetry, TRTMC is able to track how they use TRTMC

Model and target details

Roadmap item for near term

Alternatives considered

No response

Additional context

No response

Submission checks

• I searched open and closed issues and found no duplicate request.
• I removed secrets, private/internal evidence, personal paths, and restricted artifacts.

[Darshan3690]

Hi @linc-nv mam and @yifeif-nv , @chaofengw-nv sir I'd like to work on this — I'm an existing contributor to the repo. Here's a rough design proposal, happy to adjust based on feedback before opening a PR:

Consent model

• Opt-in only (never opt-out). On first run, trtmc prompts interactively for consent; in non-interactive/CI contexts it defaults to disabled.
• Respects the DO_NOT_TRACK=1 convention.
• Consent + collected metadata cached locally in the user config dir so it's only asked once.
• trtmc telemetry enable|disable|status subcommands, plus --telemetry / --no-telemetry flags to override per run.

Data collected

• Anonymous install ID (random UUID, not tied to identity)
• Company (optional free text)
• Use case (small enum + "other")
• Platform / GPU (reused from existing detection code)
• Production vs. experimental flag

Transport

• Async, fire-and-forget POST
• Non-blocking — never delays or breaks a build/run
• Fails silently (debug-level log only) on any network error

Endpoint

• Kept pluggable via env var / config rather than hardcoding an internal collector URL in the OSS code, unless there's already an internal schema/endpoint you'd like me to target.

Could you assign this to me? Also let me know if there's an existing internal spec for the endpoint/schema I should match, or any constraints on what data can be collected.

[yifeif-nv]

Hi @linc-nv mam and @yifeif-nv , @chaofengw-nv sir I'd like to work on this — I'm an existing contributor to the repo. Here's a rough design proposal, happy to adjust based on feedback before opening a PR:

Consent model

• Opt-in only (never opt-out). On first run, trtmc prompts interactively for consent; in non-interactive/CI contexts it defaults to disabled.
• Respects the DO_NOT_TRACK=1 convention.
• Consent + collected metadata cached locally in the user config dir so it's only asked once.
• trtmc telemetry enable|disable|status subcommands, plus --telemetry / --no-telemetry flags to override per run.

Data collected

• Anonymous install ID (random UUID, not tied to identity)
• Company (optional free text)
• Use case (small enum + "other")
• Platform / GPU (reused from existing detection code)
• Production vs. experimental flag

Transport

• Async, fire-and-forget POST
• Non-blocking — never delays or breaks a build/run
• Fails silently (debug-level log only) on any network error

Endpoint

• Kept pluggable via env var / config rather than hardcoding an internal collector URL in the OSS code, unless there's already an internal schema/endpoint you'd like me to target.

Could you assign this to me? Also let me know if there's an existing internal spec for the endpoint/schema I should match, or any constraints on what data can be collected.

Hi @Darshan3690 thanks for interested in this! But we will need to keep this task for NVIDIA engineers as there is obligations on the legal aspect on what data we can collect and what disclosure we need to make.

[Darshan3690]

Hi @linc-nv mam and @yifeif-nv , @chaofengw-nv sir I'd like to work on this — I'm an existing contributor to the repo. Here's a rough design proposal, happy to adjust based on feedback before opening a PR:
Consent model

• Opt-in only (never opt-out). On first run, trtmc prompts interactively for consent; in non-interactive/CI contexts it defaults to disabled.
• Respects the DO_NOT_TRACK=1 convention.
• Consent + collected metadata cached locally in the user config dir so it's only asked once.
• trtmc telemetry enable|disable|status subcommands, plus --telemetry / --no-telemetry flags to override per run.

Data collected

• Anonymous install ID (random UUID, not tied to identity)
• Company (optional free text)
• Use case (small enum + "other")
• Platform / GPU (reused from existing detection code)
• Production vs. experimental flag

Transport

• Async, fire-and-forget POST
• Non-blocking — never delays or breaks a build/run
• Fails silently (debug-level log only) on any network error

Endpoint

• Kept pluggable via env var / config rather than hardcoding an internal collector URL in the OSS code, unless there's already an internal schema/endpoint you'd like me to target.

Could you assign this to me? Also let me know if there's an existing internal spec for the endpoint/schema I should match, or any constraints on what data can be collected.

Hi @Darshan3690 thanks for interested in this! But we will need to keep this task for NVIDIA engineers as there is obligations on the legal aspect on what data we can collect and what disclosure we need to make.

hi @linc-nv , @yifeif-nv , @chaofengw-nv .
Thank you for the reply and for clarifying. I completely understand the legal and data-collection requirements.

I hope that one day I’ll have the opportunity to become an NVIDIA engineer and work with the team under your guidance. Until then, I’ll continue contributing and learning from projects like this.

Thank you again for your time and guidance! 🙏