[APM] [Service map] Service Node Icons

[graphaelli]

The initial approach to determining the service map node icon (thanks @smith) is:

kibana/x-pack/legacy/plugins/apm/public/components/app/ServiceMap/icons.ts

Lines 49 to 56 in ec4ece7

	export function iconForNode(node: cytoscape.NodeSingular) {
	const type = node.data('type');
	if (type === 'service') {
	return serviceIcons[node.data('agentName') as string];
	} else {
	return icons[type];
	}
	}

This issue intends to start a discussion around enhancements to the icon lookup with the goal of making the service map more consumable for users - that is, quicker understanding of what services are shown and what powers them.

For instrumented services (those with an APM agent) I propose icon resolution should follow:

1. Framework - service.framework.name - django/express/gin/rails
2. Runtime+Language - service.runtime.name - java/jruby/cpython
3. Language - service.language.name - java/ruby/python

Runtime alone doesn't make sense to me (and I don't think is actually reported by any known agent) For example a C# app will report .NET Core for runtime, where C# is more informative. By contrast a python app may report pypi for framework which could be useful to distinguish from cpython apps, but both are still python.

Seeking input on whether framework is a good idea.

I'm interested in exploring adjusting some attribute of the node based on where is running - cloud provider, container/k8s/serverless, etc but consider that out of scope for this pass.

A separate issue for icons for external services will follow.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[formgeist]

I have been working on some mocks for adding in more descriptive icons on the node types as per the feedback.

The framework is added as a sublabel and badge in the popover. We need clarification of whether service.framework.name is the appropriate field to populate this.

Language logos

👍Clear description of the language per logo
👎Copyright issues distributing these logos without proper permission, smaller nodes the logos becomes smaller and hard to read.

Language monochrome

👍Clean service map, making sure only the highlighted nodes with i.e. alerts or later on traffic light map styles will stand out.
👎Hard to separate the service languages apart

Language colors

👍Languages are uniquely identified without the use of logos
👎The more languages, the harder it'll become to separate. Still manual color assignment per agent name.

I would love to hear people's thoughts on this, as I think it's hard to find a perfect visual. cc @roncohen @nehaduggal @elastic/apm-ui @elastic/observability-design

[roncohen]

love the first one (Language logos). I don't think the copyright issue should be a problem, but definitely worth investigating.

[roncohen]

we can maybe fall back to "Language monochrome" for things we don't have logos for

[nehaduggal]

+1 to what Ron said- The language logos UI is pretty neat and looks great. Language monochrome is my second favorite. In addition the complexity of assigning colors to language agents, the language colors makes the map look really busy.

[formgeist]

Thanks for the great feedback! I'll look into the copyright question and see about our options for avoiding the host or bundle the icons in our Kibana code because I think that might be the underlying problem.

we can maybe fall back to "Language monochrome" for things we don't have logos for

Agreed, we need a fallback.

[formgeist]

I spoke to @snide and agreed that we shouldn't worry about the copyright issue since we're simply using them as informational, not promotional or any other sense. So let's bundle language logos for the agents we support (RUM will have a generic JS logo), and have a fallback monochrome avatar version as proposed above. I'll create the implementation issue for this. Wasn't sure if we had a preference for, in some way, show the framework name when available?

[formgeist]

@smith If we're to implement language icons in SVG, where should I put them - do I just collect them and send them your way in an implementation issue, or what do you prefer?