Call For Requests!!!

[dsarfati]

We have 2 React interns that will be spending a month with our team and we are planning on having them work on the dashboard. I would like to get a list of ideas together so we can let them pick a few items to work while they are with us.

So far we have:

• Ability to drill down to a specific grain activation instead of just the grain type
• Sort/filter the grain table
• Call a grain method (similar to the swagger UI)
• Deactivate a specific grain activation
• Map/graph showing the connections between grains based on the method calls (possibly similar to the cosmosDB gremlin UI show below)
  

[richorama]

Thank you @dsarfati, this is an amazing offer!

Here's a shortlist for some of the UI related issues. Of course I'm open to more ideas.

• Consider percentiles when calculating avg latency #135
• Ability to filter out Dashboard grains #127
• Consider (investigate) switching the JS build to webpack
• Add reminders summary to the overview page #57 & Add reminders view #51 (various improvements could be made to reminders)
• support custom user ordering of grain method invocation charts #26
• Add horizontal time axis to dashboard charts #10
• Improvements to grain tables #3 (sorting and filtering grain tables)
• General tidy up of the code
• Add a CI build for the UI stuff (travis?)

In terms of visualising grains in a graph, and understanding the behaviour of individual grains, I believe https://github.com/DerivcoIpswich/Orniscient does a good job of this.

I would be happy to have a skype chat to introduce how the dashboard works, if that would be helpful?

[ReubenBond]

Some random ideas for features/changes - mostly not UI issues

• .NET Runtime version
• Current total/available memory
• Environment variables
• Total set of known grain classes and interfaces on each silo
• Configuration object values
• Loaded assemblies, including paths & metadata (version, etc)
• Historic values / graphs for each counter
• Graph of communications between each grain (eg, by using incoming + outgoing call filters - maybe based on Orniscient)
• Ability to inspect each activation's internal state & persistent state

Maybe some of those are too sensitive to display, but I'd say it's up to the developer.

They can always ask for assistance with the Orleansy things in gitter

[SebastianStehle]

Some ideas (will add more)

• Tracking of activation performance.
• Widgets and custom dashboards.

[jkonecki]

Change the architecture from pull to push - SignalR maybe?

[rikbosch]

An overview of exception rates and top X exceptions per silo / grain / method

[justmara]

Btw. Maybe use something like AppMetrics for stat collection and counts? Current ConcurrentDictionary-based realization is very limited ;) And using appmetrics one could totally skip hosting dashboard itself in orlean's host and simply translate metrics to something like InfluxDb or esle, using any dashboard he already uses, but with all the fine-grained metrics from this project.

I mean Dashboard is fine, really nice and informative, but I don't like idea of hosting it on production machines, passing http-requests from outer world to orleans, hosting it.. And the performance factor too. Simple set of grain filters that send required metrics to orlean's Telemetry system could give help us better utilyze the power of Grafana, for example. That is way more powerful in dashboarding ;)

[SebastianStehle]

I think it is and should be out of scope of the dashboard. The dashboard is a nice and easy way to get some insights without much infrastructure. If you need more sophisticated solutions it is quiet easy:

• Write custom ITelemetryConsumer
• Use json/semantic logging
• Write a custom filter

collect the data and push them to InfluxDB or Kibana or Stackdriver or SQL Server or whatever. It would be great to have an open source project for this or a default filter for performance metrics, but I think the dashboard should be simple. The dashboard also introduces some dependencies which you can avoid if you make a custom project. Of course we could also restructure orleans and separate it into multiple packages/projects.

[justmara]

@SebastianStehle I mean that this project can be pretty easily split into two:

1. collecting data (grain filters and sending metrics to ITelemetryProducer)
2. self-hosted metrics viewer: dashboard host itself and in-memory metrics collection.

First part would be useful when you have any external metrics tracking system and only want to get all the metrics this project provides without re-inventing the wheel and repeating'em, and without hosting cpu-intensive local metric collection in Silo process and bringing all the garbage dependencies. Something like RegisterMetricCollectors() method, that only adds filters and metric collection grains.
Sure I can write your custom filters but why must I do it while it is already have been made here? :)

Second part would be dashboard itself with all the dependencies needed - web host, local metrics collector etc. As for metrics collector I've mentioned AppMetrics because it is really fast flexible with really low cpu overhead but still powerful realtime metrics processing with mean/avg/percentile metrics. So looks like it could be used as local storage instead of concurrentdictionaries.

[SebastianStehle]

100%, this is what I mean with my last sentence:

Of course we could also restructure orleans and separate it into multiple packages/projects.

[andrew-laughlin]

AuthN/AuthZ via OpenId Connect and OAuth would be a nice feature. There are OAuth JS libraries that implement implicit flow.

[seniorquico]

Sorry for the delayed response on this thread. Unfortunately, the previous candidates didn't elect to pursue this project. I meant to update the group, but the startup life caught up with me. 😓

I worked on my Orleans Dashboard pitch in the meantime, and... We have just confirmed two React interns will be spending a month with our team, committed to working on the dashboard!

The pair will begin on Monday, August 20. They will be working in our office, alongside our team. At the start of next week, we plan to review the ideas presented in this thread with the interns and to identify a scope of work. Be on the lookout for some introductions next week, if interested. 😄

@richorama I'd love to take you up on the offer of a Skype call if you're still interested/willing/available. No worries if it's not a possibility.

[richorama]

Hey @seniorquico, apologies, I've just got back from vacation. Happy to arrange a call on Monday, or any other day next week. I'm in the UK so if there's a time when we overlap our working day, that would be great.

[richorama]

awesome to hear you've got some people who can work on this BTW, very exciting.

[seniorquico]

Thanks, @richorama! Happy to find any time that works great for you. We're in the US Pacific time zone. You can reach me at [email protected].

[SebastianStehle]

Can we close this task or create concrete issues?