High cardinality for HTTP span names

[felixbarny]

I've noticed deviations from the HTTP span spec.

The Node.js agent sets the span.name to the full URL path, such as GET opbeans:3000/api/products/top. This leads to the span.name having a high cardinality. That's an issue as we'd like to create metrics that have the span name as a dimension. However, it's unclear whether we'd roll up metrics for http spans in the first iteration, or only for db spans.

Also, the properties context.http.url and context.http.status_code are not populated.

[astorm]

A fix for the high cardinality in http span names has been merged.

We're unable to reproduce the following behavior

Also, the properties context.http.url and context.http.status_code are not populated.

That is -- we do appear to be setting these values. Moving ticket to blocked until we can get a repro/description of the context behavior.

[astorm]

Re: the missing context.http.url and context.http.status_code -- when using an up to date agent and APM Server 7.12, the values from these fields end up populating the span.http object in the final Elasticsearch document.

Per this morning's planning meeting, the edge instance that didn't have these fields appears to be running APM Server 8.0 -- you can tell by both the _index field and the observer.version field.

It looks like the APM Server code that handles this transformation didn't land until 7.10.

In other words -- the agent is fulfilling its contract by setting these fields and modern versions of APM Server are correctly transforming them. The reason these fields are missing from the edge instance is an old version of APM server is shipping this data.

Moving this back into blocked for the time being.

[astorm]

Also, the properties context.http.url and context.http.status_code are not populated.

Per research done, this appears to have been an edge ingest issue. Current versions of the agent are setting these properties. Closing this out as done for now, but will reopen if more evidence comes forward.