-
Notifications
You must be signed in to change notification settings - Fork 419
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
Document the usage of the ECS generator #746
Comments
Until I have time to put together coherent docs, I guess we can still drop something I can point to here. Beats users should disregard this. Beats includes hundreds of other field definitions that aren't in ECS. Follow Beats docs to add custom fields to Beats. These tools are experimental and should be used for custom indices only. Prior to using these tools, the user should check out the git branch for the ECS version they are targeting. E.g. for ECS 1.5.0:
The ECS tooling is built for Python 3.6+. Help
Output Generate ECS artifacts in a different directory
ECS + Custom fields Generate ECS artifacts based on ECS + my custom fields.
Check out the schemas/README.md or the YAML files in this directory, for the file format of how to put together these YAML files. Pick a subset of ECS If your index will never populate some of the ECS fields, no need to have these field defs in your mapping. You can trim it down by creating a YAML file that indicates which field sets, or specific fields to include.
The structure of this YAML file should be as follow: base:
fields: "*"
event:
fields: "*"
host:
fields:
name:
fields: "*" The above will generate a template that contains the following, and nothing else:
Note that if you use Complete example To generate a template
A user could run:
Caveats:
|
#856 Lets the user override the Elasticsearch template settings as well |
Thank you, @webmat, this covers a lot of the questions I had. As a new user, my initial thought process was as follows (you've covered a lot of these). I've condensed these to save space - click here to expand
|
@rgmz thank you so much for taking the time to document your experience as a new user. This feedback and perspective is extremely valuable! I've tried to address each of your questions (focusing on the ones you didn't answer along the way), but if I've overlooked any questions or concerns, please let me know. The contributors documentation does include a bit more detail of initial setup for someone looking to contribute changes to ECS and covers running routine tasks via
great usability suggestion 👍
Yes agree again. @webmat usage notes here are great, but we need to add them to the repo's documentation vs. requiring someone to search the issue backlog 😄 . We also can add some better details in the
The intermediate files are the intermediary in-memory representation of the schema as a generated files. This allows generators/tools outside ECS' own tooling to load this fleshed out and simplified file(s). This option instructs
This currently argument accepts a single directory or multiple whitespaced separated directories:
Based on some quick testing and reviewing the implementation, passing a specific filename or wildcard attempting to match filename will not work today. I'm planning to review and better note the supported options for this arg. Passing a wildcard pattern for directories does work:
Yes another candidate for better documentation. 😄 Subset is intended for the user to provide a "subset" YAML file that will limit the file fields generated in the generated output. The best current resources are again @webmat comment above as well as here (sounds like you may have came across both already). I will call out some ongoing discussion in this PR which would be a breaking change to the existing subset YAML format in exchange for some additional functionality and flexibility.
Currently it looks like directories are not supported, but using a wildcard pattern does work:
There are some inconsistencies in file vs wildcard vs directory behavior from option to option surfacing for improvement from argument to argument.
These options update the default mapping and template settings Elasticsearch templates with the options passed in. These are JSON files. example {
"index_patterns": ["ecs-*"],
"order": 1,
"settings": {
"index": {
"mapping": {
"total_fields": {
"limit": 10000
}
},
"refresh_interval": "10s"
}
},
"mappings": {}
} example {
"_meta": {
"version": "1.5.0"
},
"date_detection": false,
"dynamic_templates": [
{
"strings_as_keyword": {
"mapping": {
"ignore_above": 1024,
"type": "keyword"
},
"match_mapping_type": "string"
}
}
],
"properties": {}
} Note that in We're actively working on improving the ECS "Getting Started" experience and documentation and are aware there are current gaps, so again these notes are really a tremendous help!! |
100% agree we need to add this to the repo, that's why I opened the issue ;-) And I want to second Eric and say thank you for sharing such detailed notes on your experience <3 You can disregard To explain more clearly Subset has a quirk though: let's say you You highlight a lot of other things we can improve, thank you! We'll use this in our next rounds of improvements to the getting started experience for implementers 👍 |
The |
Added usage documentation for the ECS generator in #884. |
The ECS generator is accruing features that let users generate their artifacts based on their additional custom fields.
We should document the usage of
--include
Add ability to include external directory of schemas when running generator #494--subset
Allow generation of a subset of ECS and custom schema fields #737--out
--intermediate-only
Since this is low level advanced stuff, I think we could document this in the github repo in
generated/README.md
, with a mention in the main readme as well.The text was updated successfully, but these errors were encountered: