Server-id-spec

[Heiko Rupp]

Hey,

I was wondering if we should (this could be part of health, metrics or a separate spec) introduce a way to easily identify the server used and perhaps also some kind of configuration.

id:

  - name: thorntail-2

    version: 2.3.4-rc15

  - config:

      - jdk: openjdk9+hotspot

        jdk-version: 9.1.2

     - garbage-collector: g1

All of this is only read-only and could perhaps also include the VM flags, just like what jconsole emits for VM Summary

(probably not all of it)

On top, it could also list the applications deployed (name, version, context-root).

For developers this is probably all less interesting, but for observability-tooling, this gets more interesting - especially when the server runs inside a container

WDYT?

[Alasdair Nottingham]

It seems like the kind of information I’d want to not reveal about the server running a service.  

Alasdair

--
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/bcb46a66-8f6e-48b8-811a-69261f918064%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Edwin Derks]

Yeah, well... at least not public

[Ladislav Thon]

Parts of this (certainly you can infer what GC is in use) are already exposed via MP Metrics. I'm not sure if Metrics or Health are a good fit for this info, as this info is fairly static, while Metrics and Health are more dynamic, but adding it to Metrics would make sense to me.

I wouldn't be terribly worried about exposing this kind of info publicly, but at the same time, I believe neither Health nor Metrics are supposed to be exposed publicly and following suit here makes sense. (Technically, I think both Health and Metrics specs don't say anything about how the endpoints should be exposed, and maybe they should, as a non-normative text?)

LT

2018-06-08 13:50 GMT+02:00 Edwin Derks <eder...@gmail.com>:

Yeah, well... at least not public

--
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+unsubscribe@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/84bc2d5a-4df4-467d-b2b0-cb8b12be01ff%40googlegroups.com.

[Heiko Rupp]

Am Freitag, 8. Juni 2018 13:47:18 UTC+2 schrieb Alasdair Nottingham:

It seems like the kind of information I’d want to not reveal about the server running a service.  

It was not intended to have this publicly available, but rather for in-datacenter or in-K8s cluster usage. At the end, one with enough privileges can also ssh into a container and run ps and all that other magic. 

 

[Werner Keil]

Shouldn't this rather be exposed in a proper way through MP Config or the Config JSR in future?

Which does not force a single format like YAML (as in this case), JSON, Properties or XML, it abstracts that.

[Emily Jiang]

IIUC Heiko, you are suggesting in the BASE metrics, you would like to put the running server, version, jvm info there so that all MP Metrics impls need to provide this info, so that K8S might potentially rely on it. Each app server has this info anyway.

Werner, it is display only not inputting info. Therefore, no related to MP Config.

Thanks
Emily

[Heiko Rupp]

Exactly. It could be exposed in the metrics spec or in a different spec. 

[Emily Jiang]

+1. I think it is a useful metrics.

Thanks
Emily