elastic/kibana

[APM] Remove usage of `getDocumentTypeFilterForTransactions`

Open

#167020 opened on Sep 22, 2023

View on GitHub
 (6 comments) (0 reactions) (0 assignees)TypeScript (19,065 stars) (8,021 forks)batch import
Team:obs-ux-infra_services - DEPRECATEDapm:service-metricsapm:transaction-metricsgood first issuetechnical debt

Description

Background

The APM UI is able to render using several different datasets:

  • raw transaction events
  • transaction metrics
  • service transaction metrics

The metric sets are further broken into intervals: 1m, 10m and 60m.

The UI should transparently use the most suitable, available dataset. This is what GET /internal/apm/time_range_metadata is for: it will decide which datasets are available for a given time range.

Problem

Currently some APIs like GET /internal/apm/services uses the time_range_metadata API for querying whilst other APIs like GET /internal/apm/services/{serviceName}/transaction_types do not and thus perform their own logic for determining which data to query. This results in some inconsistencies and outright bugs like seen in https://github.com/elastic/sdh-apm/issues/1078 (internal).

Solution

Every API that consumes (service) transaction metrics should use the information from time range metadata API as inputs. Specifically we should remove all usages of getDocumentTypeFilterForTransactions(searchAggregatedTransactions).

In some places we also call getDocumentTypeFilterForTransactions(true). We will still need this but it should be renamed to something likegetBackwardsCompatibleDocumentTypeFilterForOneMinuteTransactionMetrics().

Related

https://github.com/elastic/sdh-apm/issues/1078 https://github.com/elastic/kibana/pull/167500 (initial implementation)

Contributor guide

Tech stack
typescriptnodejsrest api
Domain
backend
Issue type
refactor
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
3-5 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Familiarity with Elastic APMUnderstanding of Kibana's internal APIsExperience with TypeScript
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
First, locate all usages of `getDocumentTypeFilterForTransactions` in the Kibana codebase. This function is likely in the APM plugin. The issue specifies that some APIs, like `GET /internal/apm/services`, already use the time range metadata API, while others, like `GET /internal/apm/services/{serviceName}/transaction types`, do not. For each usage, determine if it should be replaced with logic based on time range metadata. Additionally, rename calls with `getDocumentTypeFilterForTransactions(true)` to `getBackwardsCompatibleDocumentTypeFilterForOneMinuteTransactionMetrics()`. Refer to the initial implementation in PR #167500 and the related issue #1078 for context. Ensure no breaking changes and that all tests pass.