[Automatic import] readme input types templates

[haetamoudi]

Summary

Enhance Readme with documentation specific to Input types.

For now the templates under x-pack/plugins/integration_assistant/server/templates/readme/setup/* are not used anywhere. The goal of the PR is to complete those templates, we will integrate them into the readme in a follow up PR

[elasticmachine]

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

• Click to trigger kibana-pull-request for this PR!

[ebeahan]

A handful of nits as I read through initially.

[ebeahan]

Hey all - we're trying to standardize some documentation templates for certain inputs supported by Automatic Import. We would appreciate a quick review from a CODEOWNER for each input listed, if possible. 🙏

@elastic/security-service-integrations:

• Azure Blob Storage
• GCP Pub/Sub
• GCS
• HTTP Endpoint
• CEL

@elastic/obs-cloud-monitoring:

• AWS Cloudwatch
• Amazon S3
• Azure Event Hub

[zmoog]

What are the sources for these docs?

The event hub docs seem to come from https://github.com/elastic/integrations/blob/main/packages/azure/_dev/build/docs/README.md. I'm not familiar with these CloudWatch and S3 docs.

Do these docs focus on the (Filebeat) input or the (Elastic Agent) integration?

Is this a one-time import, or is it a sync that will happen regularly?

[haetamoudi]

What are the sources for these docs?

The event hub docs seem to come from https://github.com/elastic/integrations/blob/main/packages/azure/_dev/build/docs/README.md. I'm not familiar with these CloudWatch and S3 docs.

The documentation comes from the multiple Readme files from the different integrations in the integrations repo.
The integration repo contains many readme with similar content but written in a slightly different way. The idea is to have templates that can be reuse to generate a unified documentation.

Do these docs focus on the (Filebeat) input or the (Elastic Agent) integration?

Is this a one-time import, or is it a sync that will happen regularly?

The templates will be used by automatic import when generating new integrations by users

@zmoog

[zmoog]

Is this a one-time import, or is it a sync that will happen regularly?

The templates will be used by automatic import when generating new integrations by users

Do these docs focus on the (Filebeat) input or the (Elastic Agent) integration?

[haetamoudi]

Do these docs focus on the (Filebeat) input or the (Elastic Agent) integration?

the Elastic Agent integration

[haetamoudi]

We are still missing some content (some might also be too specific to each integration for us to be able to add generic guidelines):

• cloud foundry
• filestream
• journald
• kafka
• tcp
• udp
• ssl probably can be enhanced too

@zmoog @efd6 do you know anyone that could help writing those?

[ebeahan]

We are still missing some content (some might also be too specific to each integration for us to be able to add generic guidelines).

Discussed a bit with @haetamoudi offline. Looking at the list, my guidance is as follows:

• cloud foundry - input exists in Beats and Elastic Agent supports the input. However, no integration currently uses, so I think it's fair to skip adding a template into Automatic Import for now.

• filestream - documented in Beats. There is a Custom Logs docs page, but it's still using the deprecated log input. If we re-use any guidance from the Custom Logs page, we should verify the guidance applies to filestream.

• tcp, udp, kafka, journald - Each of these types has a custom input page in the integration docs(kakfa, tcp, udp, journald).

ssl probably can be enhanced too

The Fleet UX points to the SSL docs, so I think it's an ok approach here to do the same: