Plugin support for the UI

[jcchavezs]

Feature:
Plugin support for zipkin UI

Rational
People uses zipkin in different ways, with different purposes but more importantly using it along with different tools. Having the possibility of including plugins for specific purposes would improve user experience. All this plugins could callables hooked into frontend events. and they can be loaded into the UI by just requiring the js file.

Example Scenario
Two examples:

• UI should support generic and site-specific tags #2236: A plugin that provides a dropdown with specific tags for a site could be easily plugged into the UI. Since site vendors know what are their common tags or also this plugin can keep track of the tags used and store them in browser local storage for suggesting them later.
• Correlate requestID with logs: this very simple could turn the request_id tag in the span details into a link to e.g. kibana so you can go directly to kibana and see all log entries related to that log.

[codefromthecrypt]

I'd highly resist the idea of arbitrary plugins unless there's a well known framework that can accomplish this. I've not seen such a thing but it might exist. If it did, we'd get questions on how to install plugins as well. Even in haystack which has pluggable functionality, it is still required to design for the features involved (there is a convention but it isn't automatic afaict). OTOH, it is good to consider modularity regardless. We just need to balance requirements with reality which is what people have time to do and what exists.

[codefromthecrypt]

so basically I'd leave this open.. probably more a maintainers burden than anything else. to get to the point of "rule of 3" we'd need things that aren't features yet that folks want to install.. then we can figure out if we have resources to build a mechanism framework etc.

maintainers like @tacigar may end up using a pluggable framework anyway :D

@jcchavezs what I'd recommend for you is to top-level your request about log correlation. We have the LOGS_URL thing, but you are probably asking something else. It might be easier after the internals change to v2 format (for example we can access tags reliable after this and this might be needed depending on what you want).

other opinions and challenges welcome :)

[codefromthecrypt]

one related concern to this point is the "favorite trace" thing that came up many times, most recently by @drolando. I agree hacking the UI in its current form isn't straightforward.

[codefromthecrypt]

PS not to overanswer, but I'm always worried about busfactor.

Things requested and no-op in the past were web components (people like but no traction yet), and grafana (abstract idea unclear exactly what it would be).

exploration is helpful, getting concrete or actionable is usually the where it stops. I suspect after the redo will be a better time to consider this deeply as folks will be less heads down.

[drolando]

Having an easy way to add my custom plugin would be amazing.

I wanted to add a button to automatically save a trace without forcing users to download the json and re-upload it manually somewhere. The JS change is pretty simple, adding it to zipkin-ui is not.
I have to download the jar, unzip it, run sed against index.html to make it import my new js file, add the js file, rebundle everything in a jar and override the one embedded in zipkin-server when I start it. It works now but it's super hacky and ugly.

[codefromthecrypt]

does anyone know how folks currently customize via overlay webpacked javascript? One of the main things here is that the assets are intentionally remapped to different names allow the browser to update them. Regardless of jar or not jar (that part is easy to change in the server.. we can supply a file path override), the point will remain that webpack mapped files are not the easiest to change. cc @openzipkin/devops-tooling

[zeagord]

I have a feeling like this will become like the custom server. If there is a strong use case and request from the community we can actually add it to our UI app itself. Anyhow people who wants extra stuffs can always fork and develop something that makes sense for them. Otherwise this will lead to a lot of confusion and support from the community.

[codefromthecrypt]

we are iceboxing this. maybe after we work on grafana, we will have more experience in how plugin systems work. This doesn't mean we'll have the ability or time to recreate this sort of framework.

[jcchavezs]

Makes sense. Somehow e-mail filters hide the notifications about third thread. tor. 18. apr. 2019, 08:57 skrev Adrian Cole <notifications@github.com>:

…

we are iceboxing this. maybe after we work on grafana, we will have more experience in how plugin systems work. This doesn't mean we'll have the ability or time to recreate this sort of framework. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2251 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXOYAXL66H5ANPIJ435HMTPRALWDANCNFSM4GD4544A> .