You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Need support for multiple license keys in the Instrumentation Custom Resource (CR) for teams to send APM data to their respective New Relic accounts.
Desired Behavior
Currently, the Instrumentation Custom Resource (CR) only allows for a single license key to be specified, which is fine for single-account setups. However, in a multi-team environment, where each team uses a different New Relic account with its own license key, this approach doesn’t work. We need a way for the CR to support multiple license keys so that product teams can push APM data to their respective New Relic accounts, while the infrastructure team manages the New Relic Agent Operator and the NRI bundle.
Key Points:
-> Multiple teams, each with its own New Relic account, need to send telemetry data.
-> The infrastructure team installs the NRI bundle and Agent Operator once, but each product team needs to send APM data using their specific license key.
-> The current CR doesn’t allow for multiple license keys, causing a problem where teams can't send data to their accounts.
-> A solution that allows specifying multiple licenseKeySecret entries or dynamically associating telemetry data with the correct account would be ideal.
Possible Argument
--> There can be an argument suggesting this custom resource should be deployed in each namespace ( fulfills our use case because each team have there own dedicated namespace ) and then they can pass whatever licensekeysecret in there CR, not sure if this should be preferred way.
Possible Solution with existing setup
--> Do you recommend we deploy this CR dedicated to a service and pass licensekey to it? For eg in dev namespace lets say we deploy web, app and db as 3 pods.. we can create three crs, like web-cr , app-cr and db-cr and can mention that web-cr should only watch web pod and send telemetry data. This was it can be achieved as well..
Let me know if my understanding in incorrect.
The text was updated successfully, but these errors were encountered:
Summary
Need support for multiple license keys in the Instrumentation Custom Resource (CR) for teams to send APM data to their respective New Relic accounts.
Desired Behavior
Currently, the Instrumentation Custom Resource (CR) only allows for a single license key to be specified, which is fine for single-account setups. However, in a multi-team environment, where each team uses a different New Relic account with its own license key, this approach doesn’t work. We need a way for the CR to support multiple license keys so that product teams can push APM data to their respective New Relic accounts, while the infrastructure team manages the New Relic Agent Operator and the NRI bundle.
Key Points:
-> Multiple teams, each with its own New Relic account, need to send telemetry data.
-> The infrastructure team installs the NRI bundle and Agent Operator once, but each product team needs to send APM data using their specific license key.
-> The current CR doesn’t allow for multiple license keys, causing a problem where teams can't send data to their accounts.
-> A solution that allows specifying multiple licenseKeySecret entries or dynamically associating telemetry data with the correct account would be ideal.
Possible Argument
--> There can be an argument suggesting this custom resource should be deployed in each namespace ( fulfills our use case because each team have there own dedicated namespace ) and then they can pass whatever licensekeysecret in there CR, not sure if this should be preferred way.
Possible Solution with existing setup
--> Do you recommend we deploy this CR dedicated to a service and pass licensekey to it? For eg in dev namespace lets say we deploy web, app and db as 3 pods.. we can create three crs, like web-cr , app-cr and db-cr and can mention that web-cr should only watch web pod and send telemetry data. This was it can be achieved as well..
Let me know if my understanding in incorrect.
The text was updated successfully, but these errors were encountered: