You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: packages/oracle_weblogic/docs/README.md
+36-36Lines changed: 36 additions & 36 deletions
Original file line number
Diff line number
Diff line change
@@ -702,42 +702,42 @@ An example event for `deployed_application` looks as following:
702
702
703
703
**Exported fields**
704
704
705
-
| Field | Description | Type |
706
-
|---|---|---|
707
-
|@timestamp| Event timestamp. | date |
708
-
| agent.id | Unique identifier of this agent (if one exists). Example: For Beats this would be beat.id. | keyword |
709
-
| cloud.account.id | The cloud account or organization id used to identify different entities in a multi-tenant environment. Examples: AWS account id, Google Cloud ORG Id, or other unique identifier. | keyword |
710
-
| cloud.availability_zone | Availability zone in which this host, resource, or service is located. | keyword |
711
-
| cloud.instance.id | Instance ID of the host machine. | keyword |
712
-
| cloud.provider | Name of the cloud provider. Example values are aws, azure, gcp, or digitalocean. | keyword |
713
-
| cloud.region | Region in which this host, resource, or service is located. | keyword |
714
-
| container.id | Unique container id. | keyword |
715
-
| data_stream.dataset | Data stream dataset. | constant_keyword |
716
-
| data_stream.namespace | Data stream namespace. | constant_keyword |
717
-
| data_stream.type | Data stream type. | constant_keyword |
718
-
| ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword |
| event.category | This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. `event.category` represents the "big buckets" of ECS categories. For example, filtering on `event.category:process` yields all events relating to process activity. This field is closely related to `event.type`, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. | keyword |
721
-
| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date |
722
-
| event.dataset | Name of the dataset. If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from. It's recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name. | keyword |
723
-
| 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 |
724
-
| 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 |
725
-
| event.outcome | This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. `event.outcome` simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of `event.outcome`, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with `event.type:info`, or any events for which an outcome does not make logical sense. | keyword |
726
-
| 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 |
727
-
| host.ip | Host ip addresses. | ip |
728
-
| 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 |
729
-
| oracle_weblogic.deployed_application.deployment.state.name | Current state of the deployment as an keyword. | keyword |
730
-
| oracle_weblogic.deployed_application.deployment.state.value | Current state of the deployment as an integer. | long |
731
-
| oracle_weblogic.deployed_application.session_timeout | Session timeout in integer. | long |
732
-
| oracle_weblogic.deployed_application.sessions.open.current | Current number of open sessions in this module. | long |
733
-
| oracle_weblogic.deployed_application.sessions.open.high | Highest number of open sessions on this server at any one time. | long |
734
-
| oracle_weblogic.deployed_application.sessions.open.total | Total number of sessions that were opened. | long |
735
-
| oracle_weblogic.deployed_application.single_threaded_servlet_pool_size | Displays the size of this servlet for single thread model servlets. | long |
736
-
| oracle_weblogic.deployed_application.source_info | Source info of the deployment as a keyword. | keyword |
737
-
| oracle_weblogic.deployed_application.status | Status of the deployment. | keyword |
738
-
| 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 |
739
-
| 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 |
740
-
| tags | List of keywords used to tag each event. | keyword |
705
+
| Field | Description | Type | Metric Type |
706
+
|---|---|---|---|
707
+
|@timestamp| Event timestamp. | date ||
708
+
| agent.id | Unique identifier of this agent (if one exists). Example: For Beats this would be beat.id. | keyword ||
709
+
| cloud.account.id | The cloud account or organization id used to identify different entities in a multi-tenant environment. Examples: AWS account id, Google Cloud ORG Id, or other unique identifier. | keyword ||
710
+
| cloud.availability_zone | Availability zone in which this host, resource, or service is located. | keyword ||
711
+
| cloud.instance.id | Instance ID of the host machine. | keyword ||
712
+
| cloud.provider | Name of the cloud provider. Example values are aws, azure, gcp, or digitalocean. | keyword ||
713
+
| cloud.region | Region in which this host, resource, or service is located. | keyword ||
| data_stream.dataset | Data stream dataset. | constant_keyword ||
716
+
| data_stream.namespace | Data stream namespace. | constant_keyword ||
717
+
| data_stream.type | Data stream type. | constant_keyword ||
718
+
| ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword ||
| event.category | This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. `event.category` represents the "big buckets" of ECS categories. For example, filtering on `event.category:process` yields all events relating to process activity. This field is closely related to `event.type`, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. | keyword ||
721
+
| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date ||
722
+
| event.dataset | Name of the dataset. If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from. It's recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name. | keyword ||
723
+
| 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 ||
724
+
| 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 ||
725
+
| event.outcome | This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. `event.outcome` simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of `event.outcome`, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with `event.type:info`, or any events for which an outcome does not make logical sense. | keyword ||
726
+
| 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 ||
727
+
| host.ip | Host ip addresses. | ip ||
728
+
| 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 ||
729
+
| oracle_weblogic.deployed_application.deployment.state.name | Current state of the deployment as an keyword. | keyword ||
730
+
| oracle_weblogic.deployed_application.deployment.state.value | Current state of the deployment as an integer. | long | gauge |
731
+
| oracle_weblogic.deployed_application.session_timeout | Session timeout in integer. | long | gauge |
732
+
| oracle_weblogic.deployed_application.sessions.open.current | Current number of open sessions in this module. | long | gauge |
733
+
| oracle_weblogic.deployed_application.sessions.open.high | Highest number of open sessions on this server at any one time. | long | counter |
734
+
| oracle_weblogic.deployed_application.sessions.open.total | Total number of sessions that were opened. | long | counter |
735
+
| oracle_weblogic.deployed_application.single_threaded_servlet_pool_size | Displays the size of this servlet for single thread model servlets. | long | gauge |
736
+
| oracle_weblogic.deployed_application.source_info | Source info of the deployment as a keyword. | keyword ||
737
+
| oracle_weblogic.deployed_application.status | Status of the deployment. | keyword ||
738
+
| 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 ||
739
+
| 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 ||
740
+
| tags | List of keywords used to tag each event. | keyword ||
0 commit comments