Store APIKey in FakeIntake per payload, add /debug/lastAPIKey #33899

dustmop · 2025-02-10T21:38:09Z

What does this PR do?

Stores APIKeys in the FakeIntake. Clients can use client.GetLastAPIKey to retrieve the most recently seen apiKey. Retrieving payloads using /fakeintake/payloads?endpoint=[endpoint] will also include the apiKey for each payload.

Motivation

Test that apiKeys can be refreshed and that the fakeIntake will observe the change.

Describe how you validated your changes

An upcoming PR will include an e2e test that uses this functionality.

To manually test, run the fakeintake in one terminal:

cd test/fakeintake/cmd/server
go run .

Then run the agent, with the DD_API_KEY env var defined to have a valid api key:

DD_API_KEY=$DD_API_KEY DD_URL=http://localhost:80  bin/agent/agent run -c bin/agent/dist/datadog.yaml

Then curl the fakeintake's debug endpoint to see the api key in use:

curl -L "http://localhost:80/fakeintake/payloads?endpoint=/intake/"

Possible Drawbacks / Trade-offs

Additional Notes

agent-platform-auto-pr · 2025-02-10T21:50:03Z

Static quality checks ✅

Please find below the results from static quality gates

Info

Result	Quality gate	On disk size	On disk size limit	On wire size	On wire size limit
✅	static_quality_gate_agent_deb_amd64	836.86MiB	858.45MiB	202.9MiB	214.3MiB
✅	static_quality_gate_docker_agent_amd64	921.67MiB	942.69MiB	308.65MiB	321.56MiB
✅	static_quality_gate_docker_agent_arm64	934.04MiB	952.69MiB	292.63MiB	351.22MiB
✅	static_quality_gate_docker_agent_jmx_amd64	1.09GiB	1.11GiB	383.76MiB	395.8MiB
✅	static_quality_gate_docker_agent_jmx_arm64	1.09GiB	1.11GiB	363.72MiB	375.5MiB
✅	static_quality_gate_docker_dogstatsd_amd64	47.86MiB	57.88MiB	18.29MiB	28.29MiB
✅	static_quality_gate_docker_dogstatsd_arm64	46.26MiB	56.27MiB	17.06MiB	27.06MiB
✅	static_quality_gate_docker_cluster_agent_amd64	267.69MiB	277.7MiB	107.27MiB	117.28MiB
✅	static_quality_gate_docker_cluster_agent_arm64	283.72MiB	293.73MiB	102.1MiB	112.12MiB

agent-platform-auto-pr · 2025-02-10T21:50:28Z

Uncompressed package size comparison

Comparison with ancestor 44cdd7348582d5e672a5bdecf67ce41ad8c36857

Diff per package

package	diff	status	size	ancestor	threshold
datadog-agent-aarch64-rpm	0.00MB	✅	863.87MB	863.87MB	0.50MB
datadog-agent-arm64-deb	0.00MB	✅	854.12MB	854.12MB	0.50MB
datadog-dogstatsd-amd64-deb	0.00MB	✅	59.04MB	59.04MB	0.50MB
datadog-dogstatsd-x86_64-rpm	0.00MB	✅	59.12MB	59.12MB	0.50MB
datadog-dogstatsd-x86_64-suse	0.00MB	✅	59.12MB	59.12MB	0.50MB
datadog-dogstatsd-arm64-deb	0.00MB	✅	56.53MB	56.53MB	0.50MB
datadog-heroku-agent-amd64-deb	0.00MB	✅	440.97MB	440.97MB	0.50MB
datadog-iot-agent-amd64-deb	0.00MB	✅	86.36MB	86.36MB	0.50MB
datadog-iot-agent-x86_64-rpm	0.00MB	✅	86.43MB	86.43MB	0.50MB
datadog-iot-agent-x86_64-suse	0.00MB	✅	86.42MB	86.42MB	0.50MB
datadog-iot-agent-arm64-deb	0.00MB	✅	82.62MB	82.62MB	0.50MB
datadog-iot-agent-aarch64-rpm	0.00MB	✅	82.69MB	82.69MB	0.50MB
datadog-agent-x86_64-rpm	-0.00MB	✅	875.38MB	875.38MB	0.50MB
datadog-agent-x86_64-suse	-0.00MB	✅	875.38MB	875.38MB	0.50MB
datadog-agent-amd64-deb	-0.00MB	✅	865.61MB	865.61MB	0.50MB

Decision

✅ Passed

agent-platform-auto-pr · 2025-02-10T21:50:32Z

[Fast Unit Tests Report]

On pipeline 55746137 (CI Visibility). The following jobs did not run any unit tests:

Jobs:

tests_windows-x64

If you modified Go files and expected unit tests to run in these jobs, please double check the job logs. If you think tests should have been executed reach out to #agent-devx-help

agent-platform-auto-pr · 2025-02-10T22:20:22Z

Test changes on VM

Use this command from test-infra-definitions to manually test this PR changes on a VM:

inv aws.create-vm --pipeline-id=55746137 --os-family=ubuntu

Note: This applies to commit 876e191

cit-pr-commenter · 2025-02-11T16:09:16Z

Regression Detector

Regression Detector Results

Metrics dashboard
Target profiles
Run ID: aed9e8aa-9abd-4588-b307-092a330ae65f

Baseline: 44cdd73
Comparison: 876e191
Diff

Optimization Goals: ✅ No significant changes detected

Fine details of change detection per experiment

perf	experiment	goal	Δ mean %	Δ mean % CI	trials	links
➖	uds_dogstatsd_to_api_cpu	% cpu utilization	+1.91	[+1.03, +2.78]	1	Logs
➖	file_to_blackhole_1000ms_latency_linear_load	egress throughput	+0.21	[-0.26, +0.68]	1	Logs
➖	file_to_blackhole_500ms_latency	egress throughput	+0.10	[-0.68, +0.87]	1	Logs
➖	file_to_blackhole_0ms_latency_http1	egress throughput	+0.04	[-0.79, +0.87]	1	Logs
➖	file_to_blackhole_0ms_latency_http2	egress throughput	+0.02	[-0.84, +0.88]	1	Logs
➖	file_to_blackhole_100ms_latency	egress throughput	+0.01	[-0.69, +0.72]	1	Logs
➖	tcp_dd_logs_filter_exclude	ingress throughput	+0.00	[-0.01, +0.02]	1	Logs
➖	uds_dogstatsd_to_api	ingress throughput	-0.00	[-0.29, +0.28]	1	Logs
➖	file_tree	memory utilization	-0.01	[-0.08, +0.06]	1	Logs
➖	file_to_blackhole_300ms_latency	egress throughput	-0.01	[-0.65, +0.62]	1	Logs
➖	file_to_blackhole_0ms_latency	egress throughput	-0.03	[-0.93, +0.87]	1	Logs
➖	quality_gate_logs	% cpu utilization	-0.12	[-3.14, +2.91]	1	Logs
➖	quality_gate_idle_all_features	memory utilization	-0.24	[-0.30, -0.17]	1	Logs bounds checks dashboard
➖	file_to_blackhole_1000ms_latency	egress throughput	-0.41	[-1.17, +0.35]	1	Logs
➖	quality_gate_idle	memory utilization	-0.56	[-0.60, -0.53]	1	Logs bounds checks dashboard
➖	tcp_syslog_to_blackhole	ingress throughput	-0.92	[-0.98, -0.86]	1	Logs

Bounds Checks: ✅ Passed

perf	experiment	bounds_check_name	replicates_passed	links
✅	file_to_blackhole_0ms_latency	lost_bytes	10/10
✅	file_to_blackhole_0ms_latency	memory_usage	10/10
✅	file_to_blackhole_0ms_latency_http1	lost_bytes	10/10
✅	file_to_blackhole_0ms_latency_http1	memory_usage	10/10
✅	file_to_blackhole_0ms_latency_http2	lost_bytes	10/10
✅	file_to_blackhole_0ms_latency_http2	memory_usage	10/10
✅	file_to_blackhole_1000ms_latency	memory_usage	10/10
✅	file_to_blackhole_1000ms_latency_linear_load	memory_usage	10/10
✅	file_to_blackhole_100ms_latency	lost_bytes	10/10
✅	file_to_blackhole_100ms_latency	memory_usage	10/10
✅	file_to_blackhole_300ms_latency	lost_bytes	10/10
✅	file_to_blackhole_300ms_latency	memory_usage	10/10
✅	file_to_blackhole_500ms_latency	lost_bytes	10/10
✅	file_to_blackhole_500ms_latency	memory_usage	10/10
✅	quality_gate_idle	intake_connections	10/10	bounds checks dashboard
✅	quality_gate_idle	memory_usage	10/10	bounds checks dashboard
✅	quality_gate_idle_all_features	intake_connections	10/10	bounds checks dashboard
✅	quality_gate_idle_all_features	memory_usage	10/10	bounds checks dashboard
✅	quality_gate_logs	intake_connections	10/10
✅	quality_gate_logs	lost_bytes	10/10
✅	quality_gate_logs	memory_usage	10/10

Explanation

Confidence level: 90.00%
Effect size tolerance: |Δ mean %| ≥ 5.00%

Performance changes are noted in the perf column of each table:

✅ = significantly better comparison variant performance
❌ = significantly worse comparison variant performance
➖ = no significant change in performance

A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".

For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:

Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.
Its configuration does not mark it "erratic".

CI Pass/Fail Decision

✅ Passed. All Quality Gates passed.

quality_gate_idle_all_features, bounds check memory_usage: 10/10 replicas passed. Gate passed.
quality_gate_idle_all_features, bounds check intake_connections: 10/10 replicas passed. Gate passed.
quality_gate_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
quality_gate_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
quality_gate_logs, bounds check lost_bytes: 10/10 replicas passed. Gate passed.
quality_gate_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
quality_gate_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.

KevinFairise2 · 2025-02-12T14:55:48Z

test/fakeintake/server/serverstore/in_memory.go

@@ -19,7 +20,8 @@ import (
 type inMemoryStore struct {
 	mutex sync.RWMutex

-	rawPayloads map[string][]api.Payload
+	rawPayloads  map[string][]api.Payload
+	recentAPIKey string


If I understand correctly you are only interested by the latest api key. Do we really need to store the API in the payload then?
I think that to achieve our goal we need either the APIKey in all the payload and we retrieve the API key for the latest received payload. Or we store the latest api key in the store struct directly. But I do not think we need to store twice the same information

Yes, the current E2E test that I have a PR up for uses only the last api key. However we plan to support additional use cases that will require having more features. For example, some products have to support sending multiple payload types and each could have a different api key. Rotating them individually needs to be validated in the FakeIntake, so having support for retrieving all payloads and their associated keys is meant to support that use case.

Was about to propose parsing the payload to check the API key attached to the latest payload. But since they are stored in different list depending on the route it would not be convenient.
That's fine to me then!

Yes, that's exactly right. The recentAPIKey is mostly for convenience, but the alternative is much harder to do (as well as less performant).

KevinFairise2 · 2025-02-12T18:47:29Z

test/fakeintake/server/serverstore/in_memory.go

@@ -19,7 +20,8 @@ import (
 type inMemoryStore struct {
 	mutex sync.RWMutex

-	rawPayloads map[string][]api.Payload
+	rawPayloads  map[string][]api.Payload
+	recentAPIKey string


Was about to propose parsing the payload to check the API key attached to the latest payload. But since they are stored in different list depending on the route it would not be convenient.
That's fine to me then!

KevinFairise2 · 2025-02-12T18:48:24Z

test/fakeintake/server/serverstore/in_memory.go

@@ -37,12 +39,31 @@ func newInMemoryStore() *inMemoryStore {
 	}
 }

+func (s *inMemoryStore) SetRecentAPIKey(key string) {


NIT: Can we use SetLastAPIKey instead so we have the same naming everywhere

Sure thing, I'll make that change before merging.

dustmop · 2025-02-12T21:35:35Z

/merge

dd-devflow · 2025-02-12T21:35:40Z

View all feedbacks in Devflow UI.
2025-02-12 21:35:39 UTC ℹ️ Start processing command /merge

2025-02-12 21:35:44 UTC ℹ️ MergeQueue: waiting for PR to be ready

This merge request is not mergeable yet, because of pending checks/missing approvals. It will be added to the queue as soon as checks pass and/or get approvals.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.

2025-02-12 21:56:09 UTC ℹ️ MergeQueue: merge request added to the queue

The median merge time in main is 33m.

2025-02-12 22:25:18 UTC ℹ️ MergeQueue: This merge request was merged

dustmop added changelog/no-changelog qa/done QA done before merge and regressions are covered by tests team/agent-configuration labels Feb 10, 2025

dustmop requested review from a team as code owners February 10, 2025 21:38

github-actions bot added the medium review PR review might take time label Feb 10, 2025

dustmop changed the title ~~Store APIKey for each payload, define /debug/lastAPIKey~~ Store APIKey in FakeIntake per payload, add /debug/lastAPIKey Feb 11, 2025

dustmop and others added 5 commits February 11, 2025 10:10

Store APIKey for each payload, define /debug/lastAPIKey

11ab514

Client method for getting lastAPIKey

a7d4284

Fix test

1264792

Track recently seen APIKey, in addition to storing with payloads

d6ec45a

Avoid deadlock when appending to fakeIntake in-memory db

5e9c5c5

dustmop force-pushed the dustin.long/fake-intake-last-apikey branch from a32a70a to 5e9c5c5 Compare February 11, 2025 15:11

dustmop mentioned this pull request Feb 11, 2025

E2E test for FakeIntake retrieving apikey after it is refreshed #33955

Open

KevinFairise2 reviewed Feb 12, 2025

View reviewed changes

KevinFairise2 approved these changes Feb 12, 2025

View reviewed changes

Change recentAPIKey to lastAPIKey for consistency

876e191

dd-mergequeue bot merged commit 9b55210 into main Feb 12, 2025
212 checks passed

dd-mergequeue bot deleted the dustin.long/fake-intake-last-apikey branch February 12, 2025 22:25

github-actions bot added this to the 7.64.0 milestone Feb 12, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Store APIKey in FakeIntake per payload, add /debug/lastAPIKey #33899

Store APIKey in FakeIntake per payload, add /debug/lastAPIKey #33899

dustmop commented Feb 10, 2025

agent-platform-auto-pr bot commented Feb 10, 2025 •

edited

Loading

agent-platform-auto-pr bot commented Feb 10, 2025 •

edited

Loading

agent-platform-auto-pr bot commented Feb 10, 2025 •

edited

Loading

agent-platform-auto-pr bot commented Feb 10, 2025 •

edited

Loading

cit-pr-commenter bot commented Feb 11, 2025 •

edited

Loading

Fine details of change detection per experiment

Bounds Checks: ✅ Passed

Explanation

KevinFairise2 Feb 12, 2025 •

edited

Loading

dustmop Feb 12, 2025

KevinFairise2 Feb 12, 2025

dustmop Feb 12, 2025

KevinFairise2 Feb 12, 2025

KevinFairise2 Feb 12, 2025

dustmop Feb 12, 2025

dustmop commented Feb 12, 2025

dd-devflow bot commented Feb 12, 2025 •

edited

Loading

Store APIKey in FakeIntake per payload, add /debug/lastAPIKey #33899

Store APIKey in FakeIntake per payload, add /debug/lastAPIKey #33899

Conversation

dustmop commented Feb 10, 2025

What does this PR do?

Motivation

Describe how you validated your changes

Possible Drawbacks / Trade-offs

Additional Notes

agent-platform-auto-pr bot commented Feb 10, 2025 • edited Loading

Static quality checks ✅

Info

agent-platform-auto-pr bot commented Feb 10, 2025 • edited Loading

Uncompressed package size comparison

Decision

agent-platform-auto-pr bot commented Feb 10, 2025 • edited Loading

agent-platform-auto-pr bot commented Feb 10, 2025 • edited Loading

Test changes on VM

cit-pr-commenter bot commented Feb 11, 2025 • edited Loading

Regression Detector

Regression Detector Results

Optimization Goals: ✅ No significant changes detected

Fine details of change detection per experiment

Bounds Checks: ✅ Passed

Explanation

CI Pass/Fail Decision

KevinFairise2 Feb 12, 2025 • edited Loading

Choose a reason for hiding this comment

dustmop Feb 12, 2025

Choose a reason for hiding this comment

KevinFairise2 Feb 12, 2025

Choose a reason for hiding this comment

dustmop Feb 12, 2025

Choose a reason for hiding this comment

KevinFairise2 Feb 12, 2025

Choose a reason for hiding this comment

KevinFairise2 Feb 12, 2025

Choose a reason for hiding this comment

dustmop Feb 12, 2025

Choose a reason for hiding this comment

dustmop commented Feb 12, 2025

dd-devflow bot commented Feb 12, 2025 • edited Loading

agent-platform-auto-pr bot commented Feb 10, 2025 •

edited

Loading

agent-platform-auto-pr bot commented Feb 10, 2025 •

edited

Loading

agent-platform-auto-pr bot commented Feb 10, 2025 •

edited

Loading

agent-platform-auto-pr bot commented Feb 10, 2025 •

edited

Loading

cit-pr-commenter bot commented Feb 11, 2025 •

edited

Loading

KevinFairise2 Feb 12, 2025 •

edited

Loading

dd-devflow bot commented Feb 12, 2025 •

edited

Loading