Skip to content

TBS: Expose TTL config via integration policy #13525

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Tracked by #14931
carsonip opened this issue Jul 1, 2024 · 3 comments
Open
Tracked by #14931

TBS: Expose TTL config via integration policy #13525

carsonip opened this issue Jul 1, 2024 · 3 comments

Comments

@carsonip
Copy link
Member

carsonip commented Jul 1, 2024

Tail based sampling TTL sampling.tail.ttl config is only configurable via apm-server.yml, and is not available to fleet-managed apm-server. TTL is a useful knob to adjust TBS storage usage if storage limit is reached and sampling.tail.storage_limit cannot be further increased for any reason.

Add TTL config to integration policy, APM UI, and docs.

Files requiring changes (and possibly more):

@carsonip carsonip changed the title Expose TBS TTL config via integration policy TBS: Expose TTL config via integration policy Feb 21, 2025
@raultorrecilla
Copy link

Input from @carsonip for this task:
The task will be about:

  1. changing integration package (we can do it very quickly)
  2. changing APM integration UI (we may do it, but I think it's better for #obs-ux-infra_services to do it)
  3. Updating some translations files for the UI (need to ask #obs-ux-infra_services who's responsible for that).

Moving it to it-109 before 9.1 FF.

@carsonip
Copy link
Member Author

changing integration package (we can do it very quickly)
changing APM integration UI (we may do it, but I think it's better for #obs-ux-infra_services to do it)
Updating some translations files for the UI (need to ask #obs-ux-infra_services who's responsible for that).

I've discussed with UI team internally and apparently the UI will fetch the policy, display configs that it supports, then merge it back to the fetched policy to save it. i.e. If there's a policy config that isn't supported in the UI, there's no side effect on loading and saving them in the UI.

Therefore, we can decouple the integration package work and it is not necessary to release it with the UI at the same time. UI support is preferred but it will not be a blocker.

I'll still target 9.1 for the change in integration package.

Q:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants