Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metrics visualization #942

Open
Haarolean opened this issue Oct 7, 2021 · 6 comments
Open

Metrics visualization #942

Haarolean opened this issue Oct 7, 2021 · 6 comments
Labels
scope/backend scope/frontend status/accepted An issue which has passed triage and has been accepted type/feature A new feature
Projects

Comments

@Haarolean
Copy link
Contributor

Haarolean commented Oct 7, 2021

Store and visualize metrics graps, for, like, consumer lag

Feedback from here:

Have a graph that show consumers lag over time like metricbeat/Kibana dashboard
See a graph of the publish message count per topic over time (last hour, last day, last 10 day, etc).

UPD:
0) Research: determine set of metrics for visualisation

  1. Consider an easy&fast solution: store some data as cache for consumer lag in ram and display graphs in UI
  2. visual identification of lagging consumers? Red borders?
  3. table inline small graphs
@Haarolean Haarolean added type/enhancement En enhancement to an already existing feature scope/backend scope/frontend status/accepted An issue which has passed triage and has been accepted labels Oct 7, 2021
@Haarolean Haarolean assigned Haarolean and unassigned Haarolean Oct 7, 2021
@Haarolean Haarolean added this to the 0.5 milestone Oct 7, 2021
@Haarolean
Copy link
Contributor Author

Haarolean commented Oct 7, 2021

Also #206 #3047

@Haarolean Haarolean pinned this issue Oct 19, 2021
@Haarolean Haarolean added this to 0.5 in Roadmap Oct 25, 2021
@Haarolean Haarolean added type/feature A new feature and removed type/enhancement En enhancement to an already existing feature labels Dec 21, 2021
@Haarolean Haarolean added the status/blocked Further development process is blocked by something. Prevents merging for PRs. label Feb 10, 2022
@Haarolean Haarolean moved this from 0.5 to 0.6 in Roadmap Feb 10, 2022
@Haarolean Haarolean added this to Features in Release 0.5 Apr 21, 2022
@Haarolean Haarolean removed this from Features in Release 0.5 May 3, 2022
@Haarolean Haarolean modified the milestones: 0.5, 0.6 May 3, 2022
@Haarolean Haarolean removed this from the 0.6 milestone Jun 8, 2022
@Haarolean Haarolean removed the status/blocked Further development process is blocked by something. Prevents merging for PRs. label Nov 25, 2022
@Haarolean Haarolean moved this from 0.7 to 0.6 in Roadmap Nov 25, 2022
@Mgrdich Mgrdich self-assigned this Nov 27, 2022
@Mgrdich
Copy link
Contributor

Mgrdich commented Nov 27, 2022

Results for the Library

Basically the decision was based

  • On the features
  • Documentation
  • Bundle size
  • Ease to use
  • Performance
  • Vanilla Javascript library that they were built on
  • Customizability

We have two strong options.

1. ReCharts

Is a composable charting library built on React components.

Pros

  • Built on top of SVG elements with a lightweight dependency on D3 submodules.
  • Easy to use
  • Very Very Good Documentation on their website
  • StoryBook examples
  • mostly written with Typescript , but has a @types definition.
  • Easily customizable.

Cons

  • a bit larger bundle size than react-chartjs-2 , but not with a huge margin

2. react-chartjs-2

Pros

  • Built on top of Chart.js.
  • Easy to use
  • mostly written with Typescript , but has a @types definition.
  • better bundle size than Recharts

Cons

  • Not easily customizable.
  • Not as much examples as Recharts.

Results

My Personal choice would be ReCharts, since the pros are more than the cons , and it has a very good examples.

Tips

Since Charts Components are heavy components , i would recommend to memoize those components with React.memo, and make them on their one , where they should change only when the props of them change not , when some node in their parent trigger a re-render by calling a setState.

@sherifkayad
Copy link
Contributor

sherifkayad commented Nov 27, 2022

@Haarolean just for my understanding, what would be the backend of this feature? I mean would the Kafka UI then store such metrics by itself or generate them on the fly each time from Kafka? How about querying Prometheus for those and just visualize them like what's today possible in Grafana using the Kafka Exporter? I think querying prometheus would probably give some more accurate data and a good graph view .. what do you think?

@Haarolean
Copy link
Contributor Author

@sherifkayad this is TBD yet. Probly exporting metrics into prometheus, might be a lil bit of storing short-term some metrics in memory.

@sherifkayad
Copy link
Contributor

@Haarolean got ya. I just wanted to say if something like the Kafka Exporter (https://github.com/danielqsj/kafka_exporter) is already in place, then you wouldn't probably need to worry about lots of metrics e.g. lag metrics or throughput metrics. In that case, probably the Kafka UI can just read the metrics from Prometheus and that's it. Not sure if that makes sense to you or if there could be some metrics that the UI needs and those aren't available by the exporter.

@Haarolean
Copy link
Contributor Author

@sherifkayad thanks for suggesting kafka-exporter. We might use that as a setup example for this feature.

@Mgrdich Mgrdich removed their assignment Dec 9, 2022
@Haarolean Haarolean moved this from 0.6 to 0.7 in Roadmap Dec 15, 2022
@VladSenyuta VladSenyuta unpinned this issue Feb 23, 2023
@Haarolean Haarolean moved this from 0.7 to 0.8 in Roadmap Mar 9, 2023
@Haarolean Haarolean moved this from 0.8 to 0.9 in Roadmap Mar 15, 2023
@Haarolean Haarolean pinned this issue Apr 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope/backend scope/frontend status/accepted An issue which has passed triage and has been accepted type/feature A new feature
Projects
Development

No branches or pull requests

3 participants