Session object

[willemdh]

So I need quite a few session related fields for my F5 project. Do I place it in my new f5 object or should session deserve it's own tlf (top level field ;) )

For example:

        "f5": {
            "session": {
              "properties": {
                "id": {
                  "ignore_above": 1024,
                  "type": "keyword"
                },
                "key": {
                  "ignore_above": 1024,
                  "type": "keyword"
                },
                "value": {
                  "ignore_above": 1024,
                  "type": "keyword"
                },
                "bytes_in": {
                  "type": "long"
                },
                "bytes_out": {
                  "type": "long"
                },
                "client_ip": {
                  "type": "ip"
                },
                "deleted_reason": {
                  "ignore_above": 1024,
                  "type": "keyword"
                },
                "listener": {
                  "ignore_above": 1024,
                  "type": "keyword"
                },
                "location": {
                  "ignore_above": 1024,
                  "type": "keyword"
                },
                "vip_ip": {
                  "type": "ip"
                }
              }
            }

[ruflin]

I wonder if quite a few of the above fields already map to ECS under network.* for the bytes part. Do you have some other use cases then F5 in mind that could use the session prefix?

[willemdh]

For now I have no other use cases then F5. The most important field for session info, is f5.session.id which contains the id tha allows for F5 event correlation. I could place this in event.id. I think I can grok location into geoip.* fields.
bytes_in, bytes_out and client_ip could indeed get mapped to network.* fields
But what about deleted_reason, listener and reputation, vip ip..

[willemdh]

@ruflin Hmm just noticed event.id documentation says: Unique ID to describe the event.

But the session id is not unique for an event. Multiple events ould have the same session id.. So maybe this isn't so ideal after all..

[MikePaquette]

@willemdh yes, event.id is not meant to contain the session ID. Our intent was that the network.* fields would include common fields relating to sessions/connections. It would appear that a session or connection id should be added, for example network.session_id. Also a network.vip_ip could also make sense.

Can you point to F5 doc that specs out these fields with their descriptions and any recommended values, so we can better understand deleted_reason, listener, and reputation?

[willemdh]

F5 syslog documentation is sparse and is different for major versions. You can find some info here: https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-network-access-12-1-0/10.html#referenced and here:
https://support.f5.com/csp/article/K16702

Network. Session_id would work for me.

[ruflin]

@willemdh I opened #52 to discuss on how we could best share things like an f5 example data structure without indicating it's part of ECS.

[ebeahan]

Work has begun to discuss in the session RFC

[Oddly]

Resurrecting a very old issue, but where has this gone? There has been an RFC, but no sign of this being implemented in the ECS itself. Will this be implemented eventually or will this stay custom?

[willemdh]

Seems like there hasnt been a lot of movement in https://github.com/elastic/ecs/blob/main/rfcs/text/0004-session.md