Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Feature]: Keep Operation field filled in when switching to Service that has the same operation name #985

Open
MadLittleMods opened this issue Aug 31, 2022 · 1 comment
Open

[Feature]: Keep Operation field filled in when switching to Service that has the same operation name #985

MadLittleMods opened this issue Aug 31, 2022 · 1 comment
Labels
enhancement help wanted

Comments

@MadLittleMods
Copy link

Requirement

As a Jaeger user, I want the Operation field to be maintained when switching Services so that I don't have to keep changing it.

Problem

When switching services, the Operation field is reset back to all. But since I am just switching between different numbered instances of the same service, it's very annoying to keep setting the Operation back to what I am trying to search for in them.

Screen.Recording.2022-08-31.at.4.37.12.PM.mov

Proposal

Keep the Operation field as-is if the newly selected service has the same Operation available.

An alternative could be searching across many services, #180

Open questions

No response
@yurishkuro
Copy link
Member

I think it makes sense, but I also think it's a pretty niche use case, as services are supposed to implement different APIs so overlap in operation names would be only coincidental (your setup seems to be using service instance ID as service name).

@MadLittleMods MadLittleMods mentioned this issue Sep 6, 2022
Merged
4 tasks
MadLittleMods added a commit to matrix-org/synapse that referenced this issue Sep 9, 2022
@MadLittleMods
Strip number suffix from instance name to consolidate services that t…
f694bb7 
…races are spread over (#13729)

The problem with many services is that it makes it hard to find which service has the trace you want, see jaegertracing/jaeger-ui#985

Previously, we split traces out into services based on their instance name like `matrix.org client_reader-1`, etc but there are many worker instances of the same `client_reader` so there is a lot to click through.

With this PR, all of the traces are just collected under the worker type like `client_reader`, `event_persister` 😇

Note: A Synapse worker instance name is an opaque string with the number convention only being our own thing for the `matrix.org` deployment. But seems pretty sensible to group things this way.
realtyem pushed a commit to realtyem/synapse-unraid that referenced this issue Sep 10, 2022
@MadLittleMods @realtyem
Strip number suffix from instance name to consolidate services that t…
b5c4a72 
…races are spread over (#13729)

The problem with many services is that it makes it hard to find which service has the trace you want, see jaegertracing/jaeger-ui#985

Previously, we split traces out into services based on their instance name like `matrix.org client_reader-1`, etc but there are many worker instances of the same `client_reader` so there is a lot to click through.

With this PR, all of the traces are just collected under the worker type like `client_reader`, `event_persister` 😇

Note: A Synapse worker instance name is an opaque string with the number convention only being our own thing for the `matrix.org` deployment. But seems pretty sensible to group things this way.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@MadLittleMods @yurishkuro