Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Reconsider structure of `context.db.statement`

See original GitHub issue

We utilise the Node JS agent to capture Elasticsearch queries from Kibana. For this we need the full content body which is currently captured in the field context.db.statement. This value, however, contains the request body and URL (with parameters) delimited by two new lines. In order for us to extract the ES body + index name + any parameters, we currently parse this payload client side.

This obviously works it makes our code susceptible to changes in the agent. Whilst fields are governed by ECS and a change control process, are changes in the structure of field values also considered potentially breaking changes? If so, could such changes be made in a minor or could we rely on their consistency across majors? https://www.elastic.co/guide/en/apm/agent/nodejs/current/release-notes-3.x.html#release-notes-3.10.0 suggests that changes can be made in a minor which is concerning.

This is further complicated by the fact we use the agent version distributed with Kibana, so we would need to track the agent version this uses.

One proposal is that these values be stored in separate fields i.e. only the request body be stored in context.db.statement and the params and index names be stored in separate fields. The agent would in effect be responsible for parsing these values. Whilst we would prefer this solution, we appreciate that is a decision beyond a single agent.

@trentm