Instana Application Analyze API

The API endpoints of this group expose our analyze functionality. It includes: **Grouped Metrics** Two group endpoints to retrieve metrics for traces and calls. **List of traces and its detailed information** You can also [search and filter all traces](#operation/getTraces) and retrieve [all details](#operation/getTraceDownload) attached to the trace. Furthermore, you can also retrive [all details](#operation/getCallDetails) of a call. ## Parameters ### Mandatory Parameters (only for group Endpoints): **group** It is mandatory to select a tag by which the calls and traces are grouped for the distinct endpoint call * *groupByTag* select a tag by which the calls and traces are grouped * a full list of available tags can be retrieved from the [application tag catalog](#operation/getApplicationTagCatalog) * for the trace endpoint only two tags are reasonable and working: `trace.endpoint.name` and `trace.service.name` which indicate the entry endpoint or service for the trace * *groupByTagSecondLevelKey* tags of type KEY_VALUE_PAIR need a second parameter e.g for `kubernetes.deployment.label` you would need provide the label you want to groupBy here. ### Optional Parameters **pagination** * *offset* set the starting point for the data retrieval * *retrievalSize* you set the number of returned values * *ingestionTime* if you want to paginate through your result set you are interested in having the data for a fixed time point, the results set has a `cursor` class that has a ingestionTime property that indicates what you have to enter here. **order** **timeFrame** As in our UI you can specify the timeframe for metrics retrieval. ``` windowSize to (ms) (unix-timestamp) <----------------------| ``` The timeFrame might be adjusted to fit the metric granularity so that there is no partial bucket. For example, if the query timeFrame is 08:02 - 09:02 and the metric granularity is 5 minutes, the timeFrame will be adjusted to 08:05 - 09:00. The adjusted timeFrame will be returned in the response payload. If the query does not have any metric with granularity, a default granularity will be used for adjustment. **tagFilters** As in the UI you able to filter your query by a tag. To get a list of all available tags you can query the [application tag catalog](#operation/getApplicationTagCatalog) * *name* The name of the tag as returned by the catalog * *value* The filter value of the tag, possible types are: * "STRING" alphanumerical values, valid operators: "EQUALS", "CONTAINS", "NOT_EQUAL", "NOT_CONTAIN", "NOT_EMPTY", "IS_EMPTY" * "NUMBER" numerical values, valid operators: "EQUALS", "LESS_THAN" "GREATER_THAN" * "KEY_VALUE_PAIR" * *operator* one of the valid operators for the type of the selected tag **metrics** A list of metric objects that define which metric should be returned, with the defined aggregation. Each metrics objects consists of minimum two items: 1. *metric* select a particular metric, available metrics in this context are * Latency Mean * Error Rate * Traces Sum 2. *aggregation* depending on the selected metric different aggregations are available e.g. SUM, MEAN, P95. The aforementioned [catalog endpoint](#operation/getApplicationCatalogMetrics) gives you the metrics with the available aggregations. **Note**: The above mentioned list of available metrics with its supported metrics can also be found in [Get grouped call metrics](#operation/getCallGroup) and [Get grouped trace metrics](#operation/getTraceGroups). 3. *granularity* * If it is not set you will get a an aggregated value for the selected timeframe * If the granularity is set you will get data points with the specified granularity **in seconds** * The granularity should not be greater than the `windowSize` (important: `windowSize` is expressed in **milliseconds**) * The granularity should not be set too small relative to the `windowSize` to avoid creating an excessively large number of data points (max 600) ### Defaults: **timeFrame** ``` "timeFrame": { "windowSize": 60000, "to": {current timestamp} } ```