[GitHub] [incubator-skywalking] wu-sheng commented on issue #2322: How to make receiver settings more reasonable

[GitBox <gi...@apache.org>]

wu-sheng commented on issue #2322: How to make receiver settings more reasonable
URL: https://github.com/apache/incubator-skywalking/issues/2322#issuecomment-470923616
 
 
   I am thinking of something else than the principle. 
   
   I think we can't say `turn on` agent only is the right call, because, in our document, we call ourself observability analysis platform and have capabilities to process and visualize multiple formats. We started the project by javaagent, doesn't mean it must be agent working, especially we have other languages. As far as I known, @liuhaoyang will provide .NET CLR receiver soon, maybe in 6.1.0
   
   But we can say one thing, we could run in multiple scenarios
   1. Language agent.
   1. Service Mesh.
   1. Envoy.
   1. Zipkin
   
   In these three modes, we have certain receivers and `application.yml`, right? Could we consider to deliver different startup scripts to run in different modes?
   - `startup-in-language-agent-mode.sh`, Trace, JVM, CLR, register on.
   - `startup-in-mesh-mode.sh`, istio, mesh, envoy, register on.
   - `startup-in-proxy-mode.sh`, only envoy on.
   - `startup-in-zipkin.sh`,  zipkin and trace on.
   
   And, with
   - `startup-all.sh` with all receivers on(only turn zipkin-off, because it is not production ready, this is a clear principle). This is for quick-start and docker entry.
   
   If we have this, we could have a clear document why we open these receiver, and which scenario requests us to open.
   
   
   

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services