|
| 1 | +## Package types |
| 2 | + |
| 3 | +There are different types of packages, for different use cases. |
| 4 | + |
| 5 | +Integration packages provide complete monitoring solutions for specific |
| 6 | +applications of services. An integration package can be used to configure |
| 7 | +multiple data streams and multiple agent inputs, it also includes dashboards |
| 8 | +and other assets related to the monitored service. |
| 9 | +For example the Apache package includes configurations to collect and store |
| 10 | +access and error logs and metrics. It also includes dashboards to leverage the |
| 11 | +collected data. |
| 12 | + |
| 13 | +Input packages are intended for generic use cases, where the user needs to |
| 14 | +collect custom data. They define how to configure an agent input, so the user |
| 15 | +can adapt it to their case. An example is the log input package, that users can |
| 16 | +use to collect custom logs, and provide their own processing and mapping. |
| 17 | + |
| 18 | +Content packages include assets for the Elastic Stack, but are not intended to |
| 19 | +define how to ingest data. They can include static data for indexes, as |
| 20 | +knowledge bases or sample data. Or they can contain resources that can be used |
| 21 | +with data collected according to certain conventions, for example dashboards for |
| 22 | +data collected by other means. |
| 23 | + |
| 24 | +### What package type to use? |
| 25 | + |
| 26 | +When [creating a new package](./create_new_package.md) you will need to select |
| 27 | +the type. If you are not sure, you can follow this section to help deciding: |
| 28 | + |
| 29 | +* Do you plan to provide a whole solution for a given service? |
| 30 | + * If yes, can Fleet manage the collector agent? |
| 31 | + * If yes, create an integration package. |
| 32 | + * If not, create a content package that complements the method/s used for ingestion. |
| 33 | + * If not, do you plan to define how to collect data? |
| 34 | + * If yes, do you plan to define how to collect data in a generic way for a given protocol? |
| 35 | + * If yes, create an input package. |
| 36 | + * If not, create an integration package for the use case. |
| 37 | + * If not, create a content package. |
| 38 | + |
| 39 | +### A note on using integration packages for everything |
| 40 | + |
| 41 | +For legacy reasons, integration packages can be used for most use cases. For |
| 42 | +example a package can include dashboards without including any data stream, as |
| 43 | +if it were a content package. Or an integration package can define a single data |
| 44 | +stream, as if it were an input package. |
| 45 | + |
| 46 | +Even when this is true, these cases push integration packages (and the code |
| 47 | +supporting them) beyond what they were designed for. By having different types |
| 48 | +we can focus on better supporting this specialized use cases. For example content |
| 49 | +packages can be allowed to have bigger sizes, and we can prepare all our infra |
| 50 | +and code for them. Or input packages are better designed for custom use cases, |
| 51 | +giving a better experience on these cases. |
| 52 | + |
| 53 | +In the future we may be limiting what can be done with integration packages, |
| 54 | +providing migration paths to the other types. |
| 55 | + |
0 commit comments