-
Notifications
You must be signed in to change notification settings - Fork 429
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
Azure Resource Metrics - Apply doc template and add generic setup section #9065
Conversation
🚀 Benchmarks reportPackage
|
Data stream | Previous EPS | New EPS | Diff (%) | Result |
---|---|---|---|---|
container_service |
200000 | 142857.14 | -57142.86 (-28.57%) | 💔 |
To see the full report comment with /test benchmark fullreport
@zmoog Having the Exported fields table following each type of data streams makes this page not readable. I can test the collapse/expand feature in MD and see how it renders in MDX, but if it doesn't work I suggest we move the Exported fields table at the end of the page, just before the Changelog section. WDYT? |
|
||
`monitor` | ||
`monitor` |
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.
After reading the preview, I have the feeling that we should move this section with the metricset description and tables (generaged by {{fields "monitor"}}
) at the bottom of the doc in a "references" section.
The {{fields "monitor"}}
expands in a large table, and IMO it's easy to miss the content after the tables.
What about adding something in the lines of "see references section for all the gory details of these metricsets" right after the metricset list?
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.
Yes 👍 that's what I also suggested here. If the test with collapse/expand feature doesn't work, we'll put the tables at the end of the page and reference them where needed.
Co-authored-by: Maurizio Branca <maurizio.branca@elastic.co>
Co-authored-by: Maurizio Branca <maurizio.branca@elastic.co>
Co-authored-by: Maurizio Branca <maurizio.branca@elastic.co>
Co-authored-by: Maurizio Branca <maurizio.branca@elastic.co>
@zmoog The first block of text of Integration specific configuration notes and the entire section of Additional notes about metrics and costs can be combined into a single and more linear section called Authentication and costs. For example: If agreed, this change would be reflected on all these pages:
|
Yep, it makes senso combine these two sections into one. Two notes on the content:
|
If we want to continue using the ASCII art for diagrams, I can share the text for azure_resource_metrics_req.png. |
The name "service principal" is commonly used to represent the identity of an application for authentication purposes. Other cloud providers, for example GCP, use the term service principal for this concept. On Azure, they seem to use "app registration" on the Portal, and "service principal" on the CLI and API: On the Azure CLI, if I list the service principals: $ az ad sp list | jq -r '.[] | [.appDisplayName] | @tsv' | grep branca
mbranca-app-registration-or-service-principal
mbranca-elastic-agent I get the same result if I open the app registrations section on the Portal: |
So, the concept is the same, the only difference is that
We fix the occurrences in this PR and handle the remaining ones in a separate PR |
@alaudazzi, here is the ASCII version of the diagram:
|
It turns out that on Azure "app registration" and "service principal" are related but NOT the same. Quoting Create a Microsoft Entra application and service principal that can access resources from the Azure docs:
So, "app registration" and "service principal" are different entities. Azure creates the related service principal for you if you create an app registration. And it works both ways! So users have the option of creating:
|
I would use the app registration in our docs to resolve the "app registration" vs. "service principal" dilemma. The App registration is the most visible term in Azure Portal, the UI we primarily use in our docs. Then, if we link to Azure docs that explain how to create a service principal using the CLI (bash or PowerShell), in that case, we can mention that creating a service principal will also create a linked app registration that will be visible on the Portal. @alaudazzi, WDYT? |
makes sense
I added a note in the Authentication and costs section. The PR is ready for you to review. I guess we integrated all the comments raised so far. |
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.
LGTM!
nit: I think we can remove
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.
LGTM!
Nit: I think we can remove the .png file since we opted to use the ASCII version of the diagram.
💚 Build Succeeded
History
|
Quality Gate passedKudos, no new issues were introduced! 0 New issues |
Package azure_metrics - 1.4.2 containing this change is available at https://epr.elastic.co/search?package=azure_metrics |
…tion (#9065) * Apply doc template and add generic setup section * Update packages/azure_metrics/_dev/build/docs/README.md Co-authored-by: Maurizio Branca <maurizio.branca@elastic.co> * Update packages/azure_metrics/_dev/build/docs/README.md Co-authored-by: Maurizio Branca <maurizio.branca@elastic.co> * Update packages/azure_metrics/_dev/build/docs/README.md Co-authored-by: Maurizio Branca <maurizio.branca@elastic.co> * Update packages/azure_metrics/_dev/build/docs/README.md Co-authored-by: Maurizio Branca <maurizio.branca@elastic.co> * Move the data streams to a reference section * Fix data streams wording * Optimize config auth costs section * Replace MS AD with MS Entra * Replace Active Directory with MS Entra * Add diagram * Add note on service principal * Remove unused image --------- Co-authored-by: Maurizio Branca <maurizio.branca@elastic.co>
This PR:
Relates #123