Platform Observability

<div class="condensed-table">
| | |
| --- | --- |
| Version | 0.0.2 [beta] (View all) |
| Compatible Kibana version(s) | 8.3.0 or higher |
| Supported Serverless project types
What’s this? | Security
Observability |
| Subscription level
What’s this? | Basic |

</div>

Compatibility

This package works with Kibana 8.3.0 and later.

Kibana logs

The Kibana integration collects logs from Kibana instance.

Logs

Audit

Audit logs collects the Kibana audit logs.

An example event for kibana_audit looks as following:

		{
    "event": {
        "action": "http_request",
        "category": [
            "web"
        ],
        "outcome": "unknown"
    },
    "http": {
        "request": {
            "method": "get"
        }
    },
    "url": {
        "domain": "localhost",
        "path": "/internal/security/session",
        "port": 5601,
        "scheme": "http"
    },
    "user": {
        "name": "elastic",
        "roles": [
            "superuser"
        ]
    },
    "kibana": {
        "space_id": "default",
        "session_id": "ccZ0sbxrmmJwo+/y2Mn1tmGIrKOuZYaF8voUh0SkA/k="
    },
    "trace": {
        "id": "1c8c5808-d2d6-41fc-8cb7-998aa8996be9"
    },
    "ecs": {
        "version": "8.0.0"
    },
    "@timestamp": "2022-06-29T12:05:03.742+00:00",
    "message": "User is requesting [/internal/security/session] endpoint",
    "log": {
        "level": "INFO",
        "logger": "plugins.security.audit.ecs"
    },
    "process": {
        "pid": 7
    },
    "transaction": {
        "id": "f8863d86567119e6"
    }
}

	

Field	Description	Type
@timestamp	Event timestamp.	date
data_stream.dataset	Data stream dataset.	constant_keyword
data_stream.namespace	Data stream namespace.	constant_keyword
data_stream.type	Data stream type.	constant_keyword
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.action	The action captured by the event. This describes the information in the event. It is more specific than `event.category`. Examples are `group-add`, `process-started`, `file-created`. The value is normally defined by the implementer.	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
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
event.ingested	Timestamp when an event arrived in the central data store. This is different from `@timestamp`, which is when the event originally occurred. It’s also different from `event.created`, which is meant to capture the first time an agent saw the event. In normal conditions, assuming no tampering, the timestamps should chronologically look like this: `@timestamp` < `event.created` < `event.ingested`.	date
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.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
http.request.method	HTTP request method. The value should retain its casing from the original event. For example, `GET`, `get`, and `GeT` are all considered valid values for this field.	keyword
kibana.add_to_spaces	The set of space ids that a saved object was shared to.	keyword
kibana.authentication_provider	The authentication provider associated with a login event.	keyword
kibana.authentication_realm	The Elasticsearch authentication realm name which fulfilled a login event.	keyword
kibana.authentication_type	The authentication provider type associated with a login event.	keyword
kibana.delete_from_spaces	The set of space ids that a saved object was removed from.	keyword
kibana.lookup_realm	The Elasticsearch lookup realm which fulfilled a login event.	keyword
kibana.saved_object.id	The id of the saved object associated with this event.	keyword
kibana.saved_object.type	The type of the saved object associated with this event.	keyword
kibana.session_id	The ID of the user session associated with this event. Each login attempt results in a unique session id.	keyword
kibana.space_id	The id of the space associated with this event.	keyword
log.level	Original log level of the log event. If the source of the event provides a log level or textual severity, this is the one that goes in `log.level`. If your source doesn’t specify one, you may put your event transport’s severity here (e.g. Syslog severity). Some examples are `warn`, `err`, `i`, `informational`.	keyword
log.logger	The name of the logger inside an application. This is usually the name of the class which initialized the logger, or can be a custom name.	keyword
message	For log events the message field contains the log message, optimized for viewing in a log viewer. For structured logs without an original message field, other fields can be concatenated to form a human-readable summary of the event. If multiple messages exist, they can be combined into one message.	match_only_text
process.pid	Process id.	long
trace.id	Unique identifier of the trace. A trace groups multiple events like transactions that belong together. For example, a user request handled by multiple inter-connected services.	keyword
transaction.id	Unique identifier of the transaction within the scope of its trace. A transaction is the highest level of work measured within a service, such as a request to a server.	keyword
url.domain	Domain of the url, such as "http://www.elastic.co[www.elastic.co]". In some cases a URL may refer to an IP and/or port directly, without a domain name. In this case, the IP address would go to the `domain` field. If the URL contains a literal IPv6 address enclosed by `[` and `]` (IETF RFC 2732), the `[` and `]` characters should also be captured in the `domain` field.	keyword
url.path	Path of the request, such as "/search".	wildcard
url.port	Port of the request, such as 443.	long
url.query	The query field describes the query string of the request, such as "q=elasticsearch". The `?` is excluded from the query string. If a URL contains no `?`, there is no query field. If there is a `?` but no query, the query field exists with an empty string. The `exists` query can be used to differentiate between the two cases.	keyword
url.scheme	Scheme of the request, such as "https". Note: The `:` is not part of the scheme.	keyword
user.name	Short name or login of the user.	keyword
user.name.text	Multi-field of `user.name`.	match_only_text
user.roles	Array of user roles at the time of the event.	keyword

