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

telemetry: Adding metrics for amazonq unit test generation #915

Closed
wants to merge 6 commits into from

Conversation

laileni-aws
Copy link
Contributor

Problem

  • No metrics for amazonq unit test generation

Solution

Planning to add 4 metrics for Unit test generation.

  1. amazonq_unitTestGeneration(new)
  2. amazonq_utg_generateTests(new)
  3. amazonq_utg_buildLoop(new)
  4. ui_click(existing)
  • Planning to add a new optional field (step) to ui_click to get metrics on which stage user has clicked a button.

License

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

@laileni-aws laileni-aws marked this pull request as ready for review November 15, 2024 23:29
@laileni-aws laileni-aws requested a review from a team as a code owner November 15, 2024 23:29
Copy link

@mr-lee mr-lee left a comment

Choose a reason for hiding this comment

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

significant concerns with this

"description": "Number of characters of code generated"
},
{
"name": "generatedCount",
Copy link

Choose a reason for hiding this comment

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

this name is unhelpful. why not generatedTestCasesCount?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please refer this PR
Long story short Toolkit want to reuse the fields so the ask is to keep this as generic as possible.

Copy link
Contributor

@justinmk3 justinmk3 Nov 27, 2024

Choose a reason for hiding this comment

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

Each field is "namespaced" in a metric, so there is no need to name each field in a globally-unique way, and it's actually counterproductive (because it results in 10x or 100x the number of field names, which reduces discoverability, re-use, and leads to less-helpful dashboards and queries).

So for example, this field would live on a metric named amazon_foo and so amazonq_foo.generatedCount would clearly be understood based on the metric it is part of.

Copy link
Contributor

Choose a reason for hiding this comment

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

You probably don't need this field, just use the count field:

{
"name": "buildSystemVersion",
"type": "string",
"description": "The build system version on the user's machine"
},
{
"name": "buildZipFileBytes",
Copy link

Choose a reason for hiding this comment

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

what about number of files?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We does not have a field for Number of files and I do not think it adds a value as file can be of any size and number does not define our latency or test generation experience.
Correct me If I am missing something.

"required": false
},
{
"type": "cwsprChatProgrammingLanguage"
Copy link

Choose a reason for hiding this comment

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

why is this a chat programming language?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We planned to reuse existing fields as much as possible. Please refer this PR

"required": false
},
{
"type": "generatedCount",
Copy link

Choose a reason for hiding this comment

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

same comment as above.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is on a metric named amazonq_unitTestGeneration. Can just use the count field:

each field does not need its own namespace; it's already namespaced in a metric.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Follow this suggestion.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sure, but count already exists... when a metric's main topic needs a count, just use the existing count field.

"required": false
},
{
"type": "userEnteredPromptMessage"
Copy link

Choose a reason for hiding this comment

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

you cannot save this as telemetry. This is customer data.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As declared this is boolean, so there is no harm for customer data.

"required": false
},
{
"type": "userEnteredPromptMessage"
Copy link

Choose a reason for hiding this comment

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

This is customer data.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Replied above

"required": false
},
{
"type": "generatedCount",
Copy link
Contributor

Choose a reason for hiding this comment

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

This is on a metric named amazonq_unitTestGeneration. Can just use the count field:

each field does not need its own namespace; it's already namespaced in a metric.

Comment on lines +2412 to +2413
"name": "amazonq_utg_generateTests",
"description": "Client side invocation of the AmazonQ Unit Test Generation",
Copy link
Contributor

Choose a reason for hiding this comment

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

how is this different than amazonq_unitTestGeneration ?

        "name": "amazonq_unitTestGeneration",
       "description": "Client side metrics of AmazonQ Unit Test Generation",

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This will be the E2E metric after Build execution loop

Copy link
Contributor

Choose a reason for hiding this comment

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

That isn't indicated in the description, and still doesn't explain how it's different

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is not being added as part of RIV.

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.

3 participants