Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: update metric naming spec #984

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

nkomonen-amazon
Copy link
Contributor

Problem

We do not have a clear defined format for metric names.

Solution

Update the doc that defines how to name a metric.

  • This will NOT retroactively apply to all existing metrics since this will require significant work refactoring that we do not want to do at the moment.

  • The benefits of this new structure {namespace}_{noun}{Verb} are that it will group related metrics in the definitions file since they are alphabetically ordered. Also when getting IDE completions all relevant options will be grouped together. This should help for searchability/reusability.

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

See changes for the new spec when it comes to metric naming.

- This will NOT retroactively apply to all existing metrics since this will require significant
  work refactoring that we do not want to do at the moment.

Signed-off-by: nkomonen-amazon <[email protected]>
@nkomonen-amazon nkomonen-amazon requested a review from a team as a code owner February 26, 2025 17:50
what the metric actually means and how it should be used.
- `metadata` contains data from `types` that define characteristics of the telemetry beyond
`createTime` and a `value`.
- This field is optional, but default `types` are automatically added regardless.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know they are called types but I imagine this will be confusing to read.

Suggested change
- This field is optional, but default `types` are automatically added regardless.
- This field is optional, but default fields (`types`) are always present on generated metrics.

- Common Namespaces:
- `toolkit_` is for general non-feature-specific metrics created by the toolkit. Eg: `toolkit_moduleOpen`
- `ide_` is for IDE specific metrics, not controlled by our extension. Eg: `ide_editorOpen`
- NOTE: due to legacy reasons the above spec may not be followed, but all future definitions must follow it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- NOTE: due to legacy reasons the above spec may not be followed, but all future definitions must follow it.
- NOTE: legacy metrics don't always follow the above rules, but new definitions must follow it.

Comment on lines 38 to 39
- put effort to explaining the metrics purpose in detail. This tends to be the source of truth for
what the metric actually means and how it should be used.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. This is also the only way we have to signal "deprecated", currently.

_metrics_ is an array that contains the actual metrics posted to the service.
- `name` defines the metric name
- it must be in the format `namespace_camelCaseName` (e.g. `s3_objectUpload`).
- it must be in the format `{namespace}_{noun}{Verb}` (eg: `toolkit_moduleInit`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add some indented points explaining the rationale? As reviewers we will want to be able to link to this section of the doc to avoid repetition and pushback.

Signed-off-by: nkomonen-amazon <[email protected]>
- This format enables a natural grouping of related metrics in our definitions file, as well as improved searchability.
- Common Namespaces:
- `toolkit_` is for general non-feature-specific metrics created by the toolkit. Eg: `toolkit_moduleOpen`
- `ide_` is for IDE specific metrics, not controlled by our extension. Eg: `ide_editorOpen`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we also add an entry for ui_click?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you mean specifically?

IIUC we semi-agreed in a previous slack thread that with this new spec, toolkit_uiClick would technically be the name that we go with if it didn't already exist

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants