westbigben opened a new issue, #10265: URL: https://github.com/apache/skywalking/issues/10265
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/skywalking/issues?q=is%3Aissue) and found no similar feature requirement. ### Description Dear Apache SW team, Thank you for your support. Now, coming from using New Relic(NR) and intending to migrate over to Apache Skywalking(SW), I have a feature request that I couldn't find in SW that was available in NR. I'm sorry if I'm comparing these two, but that one feature will help me segregate and ease out my microservice deployment. The requirement is: 1. I would keep my agent to be running as default on my docker image. Therefore, all new containers will have the java-agent running and will start streaming data to the SW server. 2. Whichever Microservice I don't want to report into SW, I will just add a run-time JVM option (something like -Dskywalking.agent.enable=false) and therefore, that container won't transmit data to the server. ### Use case Some of my lower environments may not need monitoring, or I may need only few services across staging, pre-prod and prod to write into SW. In which case, the services which I wish were quiet, I can configure the runtime values to use the dynamic configuration option. The other fact is since we use helm to deploy applications, the lower environments' helm charts maybe +1 or +2 versions in comparison to that on production, thereby instead of managing multiple agent.configs or SW servers, it will be good if these can be handled dynamically. So on those instances, if I pass JAVA_OPTS="-javaagent:/skywalking.jar -Dskywalking.agent.disable=false", those service related containers maybe left out from logging data. ### Related issues _No response_ ### Are you willing to submit a PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
