Open csantanapr opened 5 years ago
Hi Carlos, this is an issue with the Appsody stack rather than codewind, as the generate application needs to include application metrics to be able to utilize the performance features of codewind.
The java profiler issue has been raised here https://github.com/eclipse/codewind/issues/533 and we are currently investigating it. For the performance dashboard, @AndyRWatson is correct and under the current design, the appsody stack will need to be modified to included the monitoring packages
Open question about use of appmetrics packages vs. having something scrape the existing metrics endpoints. I know that is more than codewind wants to do right now.. but it is more production-like than working with the appmetrics libraries. We've been having this back-and-forth for a long time.
we are working on that right now @ebullient :-) . won't be long
Agreed with above. The stacks shouldn't have 'dropped function' compared with what we had before and that's the short term fix, but we are moving the metrics to scrape any endpoint so it won't be a problem.
Glad to hear that the codewind is moving to discovering the endpoint for prometheus metrics (ie :9102/metrics 9102 is the default prometheus scraping port in k8s) and using the metrics to populate the UI dashboard and grafana will use the same data to populate their dashboard.
In the meant time @AndyRWatson
Hi Carlos, this is an issue with the Appsody stack rather than codewind, as the generate application needs to include application metrics to be able to utilize the performance features of codewind.
the VSCode extension prerequisites https://github.com/eclipse/codewind-java-profiler#prerequisites only mentions A Java Liberty project bound to Codewind.
Maybe is obvious to everyone using liberty and codewind, but it was not to me that a library and configuration for application metrics need to be done in the Liberty project.
Can you add an additional bullet stating the requirement of needs to include application metrics
?
The :9102 port is odd. Most stacks don't surface an extra port for metrics or health checks (which caused quite a stir with Istio.. ). Appsody stacks (and thus codewind) should be working w/ the behavior of the application container, which is != the behavior of prometheus by default.
That was I what I meant codewind needs to work with what the app stack exposes.
Using a different port for health and metrics is a good practice for that same reason you stated to avoid problems with istio when mTLS is enabled.
Also another benefit metrics for liveness, readiness and metrics itself don’t get in the way when you want to do fine grain metrics like connections open and such.
For getting application metrics, you need to use MicroProfile Metrics to emit some metrics. You can simply add some annotations, e.g. @Timed
etc. Refer to this guide for more info.
+1 for Codewind to scrap from metrics endpoint provided by the app (through the stack).
In the Extension description it states to use liberty and to open performance dashboard.
Steps to reproduce: Install codewind extension and codewind-java-profiler in VSCode Create new appsody app using java-microprofile stack
Add appsody app to codewind-workspaces Right click app in codewind app and select "Open Performance Dashboard"
Results: Error message
Menu items "Open Application Monitoring" and "Open Performance Dashboard" no longer show up