Make fields in uses cases which are not in ECS italic #55
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some of the existing use cases contain fields which are not in ECS. Also we had several fields commented to make it clear they are not in ECS. In recent discussions it popped up that it could be useful for others to share their schema they use for specific use cases + the fields which are not in ECS. As we now show the fields different this is possible. I plan to do follow up PR's to also clean up the use cases. Some are outdated and should be updated to use ECS fields, others can be useful for inspiration on new fields. Reviewing use cases is now much easier as it is directly visible which fields come from ECS and which ones not. Additional changes * Remove links for non ecs fields. * Remove ticks from name to make it nicer and support italic * Add fields to uses cases which were commented out previously
This was referenced Jul 26, 2018
Closed
andrewkroh
reviewed
Jul 26, 2018
| - name: rtt | ||
| type: long | ||
| description: > | ||
| Request round trip time. |
There was a problem hiding this comment.
This needs to specify a time unit.
| | [service.id](https://github.com/elastic/ecs#service.id) | Unique identifier of the running service.<br/>This id should uniquely identify this service. This makes it possible to correlate logs and metrics for one specific service. For example in case of issues with one redis instance, it's possible to filter on the id to see metrics and logs for this single instance. | keyword | | `d37e5ebfe0ae6c4972dbe9f0174a1637bb8247f6` | | ||
| | [service.name](https://github.com/elastic/ecs#service.name) | Name of the service data is collected from.<br/>The name is normally the same as the module name. | keyword | | `elasticsearch` | | ||
| | [service.version](https://github.com/elastic/ecs#service.version) | Version of the service the data was collected from.<br/>This allows to look at a data set only for a specific version of a service. | keyword | | `3.2.4` | | ||
| | <a name="service.host"></a>*service.host* | *Host address that is used to connect to the service.<br/>This normally contains hostname + port.<br/>REVIEW: Should this be service.uri instead, sometimes it's more then just the host? It could also include a path or the protocol.* | keyword | | `elasticsearch:9200` | |
There was a problem hiding this comment.
Given that it's more than a hostname, service.uri SGTM.
| # description: > | ||
| # SHA3-512 hash (SHA-3 family). | ||
|
|
||
| - name: hash |
There was a problem hiding this comment.
There are at least 2 more hash types in Auditbeat now - blake2b and xxhash. Would be good to add them so that people use the same names.
andrewkroh
approved these changes
Jul 26, 2018
|
@andrewkroh Would you be ok to address the above comments in follow up PR's? The goal of this PR is mainly to get the "infrastructure" in place not to change existing definitions or add new ones. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some of the existing use cases contain fields which are not in ECS. Also we had several fields commented to make it clear they are not in ECS. In recent discussions it popped up that it could be useful for others to share their schema they use for specific use cases + the fields which are not in ECS. As we now show the fields different this is possible.
I plan to do follow up PR's to also clean up the use cases. Some are outdated and should be updated to use ECS fields, others can be useful for inspiration on new fields. Reviewing use cases is now much easier as it is directly visible which fields come from ECS and which ones not.
Additional changes