Using each service's metric API to substitute System Management services

[MonicaisHer]

UI is currently using SMA for tracking each service's metric. I suggest UI use each service's metric API instead. They have the same return value.

SMA is deprecated with the Ireland release. Although SMA is still in use, but it has been tagged for eventual replacement in the future release.

[badboy-huaqiao]

@MonicaisHer yes, it's a good advice, I have been thinking about this feature, but it needs more time to redesign the GUI, so it's not finished before code freeze, keep this issue open until it's done.

[badboy-huaqiao]

@MonicaisHer Hi, I ran into some hard challenges if we use each service's metric API instead.

• GUI got all registered services from Consul through go-mod-register API.
• GUI can't know which service's rest API to call, it needs to be hard-code,for example, if GUI got one service's name is core-data, I will use if statement: if svcName == core-data, then call core data service's rest API.
• GUI got the registered services including all the device services, for example, device-rest, device-virtual, that means GUI needs to call the API of the device services directly though now GUI never does that, but if user adds a new device service like device-mqtt into the deployment file (docker-compose.yml), GUI will lost the ability to communicate with it,maybe the solution is that GUI provides one config page which let user set the basic communication condition.
• especially, GUI will not know the proxy route path which user set in the deployment file under secure mode, and maybe user will not set it.

though all the registered services GUI got from Consul with the host and port, but GUI is outside of Kong under secure mode, that means GUI can't use http to communicate with them directly.

all the issues above will be no problem if system agent existed.

do you have any better ideas?

and @bnevis-i what do you think?

[bnevis-i]

@badboy-huaqiao What if as part of service registration the metrics API URL was added as additional service metadata? Then, instead of hard-coding it into the UI it could just be queried from Consul?

• Base URL -- http://localhost:port for snaps, http://service-name:port for docker, or https://kong-endpoint for secure services
• Service-prefix -- /core-data, for example
• Metrics sub-url -- /api/v2/metrics, for example, combine with the above.

If we did it right, security-proxy-setup could just walk consul and configure the forwards, which I think would simplify the code a bit.

[badboy-huaqiao]

@bnevis-i that's great if the registered services returned carried the metadata you mentioned above.
but it might increase the workload on your team, as far as I know, services data returned by Consul's API will not contain such metadata.

Now the data structure of the registration service returned by thego-mod-registerAPI looks like:

{
   "ServiceId":"core-metadata"
   "Host":"edgex-core-metadata"
   "Port": 59881
}

it's better to add some extra metadatas like RoutePrefix and sub-url ， RoutePrefix is required which will be used both in secure and insecure mode.

[bnevis-i]

I would file a request in go-mod-registry. There is a Meta property https://www.consul.io/api-docs/agent/service#meta where we could add the additional information. Then we can raise it for Levski planning.

[badboy-huaqiao]

@bnevis-i that's great, looking forward to the updates.
so now what about Kamakura? should we leave it unchanged or hide the system agent module on the GUI? does the SMA still exist in the Kamakura release?

[bnevis-i]

I don't know. cc @jpwhitemn @lenny-intel Want to weigh in?

[jpwhitemn]

I will be adding this issue to the architectural topics for the Levski planning meeting for May 16-19. In the near term, the SMA service is not going away. While deprecated, it can't go away until at least EdgeX 3.0. So that gives us tome time to plan what is the path forward and what/how do we want to surface SMA info to tools like the GUI.

For now, GUI should take no action and we should add no additional features to any module or service. We should address this in a consistent way once the community picks a path forward.

[badboy-huaqiao]

ok, remove the Kamakura tag but keep this issue open until the new features mentioned aboved is done.