elastic/kibana

Describe the feature: Align the three RED metric charts (Latency, Throughput, Failed transaction rate) in the APM service flyout and in the child flyouts opened from it (today: the transaction detail flyout), so that the chart titles and plot areas sit on the same horizontal line. The thing breaking the alignment is the latency aggregation select (LatencyAggregationTypeSelect): it is the only control living in a chart header, and in the narrow flyout columns it either wraps or is stacked under the title, which makes the latency panel header one row taller than the other two. Two changes fix it: Render the select inline in the latency chart title row (the pattern already used by the flyout's Lens charts). Shorten the option labels so the select fits in a narrow column: Average → Avg, 95th percentile → p95th, 99th percentile → p99th (and any future option follows the same short form). Describe a specific use case for the feature: The service flyout is the main entry point for RED

What? Show the number of overflowing services in the capacity warning tooltip and/or popup message on the Services list. Currently the _other / "Remaining Services" row shows a generic warning message: "The cardinality of APM data being collected is too high. Please review docs to mitigate the situation." The backend already returns serviceOverflowCount (the count of services that were cut off beyond the 1,000-service cap), and this value is passed all the way down to the ServiceLink component via props — but is never rendered. Suggested improvement: include the overflow count in the warning, e.g.: "The number of services has exceeded the maximum capacity. 47 additional services are not shown. Please review [docs] to mitigate the situation." Out of scope: changing the backend cap itself. Why? Without a count, users have no way to know how many services they are missing. A concrete number helps them assess the urgency of the situation and decide whether to apply filters, increase th

Summary When the LLM judge marks a criterion "N/A", the framework adds that criterion's full weight to the score exactly as if it had passed. An output where every criterion is not applicable scores a perfect 1.0. In the discovery suite, the severity and confidence calibration evaluators have no guard for empty output, so an agent that wrongly dismisses every detection (producing zero open events, a clear failure) is handed perfect calibration scores that inflate its composite result and mask the failure. Evidence totalScore = sumBy(successful.concat(notApplicable), ...) while maxScore covers all criteria, so N/A contributes to the numerator like a PASS (kbn-evals/src/evaluators/criteria/index.ts:135-138, final score at :158) The calibration evaluators are built without a skipWhen guard (src/evaluators/discovery/common/scores_calibration.ts:62-76) The guard mechanism exists and returns score: null when used, so this requires just wiring (src/evaluators/scenario_criteria/evaluators.ts:

Kibana version: main Elasticsearch version: Server OS version: Browser version: Browser OS version: Original install method (e.g. download page, yum, from source, etc.): Describe the bug: In Kibana’s share UI, if the /short_url request fails, the "Copy link" button stays stuck in a loading/disabled state and the user gets no feedback that something went wrong. Steps to reproduce: Open a Dashboard in Kibana In DevTools, block requests to /short_url Open Share and click Copy link Observe the Copy button stuck in a loading/disabled state with no error feedback Expected behavior: When /short_url fails, show a toast that a URL could not be generated, and leave the Copy link button clickable so the user can retry without closing the modal. Screenshots (if relevant): Errors in browser console (if relevant): N/A Provide logs and/or server output (if relevant): Any additional context: Reproduces on main.

Problem The node scripts/evals CLI has two profile flags whose names describe only a subset of what they actually control: Flag Env vars it sets What it actually controls --datasets-profile EVALUATIONS_KBN_URL, EVALUATIONS_KBN_API_KEY (+ GCS_CREDENTIALS) The Kibana that stores datasets, score ingestion, and experiment reads (the single EvalsClient target) --export-profile TRACING_ES_URL, TRACING_ES_API_KEY, TRACING_EXPORTERS Where EDOT exports traces and which ES the trace-based evaluators query So: --datasets-profile local does not only point datasets at local Kibana - it also ingests eval scores into (and reads experiment stats/scores back from) that same Kibana. The name implies datasets-only. --export-profile is really a tracing target (export destination + trace-query source). The generic word "export" gives no hint that it is about traces. The underlying env vars (EVALUATIONS_KBN_*, TRACING_*) are accurately named. It is the two CLI flags that have drifted from what