fix(tracing): map some span names to their new names

packages/core/tracing/src/components/trace-viewer/SpanDescription.vue

@@ -1,5 +1,5 @@
 <template>
-  <KCard>
+  <KCard class="span-description-card">
     <p class="span-description">
       <span class="name">
         {{ span.name }}:
@@ -21,10 +21,10 @@
 </template>
 
 <script setup lang="ts">
-import { getPhaseAndPlugin } from '../../utils'
+import { computed } from 'vue'
 import composables from '../../composables'
 import type { SpanNode } from '../../types'
-import { computed } from 'vue'
+import { getPhaseAndPlugin } from '../../utils'
 
 const { i18n: { t, te } } = composables.useI18n()
 
@@ -40,6 +40,10 @@ const description = computed(() => {
 </script>
 
 <style lang="scss" scoped>
+.span-description-card {
+  padding: $kui-space-50;
+}
+
 .span-description {
   margin: 0;
 

packages/core/tracing/src/locales/en.json

@@ -35,6 +35,7 @@
           "plugin": "This span captures the execution time of the plugin that runs in the certificate phase. Multiple instances of this span can occur, one per plugin configured to run in this phase."
         },
         "dns": "Kong does most of it's DNS lookup asynchronously, but depending on configuration or custom_plugin code Kong may have to do synchronous DNS lookups. This span captures the time taken to resolve DNS queries.",
+        "find_upstream": "For each upstream target marked as healthy, Kong will attempt to open a TCP connection, optionally do a TLS handshake and send over the request headers. If all of this succeeds, Kong will finish sending the full request and wait for a response. If any of the step fails, Kong will switch to the next upstream and try again. This span captures the time taken to validate a specific upstream.",
         "flush_to_downstream": "This span measures the time taken for the client to read the response once it sent from Kong. This span can identify clients that are slow at reading responses, or are trying to read responses over slow connections.",
         "header_filter": {
           "plugin": "This span captures the execution time of the plugin that runs in the header_filter phase. Multiple instances of this span can occur, one per plugin configured to run in this phase."
@@ -52,6 +53,7 @@
         },
         "read_client_http_body": "This span captures the time taken to read the full body of the request from the client. This span can be very useful to determine if a client is on a slow network, sending a large body or simply taking too long to send a POST/PUT/PATCH body.",
         "read_client_http_headers": "This span captures the time taken to read the full set of http headers from the client. This span can be very useful to determine if a client is slow or may be coming over a slow or problematic network.",
+        "read_response_from_upstream": "Span capturing the time taken for the upstream to generate a full response. This effectively measures the time Kong sees between the first byte of the response header and the last byte of the response body coming from the upstream. This span can be used to identify slowness in response generation from upstream.",
         "response": {
           "plugin": "This span captures the execution time of the plugin that runs in the response phase. Multiple instances of this span can occur, one per plugin configured to run in this phase."
         },
@@ -60,11 +62,9 @@
         },
         "router": "This span captures the time taken by the router to search for a match. The span attributes return interesting information about the match.",
         "upstream": {
-          "try_select": "For each upstream target marked as healthy, Kong will attempt to open a TCP connection, optionally do a TLS handshake and send over the request headers. If all of this succeeds, Kong will finish sending the full request and wait for a response. If any of the step fails, Kong will switch to the next upstream and try again. This span captures the time taken to validate a specific upstream."
+          "selection": "Depending on configuration, Kong will try to find a healthy upstream by trying various targets in order determined by the configured load balancing algorithm. This span captures the total time spent in finding a healthy upstream. Child spans of this span capture the individual attempts."
         },
-        "upstream_read_response": "Span capturing the time taken for the upstream to generate a full response. This effectively measures the time Kong sees between the first byte of the response header and the last byte of the response body coming from the upstream. This span can be used to identify slowness in response generation from upstream.",
-        "upstream_selection": "Depending on configuration, Kong will try to find a healthy upstream by trying various targets in order determined by the configured load balancing algorithm. This span captures the total time spent in finding a healthy upstream. Child spans of this span capture the individual attempts.",
-        "upstream_ttfb": "Span capturing the \"time to first byte\" from the upstream. This includes the time taken to finish writing the http request to upstream, and the time taken by the upstream to start generating a response. This span can be used to identify network delays between Kong and an upstream as well as identifying upstreams that take long to start generating a response."
+        "waiting_for_upstream": "Span capturing the \"time to first byte\" from the upstream. This includes the time taken to finish writing the http request to upstream, and the time taken by the upstream to start generating a response. This span can be used to identify network delays between Kong and an upstream as well as identifying upstreams that take long to start generating a response."
       }
     },
     "span_events": {

packages/core/tracing/src/utils/spans.ts

@@ -2,6 +2,16 @@ import { cloneDeep } from 'lodash-es'
 import { SPAN_ZERO_ID } from '../constants'
 import { type IAnyValue, type Span, type SpanNode } from '../types'
 
+/**
+ * These are spans whose names are changed.
+ * Here we will map them to their new names, and use them in the following steps.
+ */
+const MAPPED_SPAN_NAMES: Record<string, string> = {
+  'kong.upstream.try_select': 'kong.find_upstream',
+  'kong.upstream.ttfb': 'kong.waiting_for_upstream',
+  'kong.upstream.read_response': 'kong.read_response_from_upstream',
+}
+
 /**
  * Iterate over the spans and build span trees, where each tree stores a trace.
  *
@@ -50,7 +60,7 @@ export const buildSpanTrees = (spans: Span[]): SpanNode[] => {
         traceId,
         spanId,
         parentSpanId,
-        name,
+        name: MAPPED_SPAN_NAMES[name] || name,
         startTimeUnixNano,
         endTimeUnixNano,
         attributes: cloneDeep(attributes), // Avoid mutating the original attributes