Skip to content

Add docs about package types #2691

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

Merged
merged 4 commits into from
Jun 27, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/howto/create_new_package.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,8 @@ This will ensure that you're following latest recommendations for the package fo

_Pick the directory where you'd like to create a new package. For integrations, it's: [packages/](https://github.com/elastic/integrations/tree/master/packages)._

_Decide what [package type](./package_types.md) you would like to create._

### Steps

1. Bootstrap new package using the TUI wizard: `elastic-package create package`.
Expand Down
55 changes: 55 additions & 0 deletions docs/howto/package_types.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
## Package types

There are different types of packages, for different use cases.

Integration packages provide complete monitoring solutions for specific
applications of services. An integration package can be used to configure
multiple data streams and multiple agent inputs, it also includes dashboards
and other assets related to the monitored service.
For example the Apache package includes configurations to collect and store
access and error logs and metrics. It also includes dashboards to leverage the
collected data.

Input packages are intended for generic use cases, where the user needs to
collect custom data. They define how to configure an agent input, so the user
can adapt it to their case. An example is the log input package, that users can
use to collect custom logs, and provide their own processing and mapping.

Content packages include assets for the Elastic Stack, but are not intended to
define how to ingest data. They can include static data for indexes, as
knowledge bases or sample data. Or they can contain resources that can be used
with data collected according to certain conventions, for example dashboards for
data collected by other means.

### What package type to use?

When [creating a new package](./create_new_package.md) you will need to select
the type. If you are not sure, you can follow this section to help deciding:

* Do you plan to provide a whole solution for a given service?
* If yes, can Fleet manage the collector agent?
* If yes, create an integration package.
* If not, create a content package that complements the method/s used for ingestion.
* If not, do you plan to define how to collect data?
* If yes, do you plan to define how to collect data in a generic way for a given protocol?
* If yes, create an input package.
* If not, create an integration package for the use case.
* If not, create a content package.

### A note on using integration packages for everything

For legacy reasons, integration packages can be used for most use cases. For
example a package can include dashboards without including any data stream, as
if it were a content package. Or an integration package can define a single data
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
if it were a content package. Or an integration package can define a single data
if it was a content package. Or an integration package can define a single data

Copy link
Member Author

Choose a reason for hiding this comment

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

I think were is correct here 🤔

Copy link
Contributor

Choose a reason for hiding this comment

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

mmm now I have doubts 😅
Probably, you're right and it should be as if it were... as an hypothetical situation.

Copy link
Member

Choose a reason for hiding this comment

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

Native English speaker here 👋 - both sound fine imo. Terrible language 😜

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks! 😄

stream, as if it were an input package.

Even when this is true, these cases push integration packages (and the code
supporting them) beyond what they were designed for. By having different types
we can focus on better supporting this specialized use cases. For example content
packages can be allowed to have bigger sizes, and we can prepare all our infra
and code for them. Or input packages are better designed for custom use cases,
giving a better experience on these cases.

In the future we may be limiting what can be done with integration packages,
providing migration paths to the other types.