Skip to content

Conversation

@alexandra5000
Copy link
Contributor

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:

  1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?
  • Yes
  • No
  1. If you answered "Yes" to the previous question, please specify the tool(s) and model(s) used (e.g., Google Gemini, OpenAI ChatGPT-4, etc.).

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.

@github-actions
Copy link
Contributor

github-actions bot commented Jan 8, 2026

Vale Linting Results

Summary: 3 suggestions found

💡 Suggestions (3)
File Line Rule Message
solutions/observability/apm/_snippets/create-apm-agent-key-applications-ui.md 16 Elastic.FutureTense 'won't be' might be in future tense. Write in the present tense to describe the state of the product as it is now.
solutions/observability/apm/_snippets/create-apm-agent-key-applications-ui.md 37 Elastic.FutureTense 'won't be' might be in future tense. Write in the present tense to describe the state of the product as it is now.
solutions/observability/apm/opentelemetry/create-apm-agent-key-for-edot-sdks.md 65 Elastic.Versions Use 'or later' instead of 'or higher' when referring to versions.

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.

@github-actions
Copy link
Contributor

github-actions bot commented Jan 8, 2026

@alexandra5000
Copy link
Contributor Author

Vale Linting Results

Summary: 3 suggestions found

💡 Suggestions (3)

To the future reviewer: I don't think these are good suggestions in the context of this change. LMK if you disagree!

Copy link
Contributor

@theletterf theletterf left a 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.
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

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 :)

Copy link
Contributor

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?

Copy link
Contributor

@mdbirnstiehl mdbirnstiehl left a 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.

Comment on lines +13 to +14
- **Ingest** (`event:write`): Required to ingest agent events.
- **Agent configuration** (`config_agent:read`): Required to use agent central configuration for remote configuration.
Copy link
Contributor

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.
Copy link
Contributor

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**.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
2. Select **Settings** > **Agent keys**.
2. Go to **Settings** > **Agent keys**.

Aligning the language between serverless/stack.


::::::

::::::{tab-item} {{serverless-full}}
Copy link
Contributor

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 😄)

Copy link
Member

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

Comment on lines +34 to +35
- **Ingest** (`event:write`): Required to ingest agent events.
- **Agent configuration** (`config_agent:read`): Required to use agent central configuration for remote configuration.
Copy link
Contributor

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.
Copy link
Member

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:

Suggested change
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.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[EDOT SDK] Creation of APM agent keys

4 participants