Custom field (tag, label, whatever...) available in transaction and subsequent spans (without defining them)

[J_Weeda (J)]

Kibana version: 7.0.0

Elasticsearch version: 7.0.0

APM Server version: 7.0.0

APM Agent language and version:
agent.name js-base
agent.version 4.0.2

Elasticstack hosted on Elastic Cloud.

We are trying to add a custom field which is available in both the transaction and all subsequent spans without having to specify the spans. Would you have a way to accomodate that?

Below calls only populate the transaction docs.

  transaction.addTags({'team': 'Tag'});
  elasticApm.setCustomContext({'team': 'Context'});

[Hamidreza (Hamidreza Jahtalabziabari)]

Hi @J_Weeda,

Thanks for reaching out.
At the moment, this is not possible. We try to mindful of the extra information we put on spans since they can increase the payload and storage costs.

Would you please explain a little bit more about your use-case?

Cheers,
Hamid

[J_Weeda (J)]

Hi @Hamidreza , ty for your reply. As per your question; we are trying to maintain multitenancy on doc level. This implies roles which have access to specific documents limited by following statement in the Granted documents query field in the Role definition:

{"term":{"team":"team_A"}}

This worked fine on any docs we ingested from Beats but now APM comes into play which doesn't give us the document level control we require. Makes sense? Any recommendations?

[Hamidreza (Hamidreza Jahtalabziabari)]

Thank you for the explanation. That makes a lot of sense. I have created this issue to address this request.

[roncohen]

Hi @J_Weeda

If you run an APM Server per tenant/customer, you can set each one up to write to a specific pipeline that would add the fields you need to do index level security. You could also add a processor in APM Server to get the field added, but it's not currently documented.

Would this be an option for you?

best,
Ron

[J_Weeda (J)]

hi @roncohen, thanks. Yes, it would be an option for a later stage where we need to scale up. For now we need to stick to a single instance.

We found a way to get the desired in place. We abuse the service field using a delimited value team#service and strip and write the team value to a dedicated field through logstash.

Thank you for your thoughts and views.

[roncohen]

Cool @J_Weeda. Another potential option is to use Attribute Based Access Control to limit certain roles to documents that have certain services.name: https://www.elastic.co/blog/attribute-based-access-control-with-xpack