search

Azure / azure-dev

A developer CLI that reduces the time it takes for you to get started on Azure. The Azure Developer CLI (azd) provides a set of developer-friendly commands that map to key stages in your workflow - code, build, deploy, monitor, repeat.
https://aka.ms/azd
MIT License
412 stars 201 forks source link

Telemetry: more usage info #1736

Closed weikanglim closed 1 year ago

weikanglim commented 1 year ago
  1. List of hashed flag names that are set (no user-provided value, just flag names).
  2. List of hashed Languages in services
  3. List of hashed Hosts in service

@savannahostrowski please help note any additional info you'd like collected. It's fairly trivial for us to instrument any new usage attributes, given we have the proper telemetry framework defined for doing it currently. For example, these changes are ~1 day of dev effort, so please help note anything else and we can do a 1-pass.

savannahostrowski commented 1 year ago

This makes sense to me. @esweet431 in case you have other thoughts.

esweet431 commented 1 year ago

Makes sense to me as well - will these be properties on all cmd. events?

Does it make sense to surface the hashed azd environment name as a property as well? That might help us proxy how many "projects" azd is creating without joining to billing data or ARM data. (Side question for my own understanding - is an azd environment tied to a single resource group? or can a single resource group be used by multiple azd environments? I'm looking at the azd-env-name tag defined in infra/main.bicep, which makes me think it's a 1:1 mapping)

savannahostrowski commented 1 year ago

Resource groups map 1:1 with environments. An app could have many environments (and therefore, many RGs).

Also interested in whether they'll be on all events. That's an interesting idea re. env name hashing.

weikanglim commented 1 year ago

We can do all events or just "usage events", which are cmd.*. Generally, it depends on how useful that attribute is.

@savannahostrowski That is certainly true in how we think users can use it. In reality, they could have the same env name mapped to different resources (in azd, this is convention based).

Re: How many "project" azd is creating -- should we just hash the project name?

esweet431 commented 1 year ago

Re: How many "project" azd is creating -- should we just hash the project name?

Where is project name defined? Is it the name field in azure.yaml? If so, then I don't think that will be helpful since it's not unique across projects.

weikanglim commented 1 year ago

@esweet431 Can you clarify what you mean by a project? Users are expected to update the name field for their own application. I would not expect users to run with todo-python-mongo-swa-func for example. It's simply the default name in the templates.

esweet431 commented 1 year ago

@esweet431 Can you clarify what you mean by a project? Users are expected to update the name field for their own application. I would not expect users to run with todo-python-mongo-swa-func for example. It's simply the default name in the templates.

Apologies for the late response. I agree that customers who are actually using the project will (hopefully) rename it, but I wouldn't be surprised if customers leave the template name as they are exploring - especially since up inits/provisions/deploys without asking the user to rename the project.

Does it make sense to hash both env name and project name? If we want to avoid bloat, then env name might be more actionable.