syslog PRI

[willemdh]

Is syslog program is meant for process.name, is there a field for the PRI syslog field (which I used to name syslog_pri). This allows for calculation of facility and severity:

https://gist.github.com/marvin/1017480

[praseodym]

There is event.severity, but only as a long. I don't see a good way to map facility and severity labels from the syslog_pri filter.

[ruflin]

It seems to me PRI is a syslog specific field and because of this should be long under a syslog prefix as you did. Either syslog_pri or syslog.pri. Is PRI also used by other services?

[willemdh]

Most syslog sources have a PRI field. Haven't seen PRI usage in non syslog data. A dedicated syslog object could also contain syslog.facility and syslog.severity.

Or syslog specific data, seeing as these are pure logs, could maybe better get mapped under log.* ?

log.pri
log.facility
log.level

Creating another 'root object' specific for syslog might be a little overkill?

[ruflin]

I would prefer to not have service specific fields in the generic objects. I tempted to say at the moment because of it would belong under syslog.pri but not sure if it should be part of ECS. At the same time syslog is very popular.

[ph]

Since severity and facility are actually extracted from the priority I think they should be prefixed by a syslog and for reference this is what the current Filebeat syslog input does.

https://github.com/elastic/beats/blob/master/filebeat/input/syslog/input.go#L240

[willemdh]

A dedicated syslog object is ok for me. So is this mapping what we need?

"syslog": {
  "properties": {
    "pri": {
      "type": "long"
    },
    "severity": {
      "ignore_above": 1024,
      "type": "keyword"
    },
    "facility": {
      "ignore_above": 1024,
      "type": "keyword"
    }
  }
}

[ruflin]

I'm working on extending our use cases here: #55 This would allow us to have a fields.yml for syslog in the use cases and then decide later if it makes sense in ECS directly or not but have it there for others to share (and comment).

[willemdh]

This will soon be resolved, see #525
Thanks all!