The DevEx team (former devtools/clients team) has been using a special HTTP header (x-elastic-client-meta) to capture and measure useful telemetry data points for Elasticsearch client activity that flows through the Cloud proxy. As of now, that only covers Elasticsearch APIs, as that was the original intended scope. This CLI expands the scope out to several other APIs whose activity we won't be able to track, but should.
Requirements:
- Create a core HTTP client utility module used throughout the CLI that is a thin abstraction over
fetch
- Stretch goal: see if it's reasonable to rip
@elastic/transport out as a dependency for ES API calls; most of its functionality is optimized for keep-alive HTTP connection pooling, node-sniffing, etc., which is not relevant to the CLI because it always exits after one HTTP request
- Ensure all HTTP requests include an
x-elastic-client-meta header
- Add tests that will fail if ANY API does not include this header
See the DevEx team for internal docs on how to craft valid header values.
The DevEx team (former devtools/clients team) has been using a special HTTP header (
x-elastic-client-meta) to capture and measure useful telemetry data points for Elasticsearch client activity that flows through the Cloud proxy. As of now, that only covers Elasticsearch APIs, as that was the original intended scope. This CLI expands the scope out to several other APIs whose activity we won't be able to track, but should.Requirements:
fetch@elastic/transportout as a dependency for ES API calls; most of its functionality is optimized for keep-alive HTTP connection pooling, node-sniffing, etc., which is not relevant to the CLI because it always exits after one HTTP requestx-elastic-client-metaheaderSee the DevEx team for internal docs on how to craft valid header values.