How much flexibility in changing the metric services??

[ddebrunner]

I believe metrics services could be improved to make them more useable and in-line with the microservice guidelines, but some changes would break compatibility?

Since they are not currently documented, are we free to change them?

E.g.

• Don't use a generic parameter names, use a name that reflects the parameter's purpose:
  • applicationConfigurationName
    • MetricsIngestService - the proposed job service (#113) uses monitoring. Ideally we would be consistent across all services in this toolkit.
    • MetricsMonitorService - Use something like thresholds ?
  • ingestTopic - something like metricsTopic
• MetricsIngestService - publish as SPL and JSON (doesn't break compatibility) - See #114, though changing MetricsMonitorService to match would.
• MetricsMonitoringService - Publish text alerts as String (not rstring message) - this allows direct feeding in the slack service as well as easy consumption by Java and Python apps.
• MetricsMonitoringService - Also publish a stream with a real schema for alerts, allowing downstream microservices to take intelligent action, e.g. using the operator name, job id etc. (see #116)

[ddebrunner]

Of course, we could move to a 2.0 version of the toolkit as an alternative.