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.

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

Create dummy /deep-dependencies endpoint #6606

Open
yurishkuro opened this issue Jan 25, 2025 · 7 comments · May be fixed by #6654
Open

Create dummy /deep-dependencies endpoint #6606

yurishkuro opened this issue Jan 25, 2025 · 7 comments · May be fixed by #6654
Labels
enhancement good first issue Good for beginners help wanted Features that maintainers are willing to accept but do not have cycles to implement

Comments

@yurishkuro
Copy link
Member

yurishkuro commented Jan 25, 2025

Jaeger-UI has "hidden" capabilities, namely a dependency graph view called "deep dependencies", which constructs the graph from paths extracted from traces . The corresponding server code was apparently never migrated out of Uber's internal code base. The proposal is to create the required endpoint in the jaeger-query but return some dummy data, which can later be extended with proper support for storage. The dummy data should use some obvious identifiers like sample-service-A, to make it obvious to the user that the data is not real. An alternative is to return just empty data but that is generally more confusing to the user.

This will need to be done with some reverse engineering of the UI code base because there is no other point of reference of what the data format should be. The main component in the UI is packages/jaeger-ui/src/components/DeepDependencies/*. An example of a valid URL is /deep-dependencies?operation=the-operation&service=the-service, but there are also other parameters like showOp=1.

The code that generates the real data can be found in https://github.com/jaegertracing/jaeger-analytics-flink.

A successful validation will be

  • running Jaeger, e.g. go run ./cmd/jaeger
  • navigating to /deep-dependencies in the UI to see the data

We should also add a check to the all-in-one e2e integration test that would query the same endpoint in the UI and get back some sensible result.

@yurishkuro yurishkuro added good first issue Good for beginners help wanted Features that maintainers are willing to accept but do not have cycles to implement labels Jan 25, 2025
@dosubot dosubot bot added the enhancement label Jan 25, 2025
@asimchoudhary
Copy link
Contributor

On it !

@adityachopra29
Copy link
Contributor

adityachopra29 commented Jan 30, 2025

@yurishkuro I looked through the jaeger-ui and I found the following:

The API for deep-dependancy-graph(ddg) is

  fetchDeepDependencyGraph(query) {
    return getJSON(`${ANALYTICS_ROOT}v1/dependencies`, { query });
  },

written in packages/jaeger-ui/src/api/jaeger.js, where query had the format:

export type TDdgSparseUrlState = {
  density: EDdgDensity;
  decoration?: string;
  end?: number;
  hash?: string;
  operation?: string;
  service?: string;
  showOp?: boolean;
  start?: number;
  visEncoding?: string;
};

written in packages/jaeger-ui/src/components/DeepDependencies/url.tsx

and had the response format as:

export type TDdgPayloadEntry = {
  operation: string;
  service: string;
};

export type TDdgPayloadPath = {
  path: TDdgPayloadEntry[];
  // TODO: Everett Tech Debt: Fix KeyValuePair types
  attributes: {
    key: 'exemplar_trace_id'; // eslint-disable-line camelcase
    value: string;
  }[];
};

export type TDdgPayload = {      --> final return type
  dependencies: TDdgPayloadPath[];  

defined in packages/jaeger-ui/src/model/ddg/types.tsx
Hence, the sample JSON return will look something like:

{
  "dependencies": [
    {
      "path": [
        {
          "service": "serviceA",    // Required: name of service
          "operation": "opA"        // Required: name of operation
        },
        {
          "service": "serviceB",
          "operation": "opB"
        }
      ],
      "attributes": [
        {
          "key": "exemplar_trace_id",  // Required: must be this exact string
          "value": "abc123"            // Required: trace ID as string
        }
      ]
    }
  ]
}

Pls have a look If this is correct and I will make the corresponding API in jaeger-query.

Also, in the ui, the endpoints are designed for v1, as shown here:

export const DEFAULT_API_ROOT = prefixUrl('/api/');
export const ANALYTICS_ROOT = prefixUrl('/analytics/');

  fetchDeepDependencyGraph(query) {
    return getJSON(`${ANALYTICS_ROOT}v1/dependencies`, { query });
  },

So do we create this for v1 or has support for v2 also been created?

Right now I had planed on adding the api in cmd/query/app/apiv3/http_gateway.go, with the endpoint
/api/v3/analytics/dependancies, assuming there is support in JaegerV2. Is this suitable?

@yurishkuro
Copy link
Member Author

@adityachopra29 the data shape looks right-ish. Best way it to just try to point the UI to an implementation and see if it renders something. We can change the API endpoints - for compatibility reasons it might be good to have it as a UI config option. By default it could go to /api/deep-dependencies (I don't think it should go to /api/v3, that is different).

@adityachopra29
Copy link
Contributor

adityachopra29 commented Feb 2, 2025

@yurishkuro I was trying to test my new api, when I ran into a few doubts I wanted to clarify:

  • Right now, the deep dependency graphs are being rendered properly when I use the Deep Dependency button.
    • Are they still using the backend present in Uber's internal codebase? Reason I am asking is because as per my
      understanding, that codebase was closed source, and so the ddg should not have been working.
    • If we redirect our frontend to the newly formed api, the feaure will stop working. Do we want that?
  • It seems to me that the Deep Dependency graph button (in the top right corner) does not use the fetchDeepDependencyGraph() api defined in the ui.
    Reason for this is that I changed the api:
  fetchDeepDependencyGraph(query) {
    return getJSON(`${ANALYTICS_ROOT}v1/dependencies, { query });
  },

to something random, like:

  fetchDeepDependencyGraph(query) {
    return getJSON(`${ANALYTICS_ROOT}v1grgg/dependenciesgrgw`, { query });
  },

and the the ddg are still generated by the button. I wasnt able to pinpoint the exact service, because the the enpoint seems to be hashed in some way when I tried to look for it in the networks tab of console.
Also, on going to the url localhost:16686/${ANALYTICS_ROOT}v1/dependencies = localhost:16686/analytics/v1/dependencies, I keep getting redirected to the default page, which suggests that the endpoint does not exists. This also suggests that the deep-dependencies endpoint is not being used.

Image

Hence, I am not able to understand the required user flow for deep-dependencies.

@adityachopra29 adityachopra29 linked a pull request Feb 2, 2025 that will close this issue
4 tasks
@yurishkuro
Copy link
Member Author

@adityachopra29 do not confuse Deep Dependencies button on the Search screen and the actual page. The former constructs the graph purely from the search results and does not need to make calls to the backend. But the top-level endpoint /deep-dependencies would be expected to make a call to the backend.

https://github.com/jaegertracing/jaeger-ui/blob/dc642b0b152e064beadd04f5899155c4de6b7983/packages/jaeger-ui/src/components/DeepDependencies/url.tsx#L24

@adityachopra29
Copy link
Contributor

Best way it to just try to point the UI to an implementation and see if it renders something

@yurishkuro
Can you please explain what portion of the frontend should be rendering something to new endpoint then, if it is not the Deep Dependency Graph button? Right now the endpoint just renders the sample json as it is. But that does not provide any validity as to whether the data is correct (as it will render anything I want)

@yurishkuro
Copy link
Member Author

yurishkuro commented Feb 2, 2025

The /deep-dependencies URL in the UI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement good first issue Good for beginners help wanted Features that maintainers are willing to accept but do not have cycles to implement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants