-
-
Notifications
You must be signed in to change notification settings - Fork 161
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
Display Grain interaction with WebGraphviz #344
Comments
This looks like a great idea. It would be awesome to overlay call counts, exceptions, latency etc.. |
yes like this |
This would be amazing |
I made a PR, following @ReubenBond advice I use RequestContext and store the call stack in it.
I would be grateful for any comments, as well as advice on how to properly write the tests. I've seen a lot of test projects, but I don't understand how it all works yet. |
you can check some results here: http://www.webgraphviz.com
|
Hi, great results so far. But would it not be better to use a graph library where we have more control over the UI behavior and can add things like tooltips and so on? Also some numbers would be great. Calls per second, error rate and so on. |
https://github.com/cytoscape/cytoscape.js There are a lot of libraries, let’s find the best one |
But I’m not familiar with front end technologies, so I can’t understand which library is better for it |
I have worked with this one: https://github.com/visjs/vis-network |
I guess with the dashboard in general but certainly with this proposed feature, this intermixes very well with open telemetry (or telemetry in general). The open PR builds something unique to orleans but the same information can be derived from open telemetry with a much lower overhead cost. Perhaps instead of introducing something Orleans specific, we can instead consume OT data and use that in the visualization. Not sure yet how that would work, just wanted to have that thrown in here... Will look into this further... |
Yes, could be. I think Open Telemetry already has some rate limiters built to reduce the number of single spans. If you can derive the needed information from these spans, it could work. |
@SebastianStehle can you guid me please But I have a question about name formatting, because now we have two Invoke methods with different contexts. I need one more parameter that will indicate the type of the calling Grain. For example, to add some attribute, so we could track a specific query to understand that why and where my performance degrades? I see the base class as:
|
What do you think about this method?
When a new request starts, we put new trackId, if we understand that the request chain continues, we use the same trackId. so it doesn't seem like there will be too many changes |
We just have to introduce a second delegate I think. |
For me it looks like they will do the same thing |
Yes, but if you introduce another parameter it would be a breaking change, isn't it? |
Yes, but I just don't know who uses this method other than the filter. |
Sorry, I thought you talk about the formatter delegate. I should have read it more carefully. I think right now we aggregate the method calls per Grain+Method. If we also need the caller then we have to group by this as well. |
I think it would be good to make diagrams of the real interaction between Grains.
And to display it, use a tool like this:
http://www.webgraphviz.com
I already have a filter that collects data, but I can't do it in the front-end :(
I will prepare a PR
The text was updated successfully, but these errors were encountered: