Skip to content
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

[O11y][ActiveMQ] Resolve host.ip field conflict #8927

Merged
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
4 changes: 4 additions & 0 deletions packages/activemq/_dev/build/docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,10 @@ System logs and Audit logs are also collected using this integration.

The ActiveMQ datasets were tested with ActiveMQ 5.17.1 or higher (independent from operating system).

## Troubleshooting

If `host.ip` appears conflicted under the `log-*` or `metrics-*` data view, this issue can be resolved by [reindexing](https://www.elastic.co/guide/en/elasticsearch/reference/current/use-a-data-stream.html#reindex-with-a-data-stream) the indices of the `Audit`, `Log`, `Broker`, `Queue` and `Topic` data streams.

## Logs

### ActiveMQ Logs
Expand Down
5 changes: 5 additions & 0 deletions packages/activemq/changelog.yml
Original file line number Diff line number Diff line change
@@ -1,4 +1,9 @@
# newer versions go on top
- version: 0.14.2
changes:
- description: Resolve host.ip field conflict.
type: bugfix
link: https://github.com/elastic/integrations/pull/8927
- version: 0.14.1
changes:
- description: Add null and ignore_missing check to handle event.original field.
Expand Down
2 changes: 2 additions & 0 deletions packages/activemq/data_stream/broker/fields/ecs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -47,3 +47,5 @@
- external: ecs
name: host.name
dimension: true
- external: ecs
name: host.ip
2 changes: 2 additions & 0 deletions packages/activemq/data_stream/log/fields/ecs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -18,3 +18,5 @@
name: message
- external: ecs
name: tags
- external: ecs
name: host.ip
2 changes: 2 additions & 0 deletions packages/activemq/data_stream/queue/fields/ecs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -47,3 +47,5 @@
- external: ecs
name: host.name
dimension: true
- external: ecs
name: host.ip
2 changes: 2 additions & 0 deletions packages/activemq/data_stream/topic/fields/ecs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -47,3 +47,5 @@
- external: ecs
name: host.name
dimension: true
- external: ecs
name: host.ip
8 changes: 8 additions & 0 deletions packages/activemq/docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,10 @@ System logs and Audit logs are also collected using this integration.

The ActiveMQ datasets were tested with ActiveMQ 5.17.1 or higher (independent from operating system).

## Troubleshooting

If `host.ip` appears conflicted under the `log-*` or `metrics-*` data view, this issue can be resolved by [reindexing](https://www.elastic.co/guide/en/elasticsearch/reference/current/use-a-data-stream.html#reindex-with-a-data-stream) the indices of the `Audit`, `Log`, `Broker`, `Queue` and `Topic` data streams.

## Logs

### ActiveMQ Logs
Expand Down Expand Up @@ -92,6 +96,7 @@ An example event for `log` looks as following:
| event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. `event.kind` gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not. | keyword |
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), `event.module` should contain the name of this module. | keyword |
| event.original | Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from `_source`. If users wish to override this and index this field, please see `Field data types` in the `Elasticsearch Reference`. | keyword |
| host.ip | Host ip addresses. | ip |
| input.type | Input type | keyword |
| log.file.path | Full path to the log file this event came from, including the file name. It should include the drive letter, when appropriate. If the event wasn't read from a log file, do not populate this field. | keyword |
| log.flags | Log flags | keyword |
Expand Down Expand Up @@ -374,6 +379,7 @@ An example event for `broker` looks as following:
| event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. `event.kind` gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not. | keyword | | |
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), `event.module` should contain the name of this module. | keyword | | |
| event.type | This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. `event.type` represents a categorization "sub-bucket" that, when used along with the `event.category` field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. | keyword | | |
| host.ip | Host ip addresses. | ip | | |
| host.name | Name of the host. It can contain what `hostname` returns on Unix systems, the fully qualified domain name, or a name specified by the user. The sender decides which value to use. | keyword | | |
| service.address | Address where data about this service was collected from. This should be a URI, network address (ipv4:port or [ipv6]:port) or a resource path (sockets). | keyword | | |
| service.type | The type of the service data is collected from. The type can be used to group and correlate logs and metrics from one service type. Example: If logs or metrics are collected from Elasticsearch, `service.type` would be `elasticsearch`. | keyword | | |
Expand Down Expand Up @@ -541,6 +547,7 @@ An example event for `queue` looks as following:
| event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. `event.kind` gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not. | keyword | | |
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), `event.module` should contain the name of this module. | keyword | | |
| event.type | This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. `event.type` represents a categorization "sub-bucket" that, when used along with the `event.category` field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. | keyword | | |
| host.ip | Host ip addresses. | ip | | |
| host.name | Name of the host. It can contain what `hostname` returns on Unix systems, the fully qualified domain name, or a name specified by the user. The sender decides which value to use. | keyword | | |
| service.address | Address where data about this service was collected from. This should be a URI, network address (ipv4:port or [ipv6]:port) or a resource path (sockets). | keyword | | |
| service.type | The type of the service data is collected from. The type can be used to group and correlate logs and metrics from one service type. Example: If logs or metrics are collected from Elasticsearch, `service.type` would be `elasticsearch`. | keyword | | |
Expand Down Expand Up @@ -706,6 +713,7 @@ An example event for `topic` looks as following:
| event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. `event.kind` gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not. | keyword | | |
| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), `event.module` should contain the name of this module. | keyword | | |
| event.type | This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. `event.type` represents a categorization "sub-bucket" that, when used along with the `event.category` field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. | keyword | | |
| host.ip | Host ip addresses. | ip | | |
| host.name | Name of the host. It can contain what `hostname` returns on Unix systems, the fully qualified domain name, or a name specified by the user. The sender decides which value to use. | keyword | | |
| service.address | Address where data about this service was collected from. This should be a URI, network address (ipv4:port or [ipv6]:port) or a resource path (sockets). | keyword | | |
| service.type | The type of the service data is collected from. The type can be used to group and correlate logs and metrics from one service type. Example: If logs or metrics are collected from Elasticsearch, `service.type` would be `elasticsearch`. | keyword | | |
Expand Down
2 changes: 1 addition & 1 deletion packages/activemq/manifest.yml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
name: activemq
title: ActiveMQ
version: "0.14.1"
version: "0.14.2"
description: Collect logs and metrics from ActiveMQ instances with Elastic Agent.
type: integration
icons:
Expand Down