Skip to content
This repository has been archived by the owner on Jun 10, 2021. It is now read-only.

View System Metrics Data #47

Closed
6 tasks
dabonnie opened this issue Dec 19, 2019 · 8 comments
Closed
6 tasks

View System Metrics Data #47

dabonnie opened this issue Dec 19, 2019 · 8 comments
Assignees
Labels
enhancement New feature or request

Comments

@dabonnie
Copy link
Contributor

Description

Provide a simple standalone utility to view logged system metric data. The problem can be split into the following:

  • Log the data into a parseable format for a display tool
  • Parse the logged data
  • Plot the data

Test Plan

  • Manual testing
  • Unit test for new classes

Documentation Plan

  • README.md update

Release Plan

PROMPT (REMOVE-ME): What release work needs to be done to finish this feature? e.g.

  • check in PR
  • bloom release

Acceptance Criteria

  • Code has been implemented, reviewed and merged.
  • Test plan has been completed
  • Release plan has been completed

Once all above items are checked, this story can be moved to done.

@dabonnie dabonnie self-assigned this Dec 19, 2019
@dabonnie
Copy link
Contributor Author

dabonnie commented Dec 19, 2019

Filed #46 for package skeleton.

@thomas-moulard
Copy link
Member

@dabonnie Before jumping into that, could we groom this story and evaluate why rqt is not the right choice?

@dabonnie
Copy link
Contributor Author

SGTM

@thomas-moulard
Copy link
Member

@ablasdel I think it'd be super helpful to have a quick chat with @dabonnie on this! I think the main challenge using rqt_plot is the way the message is organized (all types of data on the same topic with a "name"). Maybe we should have per-metric topic and/or let that being configurable? Does not need to be different message types necessarily.

@dabonnie
Copy link
Contributor Author

@ablasdel I think it'd be super helpful to have a quick chat with @dabonnie on this! I think the main challenge using rqt_plot is the way the message is organized (all types of data on the same topic with a "name"). Maybe we should have per-metric topic and/or let that being configurable? Does not need to be different message types necessarily.

We initially decided to use the same topic name for all the generated metrics because if the topic name is generated dynamically (e.g. for the per process measurements), then this could be problematic for discovery later. For example using an aggregator / collector (i.e. cloudwatch metrics) would need to ensure it's subscribed to all topics when they appear, otherwise it can sit and listen on a general topic.

@ablasdel
Copy link

Single topic makes sense I agree. Let’s look into adding “metric message support” to rqt_plot in the new year.

@dabonnie
Copy link
Contributor Author

dabonnie commented Mar 4, 2020

Bringing out of the icebox :-)

@emersonknapp emersonknapp added the enhancement New feature or request label Mar 9, 2020
@emersonknapp
Copy link
Contributor

closing in favor of a visualizer rqt plugin

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants