[APM] Create and configure custom actions links

[nehaduggal]

Links

• Figma prototype

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)

• User can create an unlimited number of custom links by defining the following parameters in a manage UI
  • Link label
  • Max length, 128 chars?
  • Link URL
  • Add field value variables from the selected transaction document metadata to retrieve i.e. the trace.id and use it in the URL.
• The custom links will be displayed in all existing action menus in the APM UI
  • Trace sample
  • Transaction details
• User can scope the display of the action to a number of fields available;
  • service.environment, service.name, span.id, trace.id, transaction.id, transaction.type
• User will access a new section of the existing APM settings named "UI customization" that will have a custom links section.
• Under the hood, custom actions will additionally carry a action.type custom and the existing APM links can be type ui or similar, just to make sure they can be separated later on.
• Under the hood, the custom actions will also carry a context.type transaction which means we can extend to spans and errors at a later point for users to scope the display of their custom actions to a specific proccesor event type

Are 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 https://github.com/elastic/kibana/issues/53187

[formgeist]

@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.

• Do we need to convert the Error occurrence link currently going to Discover to an Actions menu with these custom links?
• Any other places we'd like to add the Action menu?

[formgeist]

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.

Video walk-through

Figma prototype

[formgeist]

Design update - Jan 22, 2020

Figma prototype

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.

[Yogi-SAP]

hi, Thanks for coming up with this, the video made things easier to understand, I had the following questions,

1. What is seen in the video is the "Actions" drop-down against a particular transaction. A transaction of type "page-load" will typically have many transactions listed under it. Won't the customize UI functionality not be available for the entire page-load transaction? Will it be only against the individual transactions? I think it would be good to have it also for the whole RUM page load transaction as there would be navigation options for the entire visualization as in our case. We would like to present separate navigation options against an individual transaction and also the whole page load transaction.
2. In a topical continuation to the point above, Different types of transactions have different types of actions to them. Don’t you think it would be a good idea to have an option of also configuring against a "transaction type"? For example, a transaction type "Custom" would have different actions versus a transaction of type "page-load" or "request".
3. We have close to 20-25 services, it would be very difficult to navigate to each service and configure an action. I see that the original description mentions being able to select all services but I don’t see the "all" option being discussed in the video. Could you please clarify? Do you also plan to make the configuration available through a API, as we have automation for our elastic deployment and we would also want to do this programmatically.
4. Most of the action links would have dynamic element to them. For example, being able to attach a trace id or transaction id or any other label field to the URL. You guys already send the trace id when user selects the "View trace logs" action menu. Static links alone do not help, please review this requirements it is very critical. You may want to let the user configure something like this -> http://somelink/?id={$trace.id} , user may want to select some other custom field from the index document but I just used the trace ID as an example.
5. What happens when the user has added a custom action for only one environment but has navigated to a transaction with the environment filter at the top set to "All"? Would the custom action be shown or not? I am assuming if the current transaction is against the configured environment then the configured actions are shown. Obvious, but always good to clarify, please confirm my understanding.
6. Ability to customize the menu header would be great. For example, we might add a menu header which says "Custom actions for SuccessFactors Systems" below which the menu options would be available. If the user doesn’t configure a header name you may leave it empty. A nice to have bell/whistle combo.
7. The menu option to automatically show relevant errors against the Trace would be excellent and adds completeness to the APM perspective, I did not see the menu option in the video.

[stacey-gammon]

I think this issue is very relevant for your use case: https://github.com/elastic/kibana/issues/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:

• What is Environment in the flyout?
• Is there any dynamic context that could be used in these links (for dashboard drilldowns the dynamic context is the filter created when a user clicks on a part of a visualization)?
• Have you looked into using the uiAction/trigger system at all? I'll have to look more into this feature but it looks so similar to drilldowns in dashboards (or custom links accessible from dashboard panels, without filter context), we should stay in sync.

[formgeist]

Hi @Yogi-SAP,

Thanks for checking this out and allow me to inline comment on your feedback/comments;

What is seen in the video is the "Actions" drop-down against a particular transaction. A transaction of type "page-load" will typically have many transactions listed under it. Won't the customize UI functionality not be available for the entire page-load transaction? Will it be only against the individual transactions? I think it would be good to have it also for the whole RUM page load transaction as there would be navigation options for the entire visualization as in our case. We would like to present separate navigation options against an individual transaction and also the whole page load transaction.

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?

In a topical continuation to the point above, Different types of transactions have different types of actions to them. Don’t you think it would be a good idea to have an option of also configuring against a "transaction type"? For example, a transaction type "Custom" would have different actions versus a transaction of type "page-load" or "request".

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 have close to 20-25 services, it would be very difficult to navigate to each service and configure an action. I see that the original description mentions being able to select all services but I don’t see the "all" option being discussed in the video. Could you please clarify? Do you also plan to make the configuration available through a API, as we have automation for our elastic deployment and we would also want to do this programmatically.

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.

Most of the action links would have dynamic element to them. For example, being able to attach a trace id or transaction id or any other label field to the URL. You guys already send the trace id when user selects the "View trace logs" action menu. Static links alone do not help, please review this requirements it is very critical. You may want to let the user configure something like this -> http://somelink/?id={$trace.id} , user may want to select some other custom field from the index document but I just used the trace ID as an example.

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 service.name and transaction.id to begin with, not a big issue also adding in trace.id as it's part of our existing links. Down the line, we want to support additional fields.

What happens when the user has added a custom action for only one environment but has navigated to a transaction with the environment filter at the top set to "All"? Would the custom action be shown or not? I am assuming if the current transaction is against the configured environment then the configured actions are shown. Obvious, but always good to clarify, please confirm my understanding.

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.

Ability to customize the menu header would be great. For example, we might add a menu header which says "Custom actions for SuccessFactors Systems" below which the menu options would be available. If the user doesn’t configure a header name you may leave it empty. A nice to have bell/whistle combo.

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 [SuccessFactors System] My custom action. Not sure if that will suffice for the time being?

The menu option to automatically show relevant errors against the Trace would be excellent and adds completeness to the APM perspective, I did not see the menu option in the video.

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.

[formgeist]

@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.

What is Environment in the flyout?

Users can define a service environment, whether it be production or development, so they can see one service in APM but easily separate the data for performance troubleshooting.

Is there any dynamic context that could be used in these links (for dashboard drilldowns the dynamic context is the filter created when a user clicks on a part of a visualization)?

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.

Have you looked into using the uiAction/trigger system at all? I'll have to look more into this feature but it looks so similar to drilldowns in dashboards (or custom links accessible from dashboard panels, without filter context), we should stay in sync.

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?

[stacey-gammon]

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 emitTriggerActions(APPLY_FILTER_TRIGGER, { filters, embeddable }), a context menu will show up with all the configured actions/drilldowns.

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 service.name and transaction.id.

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:

• Open service page
• Apply filter to current dashboard
• [Admin configured drilldowns:]
• Open "my custom service dashboard" and apply filter

It'd be great if the actions are the same in both environments and the experience for adding custom drilldowns is the same.

[stacey-gammon]

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. :)

[nehaduggal]

@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.

[formgeist]

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.