MP-wide application name?

[Heiko Rupp]

In the good ol' days when little green creatures from Alpha Centauri were still little green creatures from Alpha Centauri,

most of us targeted the specs as the prototypical where 1 app = 1 runtime = 1 server = 1 deployment

Now there are runtimes like OpenLiberty and others using MicroProfile, that can deploy multiple applications.

Within Metrics we are thinking to add application identifiers to the deployments, so that in metrics output

it is possible that multiple apps have the same metric name, but the metrics are still separated into the

scope of the respective application.

One choice is mp.metrics.appName , but we are wondering if that could be something more MicroProfile wide

(OpenApi or OpenTracing probably has the same issue as we).

In this case it could be good to agree on a more top-level property mp.applicationName.

Either choice could be then put into META-INF/microprofile-config.properties and the spec impls

like for metrics could read it from there (via config api) and use it for their purposes.

Obviously setting those via env-Var or system property still has some challenges :-/

Wdyt?

[donbo...@gmail.com]

I'd just say that I don't necessarily even think env-var / system property are challenges -- they address different needs.  In environments where you just have one app in a server you might use env-var to set the application name.  In envs with multiple apps in a server you'd need to configure it per-app via the microprofile-config.properties file.  Both have good use cases.

[Phillip Krüger]

Hi Heiko.

We have been discussing this at the GraphQL weekly meetings recently, and also came to the conclusion that we need to discuss this at a MP Level.

We got this from the OpenAPI Workgroup:

"The 1.0 version of the MicroProfile OpenAPI specification does not define how the /openapi endpoint may be partitioned in the event that the MicroProfile runtime supports deployment of multiple applications. If an implementation wishes to support multiple applications within a MicroProfile runtime, the semantics of the /openapi endpoint are expected to be the logical union of all the applications in the runtime, which would imply merging multiple OpenAPI documents into a single valid document (handling conflicting IDs and unique names)." - https://github.com/eclipse/microprofile-open-api/blob/master/spec/src/main/asciidoc/microprofile-openapi-spec.adoc#55-multiple-applications

Personally I am of the opinion that when you have multiple applications, the MP libs should publish under /${contextRoot}/mp_endpoint, if fact, the spec can say that it should always be /${context_root}/mp_endpoint, and in the case of only one app, your context root is typically / anyway, so then you end up with /mp_endpoint.

I am not sure that we should aggregate things just because they are deployed on the same server, but I guess there would be use-cases where it makes sense. In my head, when deploying to a "traditional" application server, the application server plays the roll of K8n, and thus we should treat it like that. With K8n, apps might be on different IPs where as with application server it's different context roots, but the developer had the intention to treat them separate.

If we take /health as an example, the idea is the the Controller (K8n or Application Server then) can determine the health and decide to restart, in the case of K8n, restart the pod, in the case of application server, restart the app....

Let me know what you think.

Cheers.

Phillip

[Heiko Rupp]

Personally I am of the opinion that when you have multiple applications, the MP libs should publish under /${contextRoot}/mp_endpoint, if fact, the spec can say that it should always be /${context_root}/mp_endpoint, and in the case of only one app, your context root is typically / anyway, so then you end up with /mp_endpoint.

If we take /health as an example, the idea is the the Controller (K8n or Application Server then) can determine the health and decide to restart, in the case of K8n, restart the pod, in the case of application server, restart the app....

Health is like metrics - you have one entry point for the client ("Kubernetes", "Prometheus") to query for all the data of the entire server. You don't want server admins to configure different endpoints (on the same) server depending on all the apps you have deployed.

So here /health/{appName} or /metrics/{appName} is more appropriate (actually we will use labels in  Metrics).

[Alasdair Nottingham]

I don’t really agree. I think the idea of the app server using a REST API to determine if an app is healthy is weird and if I were to use MP Health to make that determination as an app server owner is just make a Java API call. I don’t need to invoke REST. I think the point of doing a REST api is for external things to understand the state of things. Now that doesn’t invalidate your suggestion here, but I think we should look at the usefulness of having the data aggregated vs not aggregated on a JVM by JVM basis. My gut feel is aggregation would be more useful for health and metrics than not. Not sure about openapi, could go either way.

Alasdair Nottingham

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/154bbef8-13c3-434a-9498-8cf42149c256%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ken Finnigan]

For me this is more than just adding support for an application name within MicroProfile.

From Day One we've had the view that there's a single application per "deployment" or "runtime". We want to be very careful about diverging away from that goal.

My view is that MicroProfile isn't necessarily designed to be doing traditional application server type metrics, checks, or anything else.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/C84A22B5-CABC-4A78-96AC-7AEFFD36ED49%40gmail.com.

[Phillip Krüger]

Hi Ken

Not all companies can switch to a runtime like Thorntail immediately, however they still have the need to :

• Understand the health of an app,
• Get the metrics from an app, into some dashboard (via prometheus or something else)
  
• Expose API via JAX-RS and describe them with OpenApi
• Add fault tolerance to their services
• ...and so on

Even though all of this is still on a Traditional Application server. This is a good start to apply the principals of distributed computing, before moving to something like Thorntail, K8n and Docker.

That is why I am suggesting to do this under the context of the application. I get that, for metrics you need to do some more setup to pull in multiple end points, but that still makes the most sense to me.

I also get that the intention for MicroProfile is single application per runtime, but these libraries is still useful in traditional app servers.

Cheers

[Ken Finnigan]

The specifications as it stands can be used per application in a traditional application server.

Changing to include application name appears, to me, to be more about supporting MP specifications being used at the server vs application level, which is where I take issue

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b9ae2b7e-ed6e-47c7-b88e-c74508fad71c%40googlegroups.com.

[Phillip Krüger]

Hi Ken.

Ok so I might have misunderstood you.

So you agree that when using MicroProfile APIs in a traditional app server, it should be under the context of the application ? Also not doing any aggregation as suggested by OpenAPI ?

Cheers

[Ken Finnigan]

Correct.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/33647418-fcb5-43cd-ae28-4c3cf388504f%40googlegroups.com.

[donbo...@gmail.com]

Ken, 

For metrics, what we're envisioning using the app name for is something that looks like this:

Server 1 / App 1:

    connectionPool_managedConnections{datasource="someDatasource", appName="app1"} 25

Server 2 / App 2:

    connectionPool_managedConnections{datasource="someDatasource", appName="app2"} 9

If people don't set an application name for each of their apps then the metric names would not be differentiated, so the metrics would be shared across apps in the server:

Server 1:

    connectionPool_managedConnections{datasource="someDatasource"} 34

The recommendation would be that, for any app server with more than one app, the appName be set in each app (using mpConfig's META-INF/microprofile-config.properties files)

Don

[Ken Finnigan]

I guess I just don't see where the issue is, unless you're aggregating metrics from all applications in a single server into a single view.

And I'm not sure that's something we should support

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ecfbc628-4118-4587-b749-848e26a809cd%40googlegroups.com.

[Ladislav Thon]

st 6. 3. 2019 v 15:21 odesílatel <donbo...@gmail.com> napsal:

For metrics, what we're envisioning using the app name for is something that looks like this:

Server 1 / App 1:

    connectionPool_managedConnections{datasource="someDatasource", appName="app1"} 25

Server 2 / App 2:

    connectionPool_managedConnections{datasource="someDatasource", appName="app2"} 9

If people don't set an application name for each of their apps then the metric names would not be differentiated

Shouldn't an application server already have a human-readable name of the application? Typically, the name of the deployment, e.g. app1.war or app2.war. I don't think there should be yet another way how to configure this, the app servers already do it and the MP implementations, if they choose to do so, can provide an SPI which the app servers should use.

LT

 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ecfbc628-4118-4587-b749-848e26a809cd%40googlegroups.com.

[Jan Martiska]

The app server could use the context root of the application as the value of appName. (This IMO is more sensible than using the name of the archive, but that's open for discussion. Trouble might arise if someone is using metrics in a JAR deployment though, which could be possible, in that case we would have to use the archive name).

The mechanism which will be used to propagate the value from app server to the application could be left vendor-specific. We could still add the possibility to override it using a specific property in META-INF/microprofile-config.properties in the application.

I think this solution would be the least disruptive to the original "single app" philosophy of MicroProfile but still good enough to make metrics usable with multi-app servers.

If we went with Ken's suggestion of metrics being tied to the context root of the application, what would happen to vendor and base metrics? Would the same set of metrics be duplicated for each deployment?

[Ken Finnigan]

On Thu, Mar 7, 2019 at 8:52 AM Jan Martiska <jmar...@redhat.com> wrote:

The app server could use the context root of the application as the value of appName. (This IMO is more sensible than using the name of the archive, but that's open for discussion. Trouble might arise if someone is using metrics in a JAR deployment though, which could be possible, in that case we would have to use the archive name).

The mechanism which will be used to propagate the value from app server to the application could be left vendor-specific. We could still add the possibility to override it using a specific property in META-INF/microprofile-config.properties in the application.

I think this solution would be the least disruptive to the original "single app" philosophy of MicroProfile but still good enough to make metrics usable with multi-app servers.

If we went with Ken's suggestion of metrics being tied to the context root of the application, what would happen to vendor and base metrics? Would the same set of metrics be duplicated for each deployment?

That's possible, but likely also depends on what the metric is.

If it's measuring something in the app, then it wouldn't be, but if it's measuring something associated with "server level" then in a multi application server there would be some/a lot of overlap

 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b47d12d9-f651-412d-a13a-f4d88a4d5625%40googlegroups.com.

[Heiko Rupp]

Am Freitag, 8. März 2019 08:29:01 UTC+1 schrieb Ken Finnigan:

If we went with Ken's suggestion of metrics being tied to the context root of the application, what would happen to vendor and base metrics? Would the same set of metrics be duplicated for each deployment?

That's possible, but likely also depends on what the metric is.

If it's measuring something in the app, then it wouldn't be, but if it's measuring something associated with "server level" then in a multi application server there would be some/a lot of overlap

 

base scope is mostly about JVM statistics. They should be the same for all applications on a server

vendor scope is about vendor specific server metrics. E.g. for TT it could be number of loaded (jboss) modules.  

One would not want to expose them n times on a server with n deployments

Putting the /metrics endpoint below the context root of a deployment would (imo) also be a configuration nightmare for the clients that actually pull the metrics from the MP-Metrics enabled servers.

[Ken Finnigan]

This gets back to one of the comments I made, I think, earlier.

Namely that this proposal significantly deviates from everything in MicroProfile to date in that we've focused on single deployment for a single server instance, and not multiple deployments to a single server instance.

In Eclipse MicroProfile our target goal is "Optimizing Enterprise Java for a Microservices Architecture". At the time this mission was created, I'd be surprised if everyone wasn't in agreement that a microservice meant a single deployment. If, and that is a very large if, MicroProfile wants to go beyond the idea of "single deployment", then that needs to be discussed and agreed upon by the entire community.

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/eb965701-492d-4d00-ad08-e50b4e3269a7%40googlegroups.com.

[donbo...@gmail.com]

I certainly agree that the main target of MicroProfile is single deployment servers.  Today, having the same metric name in more than one application provides a poor developer/ops experience since the metric updates are merged from all apps.  Worse, if the applications aren't coded to indicate that their metric names are "reusable" then the duplicate metrics will fail to register.  This essentially means that two or more apps that may have overlapping metric names can't run in the same server.

So, while I think we agree that MicroProfile favors single deployment servers, this is an example where, if we don't address it, MicroProfile can ONLY be used reliably with single deployment servers.

Rather than leave this problem up to each app server vendor to deal with in their own way, or leave it up to app developers to deal with, it would be nice to have consistency.  

If we want to minimize how much MicroProfile gets involved with multi-deployment scenarios, would it be reasonable for the MP Metrics spec to just prescribe what label should be used on app-specific metrics in the case that an app server vendor supports multiple applications being deployed?  It could then be the vendor's choice on how to implement that.

Perhaps this should just be a topic for tomorrow's MP Hangout?

Regards,

Don

On Monday, April 15, 2019 at 3:53:28 PM UTC-4, Ken Finnigan wrote:

This gets back to one of the comments I made, I think, earlier.

Namely that this proposal significantly deviates from everything in MicroProfile to date in that we've focused on single deployment for a single server instance, and not multiple deployments to a single server instance.

In Eclipse MicroProfile our target goal is "Optimizing Enterprise Java for a Microservices Architecture". At the time this mission was created, I'd be surprised if everyone wasn't in agreement that a microservice meant a single deployment. If, and that is a very large if, MicroProfile wants to go beyond the idea of "single deployment", then that needs to be discussed and agreed upon by the entire community.

On Thu, Apr 11, 2019 at 5:56 AM 'Heiko Rupp' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Am Freitag, 8. März 2019 08:29:01 UTC+1 schrieb Ken Finnigan:

If we went with Ken's suggestion of metrics being tied to the context root of the application, what would happen to vendor and base metrics? Would the same set of metrics be duplicated for each deployment?

That's possible, but likely also depends on what the metric is.

If it's measuring something in the app, then it wouldn't be, but if it's measuring something associated with "server level" then in a multi application server there would be some/a lot of overlap

 

base scope is mostly about JVM statistics. They should be the same for all applications on a server

vendor scope is about vendor specific server metrics. E.g. for TT it could be number of loaded (jboss) modules.  

One would not want to expose them n times on a server with n deployments

Putting the /metrics endpoint below the context root of a deployment would (imo) also be a configuration nightmare for the clients that actually pull the metrics from the MP-Metrics enabled servers.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Ken Finnigan]

I'd be fine with a comment in the spec offering a way for vendors to implement multi deployment support, as long as it doesn't impact the API or TCK and is purely a "suggestion".

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5638be77-18e8-40e2-a219-869c3c74cbd9%40googlegroups.com.