How to filter `Ask<T>` out of traces?

[object]

We are getting many traces from Ask invocations (this is another issue that I will file, trying to reproduce it on a small example), and to get rid of Ask traces I want to exclude traces by actor path. All Ask operaions include sending a message to an intermediate actor that has a path akka:///temp/ and I want to filter out all messages sent to actors /temp/*. I remember @Aaronontheweb mentioned that in addition to filtering out messages by type, there can also be excluded all messages sent to a specified actor path. But I can't find any documentation or example of how to use such filtering.

[Aaronontheweb]

Hi @object - when automatic span creation is turned on we don't have the ability to filter traces based on the path currently. We can definitely disable Ask traces with a new setting if you'd like.

[object]

@Aaronontheweb is there any tracing scenario when filter based on the path can be enabled? I am still testing various configuration options, so if there is a way to control selective span creation based on actor paths, I'd like to give it a try,

When it comes to Ask, we are definitely interested in disabling messages sent to an internal /temp/xxx actor. I also wonder whether traces from this actor are of any use for anyone. Because of the special nature of Ask, it involves 3, not 2 actors, so if actor /user/a sends Ask to /user/b, then Akka will silently create a temporary helper actor /temp/xxx. Currently I can see plenty of trace spans for this actor, but they contain no useful information. Here's an example of fields of such span:

Timestamp: 2022-07-13T12:22:08.7314042Z
akka.actor.recv.msgType: object
akka.actor.recv.sender: akka://Oddjob/temp/7R
duration_ms: 2730.6774
name: akka.actor.ask object
span.kind: internal
type: internal

(some other fields are removed)

As you see, the trace data are absolutely useless because they don't even contain the recipient path, so there is no way to relate this data to anything. Yes, we would certainly like to disable them - they create a lot of noise for us, but perhaps you should consider removing Ask spans all together. You managed to hide the logic behind stashed messages so stash is transparent for trace spans. Perhaps Ask internals need a similar effort so they won't be reflected in trace transactions.

[Aaronontheweb]

It wasn't until pretty recently that Ask<T> operations could be traced - we added it because it's a popular option for developers building Web APIs. But I could easily add a toggle to disable it. When automatic span creation is on we are able to correlate this using the corresponding msg.recev span that occurs right afterwards. I believe we were limited from an API pov - which is why we don't record the upfront destination.

I'll add a feature toggle to turn this off.

[Aaronontheweb]

I @object - it's been a while since we discussed this but I wanted to let you know that we're picking up work on this and your other issue today.

[Aaronontheweb]

This issue was closed automatically because I just merged a fix for this:

phobos.tracing.trace-ask = off

or

collection.AddAkka("LocalSys", (builder, sp) =>
{
    builder.WithPhobos(AkkaRunMode.Local, 
        configBuilder => configBuilder.WithTracing(t => t.SetTraceAsk(false)));
    AddTestActors(builder);
});

We'll be rolling this into the next release of Phobos once I've had a chance to resolve your other open issue.

[object]

Thanks, very much appreciated. I am taking a one week vacation, back to business on Monday August 8. I will check this out then.