[REQUEST]: Managed Input pages should not be under the Opentelemetry section #7757

Activity

1. nimarezainia commented on Aug 3, 2026

   

   nimarezainia

   on Aug 3, 2026

   ContributorAuthor

   More actions

   cc: @vishaangelova
2. vishaangelova commented on Aug 3, 2026

   

   vishaangelova

   on Aug 3, 2026

   Last edited by vishaangelova

   Member

   More actions

   Thanks @nimarezainia! Yes, while working on the _bulk endpoint, I also thought it didn’t make sense to have these docs live in the opentelemetry repo (where mOTEL was documented initially). I wanted to restructure the current docs to move out the managed inputs shared parts of the doc to a separate doc + get the _bulk endpoint documented (waiting for @constanca-m’s final review in elastic/opentelemetry#644) before moving them out of the repo as a follow-up.

   👍React with 👍1Reacted by Marcin Stożek
3. bmorelli25 commented on Aug 4, 2026

   

   bmorelli25

   on Aug 4, 2026

   Last edited by bmorelli25

   Member

   More actions

   So is the play to move these out of the opentelemetry repo? Or is it to move the folder up one level in the opentelemetry repo so it's a standalone section and then point the global nav at /reference/managed-inputs? Either option would give us a more prominent placement and either option will need redirects.

   @vishaangelova let's chat more about this when you return. Whatever we do should play into our larger TOC/IA/Nav plans for the ingest space.

   👍React with 👍1Reacted by Visha Angelova
4. bmorelli25

   transferred this issue fromelastic/ingest-docson Aug 4, 2026
5. github-actions

   added

   needs-teamIssues pending triage by the Docs TeamIssues pending triage by the Docs Team

   on Aug 4, 2026
6. github-actions commented on Aug 4, 2026

   

   github-actionsBot

   on Aug 4, 2026 – with GitHub Actions

   Contributor

   More actions

   Elastic Docs AI Menu

   Check one box to run an AI workflow for this issue.

   • Triage (docs-triage). Status: not started.
   • Size the work (docs-size). Status: not started.
   • Scope the docs work (docs-issue-scope). Status: not started.

   Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.
7. bmorelli25

   added

   Team:SKIIssues owned by the SKI Docs TeamIssues owned by the SKI Docs Team

   and removed

   needs-teamIssues pending triage by the Docs TeamIssues pending triage by the Docs Team

   on Aug 4, 2026
8. vishaangelova commented on Sep 2, 2026

   

   vishaangelova

   on Sep 2, 2026

   Last edited by vishaangelova

   Member

   More actions

   Update: We want to tackle this issue as part of a the larger ingest docs IA update. Moving the docs out of the opentelemetry repo requires some effort that also involves adding redirects for these pages. Since we're already looking into making changes in the Ingest docs structure which could affect these pages, we want to only move and rename the docs once in order to have minimal negative impact on SEO and redirects.

   👍React with 👍1Reacted by Brandon Morelli
9. vishaangelova

   self-assigned this

   on Sep 18, 2026
10. vishaangelova commented on Nov 4, 2026

    

    vishaangelova

    on Nov 4, 2026

    Last edited by vishaangelova

    Member

    More actions

    @perk @nimarezainia @younginseattle (cc: @bmorelli25, @alexandra5000)

    As per my discussions with @nimarezainia and @perk, we will move the Managed inputs docs out of the opentelemetry repo and into the docs-content repo. Managed inputs will keep its current placement in the Docs navigation: Reference > Ingestion tools > Managed inputs. Managed integrations will move there from Manage data > Ingest, as a sibling of Managed inputs.

    I propose that the docs themselves live under docs-content/reference/managed-services or should this be streams-services instead, what do you think?

    If we use managed-services, we avoid having words like "inputs", "endpoints", and "sources" in the parent directory (and consequently in the URL of each doc), and we can move the docs for both the managed inputs (a streams push service) and the managed integrations (a streams pull service) into this directory.

    Effectively, the two would appear in the Docs navigation like this:

    Target: navigation (what readers see)

    Reference
    └── Ingestion tools
        ├── ...
        ├── Managed inputs                          docs-content://reference/managed-services/managed-inputs.md <1>
        │   ├── Authentication, delivery, and failure handling
        │   ├── Rate limiting
        │   ├── Managed OTLP Endpoint
        │   │   └── Troubleshooting
        │   ├── Managed Prometheus Remote Write endpoint
        │   └── Managed Elasticsearch _bulk endpoint
        ├── Managed integrations                    docs-content://reference/managed-services/managed-integrations.md
        │   ├── Enable an Elastic Managed integration
        │   ├── Federated identity authentication
        │   └── FAQ
        └── ...
    

    <1> managed-services is only a directory, it doesn't have its own entry in the navigation. The current managed-inputs/index.md is renamed to managed-inputs.md.

    Let me know what you think.

    👍React with 👍1Reacted by Brandon Morelli

    🚀React with 🚀1Reacted by Brandon Morelli
11. vishaangelova commented on Nov 8, 2026

    

    vishaangelova

    on Nov 8, 2026

    Last edited by vishaangelova

    Member

    More actions

    Update on the directory name

    I've decided that one directory per tool instead of a shared parent directory is the better way to handle this:

    • docs-content/reference/managed-inputs/ → URL: docs/reference/managed-inputs/...
    • docs-content/reference/managed-integrations/ → URL: docs/reference/managed-integrations/...

    The navigation stays as proposed above. Maybe with one exception: I intend to keep "Elastic Managed integrations" as the nav title for the Managed integrations doc. Unless we want to simplify this?

    My reasoning:

    • A shared parent such as managed-services would add a term to the URL which doesn't exist in the navigation or the UI.
    • Managed inputs and Managed integrations are different "tools", built by different teams, with different availability.
    • One directory per tool is the existing convention under reference/ (for example, reference/fleet/, reference/apm/), and the grouping is done in the navigation. This way the URLs contain only product names (which are the most stable part) and survive any future regrouping of the navigation.

    Unless there's a strong reason to prefer a shared parent directory, I'll proceed with this layout.

    (cc: @bmorelli25 since you reacted on my previous comment)