Log

Log collects the Kibana logs.

An example event for kibana_log looks as following:

		{
    "http": {
        "request": {
            "id": "unknownId",
            "method": "GET"
        },
        "response": {
            "body": {
                "bytes": 118
            },
            "status_code": 200
        }
    },
    "url": {
        "path": "/_nodes",
        "query": "filter_path=nodes.*.version%2Cnodes.*.http.publish_address%2Cnodes.*.ip"
    },
    "ecs": {
        "version": "8.0.0"
    },
    "@timestamp": "2022-07-14T10:35:25.366+00:00",
    "message": "200 - 118.0B\nGET /_nodes?filter_path=nodes.*.version%2Cnodes.*.http.publish_address%2Cnodes.*.ip",
    "log": {
        "level": "DEBUG",
        "logger": "elasticsearch.query.data"
    },
    "process": {
        "pid": 7
    },
    "trace": {
        "id": "0cd8dd5a3483159a43c07e9205432775"
    },
    "transaction": {
        "id": "6301eca88fba8d99"
    }
}

	

Field	Description	Type
@timestamp	Event timestamp.	date
data_stream.dataset	Data stream dataset.	constant_keyword
data_stream.namespace	Data stream namespace.	constant_keyword
data_stream.type	Data stream type.	constant_keyword
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.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
event.ingested	Timestamp when an event arrived in the central data store. This is different from `@timestamp`, which is when the event originally occurred. It’s also different from `event.created`, which is meant to capture the first time an agent saw the event. In normal conditions, assuming no tampering, the timestamps should chronologically look like this: `@timestamp` < `event.created` < `event.ingested`.	date
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.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
http.request.id	A unique identifier for each HTTP request to correlate logs between clients and servers in transactions. The id may be contained in a non-standard HTTP header, such as `X-Request-ID` or `X-Correlation-ID`.	keyword
http.request.method	HTTP request method. The value should retain its casing from the original event. For example, `GET`, `get`, and `GeT` are all considered valid values for this field.	keyword
http.response.body.bytes	Size in bytes of the response body.	long
http.response.status_code	HTTP response status code.	long
log.level	Original log level of the log event. If the source of the event provides a log level or textual severity, this is the one that goes in `log.level`. If your source doesn’t specify one, you may put your event transport’s severity here (e.g. Syslog severity). Some examples are `warn`, `err`, `i`, `informational`.	keyword
log.logger	The name of the logger inside an application. This is usually the name of the class which initialized the logger, or can be a custom name.	keyword
message	For log events the message field contains the log message, optimized for viewing in a log viewer. For structured logs without an original message field, other fields can be concatenated to form a human-readable summary of the event. If multiple messages exist, they can be combined into one message.	match_only_text
process.pid	Process id.	long
trace.id	Unique identifier of the trace. A trace groups multiple events like transactions that belong together. For example, a user request handled by multiple inter-connected services.	keyword
transaction.id	Unique identifier of the transaction within the scope of its trace. A transaction is the highest level of work measured within a service, such as a request to a server.	keyword
url.path	Path of the request, such as "/search".	wildcard
url.query	The query field describes the query string of the request, such as "q=elasticsearch". The `?` is excluded from the query string. If a URL contains no `?`, there is no query field. If there is a `?` but no query, the query field exists with an empty string. The `exists` query can be used to differentiate between the two cases.	keyword

Changelog

Version	Details	Kibana version(s)
0.0.2	pass:[] Enhancement (View pull request) Added categories and/or subcategories.	—
0.0.1	pass:[] Enhancement (View pull request) Initial draft of the package	—