Closed ddebrunner closed 7 years ago
USG is planning to open source a metrics relay service. It's not a toolkit, more of a standalone application. It connects to JMX, buffers metrics and relays them to services that want them. They currently have permission to export the code and are just waiting on the paperwork before it goes up on GitHub. We may be able to use their codebase and minimize development cost.
Should this be a separate toolkit or combined with streamsx.metrics? Either adding new capabilities to streamsx.metrics or renaming streamsx.metrics to streamsx.monitoring.
Renaming streamsx.metrics
to streamsx.monitoring
seems like a good approach.
+1 to
Renaming streamsx.metrics to streamsx.monitoring seems like a good approach.
I like the idea of renaming streamsx.metrics to streamsx.monitoring too. Its a little annoying to rename a toolkit that has only recently been created but I think it makes sense as the right longer term packaging so its worth the disruption. @markheger what are your thoughts?
I agree that renaming would make sense if additional monitoring functionality would be added to the streamsx.metrics toolkit.
There's a metrics monitor that I've been working on. You can find it here: streamsx.metricsmonitor. It's part of a larger starter kit that monitors metrics and sends alerts to Slack.
I'm wondering if it belongs in the streamsx.monitoring repo. And if it should, whether it should be added to the metrics toolkit. What do you guys thinks?
@nelsonong +1 that was the purpose of the monitoring concept, services/operators like that.
It looks like the consensus is to have a single monitoring toolkit, renaming streamsx.metrics
.
+1 on the summary above from @ddebrunner have a single monitoring toolkit, renaming streamsx.metrics and moving metrics monitor from @nelsonong
+1
I believe that the metrics repo has been renamed, can this issue be closed?
A toolkit that provides capabilities to create applications that monitor Streams and its applications.
Basically the toolkit would monitor JMX and create streams of events from JMX notifications and other events of interest.
It may use capabilities from
streamsx.metrics
, e.g. to integrate alerts if a stream is finalized, or tuple rate drops to zero for a period.Apart from source operator(s) it would include microservices to publish events that then could be delivered by other microservices to various destinations, such as message queues or slack.