[Feature request] Standard conventions for icon and color of resources and/or spans

[michaelsafyan]

Area(s)

area:new

Is your change request related to a problem? Please describe.

In tracing systems, it is useful to use icons and colors to differentiate components.

If someone uses multiple tracing systems, they may have to configure the display multiple times for each system.

In addition, tracing systems must currently implement a separate control plane to manage/configure the display and color when there is already a path for data to enter the system via span attributes.

Describe the solution you'd like

It should be possible to hint at the desired icon and color in the resource or span attributes.

While tracing systems may still wish to provide a way to override these hints, the presence of these hints would serve as a useful baseline for configuring the default display behavior of the tracing system.

As a strawman proposal:

• display.icon: Hints at the icon that should be used. This is a comma-separated list containing entries of the form: <namespace>:<name>. The namespace mdi for "material design icons" (based on Google's Material Icon Font) is expected to be supported on systems that support display.icon. Tracing systems may optionally support additional namespaces, which are to be documented by the tracing system provider. The first entry that exists/works in the comma-separated list will be the one that is used (unless overridden by the user somewhere else).
• display.color: Hints at the color that should be used. Can contain color names, CSS-style hex values prefixed with #, CSS-style rgb() function calls, CSS-style rgba() function calls. Given that not all color names may be supported on all systems and given that commas are used in rgb() and rgba(), uses ; to provide a list.

Examples:

• display.icon: gcp:cloudsql,mdi:database
• display.color: google_blue;cerulean;blue;#0000ff

Describe alternatives you've considered

Alternatives include:

• Not doing this at all; using configuration elsewhere to drive the display: although separate configuration has its benefits, it can be a challenge for configuring multiple systems and can create repetitive configuration work.

• Supporting only one syntax for color: if only named colors were supported, it would be difficult to guarantee a fallback that will actually work; if only precise CSS colors were supported, then it would be difficult to supply names that can be dynamically evaluated (e.g. map to different actual colors in light mode vs dark mode), which could be limiting in the case where a particular provider has some support for theming.

• Supporting only one entry for color: given that color names (especially ones that reference a particular color palette or theme) may be unrecognized in some systems, lists are needed to ensure that there is some fallback.

• Supporting only one entry for icon: this would make it difficult for vendors to provide special support for icons corresponding to services in their platform. Multiple entries allows for fallback for unrecognized icons.

• Not supporting a well-defined namespace for icons out of the box: this would be a problem for being able to provide a reasonably working fallback solution

• Supporting a baseline namespace other than mdi: : the reason that Material Design Icons make sense to use as a default option is that it is both open-source and free to use (including commercially). If there is another icon font that is both open-source and free (even for commercial use), such an alternative could be reasonably suggested.

Additional context

No response

[nirga]

Interesting! I assume you expect these to be part of semantic conventions for each span definition which can then be read by the observability platform?