-
Notifications
You must be signed in to change notification settings - Fork 111
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
[APM] Create and configure custom actions links #196
Comments
@nehaduggal @graphaelli I've updated the description with some more notes on the feature from my talk with Gil earlier. Let me know if there's anything I've missed. There's a couple of open questions, but none that urgently needs to be resolved before I'll start creating the initial screens.
|
I've made a first stab at the design proposal for this feature. As per last time, I've created a quick video with a walk-through of the UI. Basically it's a repeat of the central config UI, but with obvious changes to the creation flyouts and lists, but hopefully we should be able to leverage some of the same parts and interactions. |
Design update - Jan 22, 2020 Based on some of the feedback I've gotten on the initial proposal, I've made some additions to the user flow. Overall the set up is looking good, but we want to allow the user a more direct creation from a given service view. That's why we're adding options to create a new action and go to the list of actions with a given service filtered so it's a lot easier to get an overview of the custom actions already in place. With the UX change of adding a new custom action from within a service view, i.e. the Trace sample panel, the create flyout will open on that page, not redirecting the user to the Customize UI settings view. |
hi, Thanks for coming up with this, the video made things easier to understand, I had the following questions,
|
I think this issue is very relevant for your use case: elastic/kibana#25247 Especially since based on the mocks the user will pushed to link to internal apps by manually writing out relative URLs, if dashboard app changes its URL structure and wants to stop supporting old style URLs, these custom action saved objects will be storing outdated URLs and there is no good way to migrate them. This means dashboard app team may get stuck having to support old style URLs for a long time, as long as we have customers with outdated custom action link objects. Some more questions:
|
Hi @Yogi-SAP, Thanks for checking this out and allow me to inline comment on your feedback/comments;
For the initial implementation, it would surface for the trace sample from a transaction (group) and for each individual transaction and span details in the trace. We haven't discussed the option to have an "Actions..." menu for the group of transactions i.e. by the Transaction name; Is this along the lines of what you're suggesting?
We haven't discussed adding the transaction type as a parameter for custom actions, but I think there's a valid point in considering having separate options available for "custom" and "page-load" types, especially in the RUM use-case. We'll take it into consideration.
We did consider having an "All" option in order to allow for that kind of bulk actions creation, but decided against it for the first iteration. We'll take it into reconsideration since we imagine it'll just happen on the Kibana side and bulk creating the action for each discovered service.
Yeah. we've discussed adding dynamic fields to the URLs because, as you say, it goes beyond static links which might not be very helpful. We've discussed having
Yes, the custom action will show the environment of the transaction. So here, if we take the above example of adding in the actions menu for the transaction group, I imagine both of those links would appear if the transaction group has a mix of both production and development environment transactions. We need to consider this scenario obviously.
We considered allowing for groups or nesting of actions within a parent but instead thought that you'd be able to create a prefix with
That's because we have a direct link to the related errors in the Timeline and they're actually annotated on the x-axis as well. This will be available in the upcoming 7.6 release. Here's an example; I understand there might be case where you'd want to view a list of the related Errors for this selected service and trace. We might consider adding this as well to the list of already available actions in the menu. Thanks for taking a look and appreciate the detailed feedback. |
@stacey-gammon Thanks for the heads up on the URL service. That would definitely be a better way to implement those Kibana links 👍 Even though the Kibana use case is presented in this case, it's actually not the primary use case but added as a side-effect of being able to add custom links. We imagine, especially with dynamic values, we'll be able to support some external actions outside Kibana that will help our users with case management or similar when they're analyzing their data in Observability.
Users can define a service environment, whether it be
The dynamic context would be dependent on the piece of metadata that the user wants to have carried over; we want to allow the user to use a variables picker and choose which field value they want to include in their URL structure, so they can compose it themselves. We will then dynamically add in the values of those fields when the user clicks the action in the menu. I only just added this example in the design mocks today, which is why that functionality is not present in the above examples.
I saw the demo last week from the Kibana team, and yes, I agree it does feel really similar. I recall looking into the uiAction system for the embedded components project we had discussed previously, but not any deeper than just a skim. Happy to sync up as we move closer to the implementation and will need to investigate the best way forward there - or earlier if you think it's relevant to present to your team for other use cases to consider? |
Yea, I think this is really relevant (cc @streamich). Our phase 1 will be drilldowns that are attached to the "APPLY_FILTER_TRIGGER". Which means that any time someone calls Every trigger comes with required context. The idea is that any data from this context can be used by the action creator as a template parameter - just like you have above showing While phase 1 for drilldowns on dashboards are only going to consider that one trigger type, we want to eventually support more. Consider if APM made this services list an embeddable: and a user added it to a dashboard. You click on one of the service names and it directs the user to the service page. If this was on a dashboard though, I could see two actions offered to the user:
It'd be great if the actions are the same in both environments and the experience for adding custom drilldowns is the same. |
Is there a developer on APM working on this now? Or is it planned work? Either way, do you know which dev will be working on it? It'd be great to sync up with that person & Vadim and I, see if we can come up with a plan that doesn't have two devs duplicating the same work. :) |
@stacey-gammon this is planned for 7.7. We have a sync up on all our calendars for next week to discuss this. Will get folks from the UI team on the invite too so we can discuss and align. |
Opened implementation issues for the primary UI for the team to move forward. Closing this and will open specific issues for individual design items that might come up in the implementation. |
Links
Summary of the problem : Currently Kibana APM UI does not allow customers to embed custom links to external URLs. Adding this ability from the actions dropdown in the trace (and transaction) details to add/edit/delete additional custom links will enable users to configure additional views of their data and/or will enable them to link to external tools for more information.
Ideal solution (optional)
trace.id
and use it in the URL.service.environment
,service.name
,span.id
,trace.id
,transaction.id
,transaction.type
action.type
custom
and the existing APM links can be typeui
or similar, just to make sure they can be separated later on.context.type
transaction
which means we can extend tospans
anderrors
at a later point for users to scope the display of their custom actions to a specific proccesor event typeAre there any pages or actions that relate to this feature?
This is an extension of the custom links in the Actions drop down captured in this issue elastic/kibana#53187
The text was updated successfully, but these errors were encountered: