wu-sheng commented on pull request #7224: URL: https://github.com/apache/skywalking/pull/7224#issuecomment-872975655
> > Could you give more explanation about what these changes for? What are the benefits for the users? > > SkyWalking never does things according to other projects, such as you said `The main idea comes from "opentelemetry-java-instrumentation".`. We focus on the product and tech parts. > > Ok. I have an ambiguity,sorry. > > In our company, skywalking is a very new concept, so I want to minimize the cost of access. > I can now allow users to click a button to access apm. This is pretty cool, so I am not going to change this approach. > so the [log4j2&logback-automatic-agent] can do this. only one button. (To be precise, you also need to add %X(traceid), but this will not change the POM) > > As for opentelemetry-java-instrumentation, I just borrowed their cut points. (org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector and ch.qos.logback.classic.Logger) > The framework and main logic are based on the definition of skywalking. OK, I can get your points now. But we are very careful to provide a plugin like this. Actually we discussed about this from the day at beginning of the toolkit you see right now. Once we have an auto instrumentation log injection, we face a risk to break user's log analysis system, such as prod env's ELK. Because we inject something breaking the existing pattern, but users would not expect this, as our agent is out of box, people are new to the project. Also, we will have to inject all the logs, rather than the necessary logs which cause unnecessary costs. I am not sure whether these make sense to you, but those are the reasons we don't have this today. -- 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]
