elastic/kibana

[Telemetry] Better error handling at the `telemetry_plugin_collector`

Open

#122634 opened on Jan 11, 2022

View on GitHub
 (4 comments) (1 reaction) (0 assignees)TypeScript (19,065 stars) (8,021 forks)batch import
Feature:TelemetryTeam:Coregood first issueimpact:lowloe:small

Description

In the telemetry_plugin_collector we are swallowing any errors thrown by getTelemetrySavedObject: https://github.com/elastic/kibana/blob/c2641bd8cc875dd50c63a40fbaf3054780cd570b/src/plugins/telemetry/server/collectors/telemetry_plugin/telemetry_plugin_collector.ts#L45-L52

I don't think that we should do this as we might report different data depending on whether there's an ES connection issue or not (because when there's no savedObject information we rely on the kibana.yml config values).

IMO, we should either let the collector fail or populate the related fields only when getTelemetrySavedObject succeeds.

Contributor guide

Tech stack
typescriptnodejs
Domain
backendobservability
Issue type
bug
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.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
TypeScriptNode.jsElasticsearchKibana telemetry
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
50
Research direction
The issue is located in `src/plugins/telemetry/server/collectors/telemetry plugin/telemetry plugin collector.ts` around line 45-52, where errors from `getTelemetrySavedObject` are currently swallowed. The two suggested approaches are to either let the collector fail or only populate fields when the call succeeds. A contributor should evaluate which approach is more appropriate for consistent telemetry data and implement the change. No linked PRs or assignees exist, so this is an open opportunity.