How add custom Spam information with Java agent

Elastic Observability APM
1

Hi,

I would like to know if there is a way to add custom information on a Spam ?
An example is to trace the values of parameters when a method is called or parameters on a SQL Query.
I know there is a risk about confidential data leak, it's trade off, and there is mechanism for this in the Http request's body tracing.
I looked to classical configuration, the public API and quick view of source code without success.

Thanks for your helps,
Philippe

2

Hi Philippe and welcome to the forum :slight_smile:

You can use labels (which are mapped to context.tags in APM server versions <7.0) .

I hope this is what you are looking for.

3

Hi Eyal,

I saw the labels, but there is this message :
The labels are indexed in Elasticsearch so that they are searchable and aggregatable. By all means, you should avoid that user specified data, like URL parameters, is used as a tag key as it can lead to mapping explosions.

I understand that it's not the right notion for my needs : add parameters values (methods' parameters and SQL Queries' parameters).
Is this right ?

Regards,
Philippe

4

This is about avoiding using high-cardinality spectrum for keys.
So you should come up with a way to use a limited range of keys. For example, if your keys are something like parameter1, parameter2 etc. (corresponding parameter order), you should be fine (assuming the number of parameters used in a single method/SQL-query is not very big).

On a side note, I am not sure how you intend to add SQL parameters - if you want to add to the automatically-generated DB spans, you need to instrument your code while the DB spans are active (i.e. after started and before ended), not sure if there's a way for you to do that. Otherwise, you will have to add the labels to your manually-created spans.

5

That's clear now. Is there a way to customize the way the span are logged when using the 'trace_methods' configuration ? Or should I reimplement my own plugin ?
I didn't see configuration for 'log levels', like tracing parameters.
Is it just something that may be implemented (but postponed as for now) ? Or is something that had been refused because it has a to huge impact on performance (is not in the philosophy of the tool) ?

For the SQL part, I didn't think how to implement it. I was just wondering about the capacity to store data. I will have a look to the implementation of the jdbc plugin now.

Thanks for your help.

6

We have this idea in mind, and we have a GitHub issue for that, which you can upvote to express your interest.
There will be performance implications and also increased risk of exposing sensitive data, which is part of the reason we are not decided on that yet.

Plugins are normally a way for supporting new libraries/infrastructures, and less for monitoring custom data. Using a plugin that we don't maintain would expose you to frequent breaks due to dependency on internal APIs. The way to go with custom data is using our public APIs. Those are very stable and you can get a very long way with them.

Again- better not add your code to the plugin, but find a way around it with the public APIs. For example, you can create a span in your DAO code (if you use such) where you can store SQL with parameters (in which case you actually may want to look into our plugin to see what we do to reduce related performance costs). Adding to the plugin may yield the best results, but you will take the risk of having to maintain more frequently.

7

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.