That's a great idea! What is the positioning of this feature? If it's designed for development environment trouble-shooting, I guess it's okay the web pages are provided by the micro-service instances directly. But if this feature is expected to work in production environment, which may contains massive micro-service instances, maybe it's better that service instances provide RESTful interfaces, and users get access to these informations via the console service.
Yours sincerely Yao Haishi yhs0...@163.com On 3/5/2019 09:52，wjm wjm<zzz...@gmail.com> wrote： @zhang_lei ServiceComb can run with spring boot, but will not depend on spring boot. wjm wjm <zzz...@gmail.com> 于2019年3月5日周二 上午9:49写道： href of gif: https://issues.apache.org/jira/secure/attachment/12961084/swaggerAndDocument.gif and more question: how to define the security of the new feature should open a new port for the feature? wjm wjm <zzz...@gmail.com> 于2019年3月5日周二 上午9:20写道： currently it's difficult to collect internal status of a microservice instance when some problem happened. eg: routing depend on cached instances, discovery tree, strategy of governances, and so on when we resolving routing related problem, we can only guess the status of all related modules. so we should provide a way to inspect the internal status of a microservice instance at runtime, maybe include: discovery tree isolation eventbus view schemas as swagger or html/pdf...... ...... maybe like the gif: my question: provide these informations include related html/js/css by instance directly, or only by governance console if provide by both instance and governance console, that will cause duplicate development if provide by instance what's the name of the module? "inspector"? swagger to html depend on "asciidoctor", which depend on jruby, it's very heavy. in my demo, resource of swagger and asciidoctor all load from cdn, but for some customer's environment, maybe can not connect to internet. any other idea?
