Traces/Services - Query optimization / UI setting / Bugfix

[TackAdam]

Description

1. Remove the all_services aggregation field from getRelatedServiceQuery. The only purpose seemed to be in displaying the “greyed-out” connection in service map. Earlier code changes removed the full map being displayed with this grey-out functionality in preference of the “Focus on” search box being implemented. This field being presented seemed to require a 4x increase in the number of buckets.

• Removed the shading logic from getServiceMapGraph as we no longer enter that state based on related services.

2. Remove the traceGroupName aggregation field from getServiceNodesQuery. This appeared to be an old artifact and was not used in any visualizations.
3. Remove the toast messages after the first check of handleServiceMapRequest as they were indicating false positives as the map took time to render.
4. Add "TRACE_CUSTOM_MODE_DEFAULT_SETTING" option for users to enable it as the default landing page. Update the fly-out for custom source to include the option to enable this. When the mode is not presented and this setting is enabled it will direct the user to correct mode.
5. Update the error field for custom spans under the non "traces" field. It was originally using the >0 check used for error_count but this field uses status.code which is only an error when it is equal to 2. https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#set-status

• Added renderStatusCodeErrorsField() as it's behavior is different for custom traces checking the spans and needs to do the ===2 check similiar to https://github.com/opensearch-project/dashboards-observability/blob/main/public/components/trace_analytics/requests/traces_request_handler.ts#L403

6. Update the Services table link, and Expand view buttons to append the trace mode to allow it to be used as a favorite or shared link.
7. Fix a bug that was causing infinite refreshes if MDS was disabled and the service page - traces link was clicked as the datasource was appended as undefined.
8. Fix flaky cypress test in services by adding wait condition.

Before: (with all_services)

PUT _cluster/settings
{ "persistent": { "search.max_buckets": 450 } }

Before_460Buckets.mov

Required 460 buckets to avoid errors.
After: (removed all_services)

After_110Buckets.mov

Required just 110 buckets to avoid errors.

TRACE_CUSTOM_MODE_DEFAULT_SETTING:


Example usage:

CustomModeSetting.mov

Service page infinite refresh while MDS disabled bug Before:

Screen.Recording.2025-01-14.at.4.31.31.PM.mov

After (fixed):

Screen.Recording.2025-01-14.at.4.37.14.PM.mov

Issues Resolved

[List any issues this PR will resolve]

Check List

• New functionality includes testing.
  • All tests pass, including unit test, integration test and doctest
• New functionality has been documented.
  • New functionality has javadoc added
  • New functionality has user manual doc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[RyanL1997]

Hi @TackAdam , thanks for putting this together. And I just left some comments.

[joshuali925]

this logic no longer consider traceGroup filters in DSL anymore, does it change behavior of service metrics when filtering by trace group?

seems it would always consider all targetResources instead of the subset of targetResources that belong to services with traceGroups matching the user's traceGroup filter, which should cause a difference?

I'm ok if the difference it makes is not meaningful for users, just want to check if it's what we want

[RyanL1997]

LGTM. Once we address @joshuali925 's comment we can proceed to merge

[joshuali925]

also CI has been failing?

[TackAdam]

also CI has been failing?

Added in

interface ServiceMapParams {
  map: ServiceObject;
  idSelected: 'latency' | 'error_rate' | 'throughput';
  ticks: number[];
  currService?: string;
  filterByCurrService?: boolean;
}

To clean up the code readability when removing the related service param. Had to adjust the test as well I missed in last commit. Should pass now, will wait for run to complete.