-
Notifications
You must be signed in to change notification settings - Fork 195
Add documentation for creating APM agent keys for EDOT SDKs #4554
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
base: main
Are you sure you want to change the base?
Conversation
Vale Linting ResultsSummary: 3 suggestions found 💡 Suggestions (3)
The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
To the future reviewer: I don't think these are good suggestions in the context of this change. LMK if you disagree! |
…ent API keys; remove redundant information
theletterf
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work! Some suggestions.
| - **Ingest** (`event:write`): Required to ingest agent events. | ||
| - **Agent configuration** (`config_agent:read`): Required to use agent central configuration for remote configuration. | ||
| 7. Select **Create {{apm-agent}} key**. | ||
| 8. Copy the API key now. You won't be able to view it again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One way of rewriting this in present tense:
"The key is shown only once."
| - **Ingest** (`event:write`): Required to ingest agent events. | ||
| - **Agent configuration** (`config_agent:read`): Required to use agent central configuration for remote configuration. | ||
| 6. Select **Create {{apm-agent}} key**. | ||
| 7. Copy the API key now. You won't be able to view it again. API keys do not expire. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. I would also move the "do not expire" observation to a note outside of this step to avoid mixing concepts.
|
|
||
| ::::::{tab-item} {{serverless-full}} | ||
|
|
||
| For {{observability}} {{serverless-short}} projects, the Editor role or higher is required to create and manage API keys. Refer to [Assign user roles and privileges](/deploy-manage/users-roles/cloud-organization/user-roles.md#general-assign-user-roles) for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, "or higher" makes sense :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to blur or obscure details here? The user number for example?
mdbirnstiehl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good! I left a few comments, let me know what you think.
| - **Ingest** (`event:write`): Required to ingest agent events. | ||
| - **Agent configuration** (`config_agent:read`): Required to use agent central configuration for remote configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see these two options in the opposite order (config_agent:read first then event:write). Unless we are reordering here for some other reason, it might be good to align with the UI.
|
|
||
| To create an {{apm-agent}} key: | ||
|
|
||
| 1. In your {{obs-serverless}} project, go to any **Applications** page. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This step is the same in serverless and stack, but we're using different language. Do we want to use the same language in these?
| To create an {{apm-agent}} key: | ||
|
|
||
| 1. In your {{obs-serverless}} project, go to any **Applications** page. | ||
| 2. Select **Settings** > **Agent keys**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 2. Select **Settings** > **Agent keys**. | |
| 2. Go to **Settings** > **Agent keys**. |
Aligning the language between serverless/stack.
|
|
||
| :::::: | ||
|
|
||
| ::::::{tab-item} {{serverless-full}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems the only difference between the serverless and stack is whether you're in a serverless project or stack deployment. Do we need tabs here? (I say this as the person that probably set up these tabs during migration 😄)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ good callout. We can really simplify by removing the tabs
| - **Ingest** (`event:write`): Required to ingest agent events. | ||
| - **Agent configuration** (`config_agent:read`): Required to use agent central configuration for remote configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same comment as above.
|
|
||
| ::::::{tab-item} {{fleet}}-managed or {{apm-server}} binary | ||
|
|
||
| You must have the `manage_own_api_key` cluster privilege and the {{product.apm}} application privileges they intend to assign. Additionally, appropriate {{kib}} Space and Feature privileges are needed to access the Applications UI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the "they" is too ambiguous here. Something like this might be better:
| You must have the `manage_own_api_key` cluster privilege and the {{product.apm}} application privileges they intend to assign. Additionally, appropriate {{kib}} Space and Feature privileges are needed to access the Applications UI. | |
| You must have the `manage_own_api_key` cluster privilege and the {{product.apm}} application privileges you plan to assign to the key. Additionally, appropriate {{kib}} Space and Feature privileges are needed to access the Applications UI. |
Summary
This PR adds a dedicated page for creating APM agent keys for EDOT SDKs, with a reusable snippet to reduce content duplication. This change addresses the need for EDOT-specific API key documentation.
Closes #4296
Generative AI disclosure
To help us ensure compliance with the Elastic open source and documentation guidelines, please answer the following:
Tool(s) and model(s) used: Claude 4.5 Sonnet to help draft some sections, make the snippet work as it should, fix build errors, etc.