Akamai: add recovery_interval parameter and handle 400 invalid timestamp

[chemamartinez]

Proposed commit message

akamai: add configurable recovery interval for historical data re-fetch

The integration now supports a recovery_interval parameter (default: 12h)
that controls the lookback period when re-fetching historical data after
encountering API errors (416, 400 with "Invalid timestamp").

Additionally, enhanced error detection to properly identify and handle
400 Bad Request responses containing "Invalid timestamp" errors by
triggering recovery mode.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[ShourieG]

Suggested change

	: (resp.StatusCode == 416 || (resp.StatusCode == 400 && size(resp.Body) != 0 && bytes(resp.Body).decode_json().as(errorBody, has(errorBody.detail) && errorBody.detail.contains("Invalid timestamp")))) ?
	: (resp.StatusCode == 416 || (resp.StatusCode == 400 && size(resp.Body) != 0 && bytes(resp.Body).decode_json().as(errorBody, has(errorBody.detail) && errorBody.detail.to_lower().contains("invalid timestamp")))) ?

I think we should use to_lower() just to be safe.

[ShourieG]

We just need to check if to_lower() can be chained with contains() correctly once.

[chemamartinez]

I've verified that they can be chained.

[ShourieG]

I also updated the commit message a bit

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: dc60985

History

• 💚 Build #35548 succeeded 85bf94a
• 💚 Build #35528 succeeded a4469c5

cc @chemamartinez

[ShourieG]

@chemamartinez ,Just noticed this, I saw it was tagged as a bugfix, and the custom package shared was 3.0.3. Should we keep this the same or do we want to label it as an enhancement ? I feel an enhancement is appropriate as we are introducing a new config variable. If so we can add the enhancement label.

[ShourieG]

I've added the enhancement label

[chemamartinez]

Yes, it includes two changes and for me one is an enhancement and the other one a bugfix, so I changed the minor version and marked it as both in the changelog but forgot to add the label. Thank you!

[ShourieG]

LGTM

[elastic-vault-github-plugin-prod]

Package akamai - 3.1.0 containing this change is available at https://epr.elastic.co/package/akamai/3.1.0/