ebeahan
commented
2 years ago Instead of thinking about new fields first, I recommend striving to map into existing ECS fields as much as appropriate. With most data sources, there are already a lot of values to map:
- Base fields like
messageand@timestamp event.original, event categorization, and other metadata underevent.*log.*transport detailsnetwork.*,error.*,service.*,user.*
Hopefully, this gives an idea of a starting point. Mapping to existing fields allows correlating the call records logs with other ECS-aligned events.
After mapping different call record events, there may be common concepts not already represented somehow ECS. Once the scope is better understood, you could open an RFC to propose additional fields and include sample logs to anchor the discussion.
Custom fields are always another welcomed option for internal-only concepts or less-common uses cases. There's a list of recommended practices in the ECS docs to avoid future field conflicts.
Summary
I'd like to have a standard for mapping telephony type data (phone call records) to be able to use across providers.
Motivation:
One of the major use cases for Elasticsearch is time series data, and one use case that I've come across is storing call records (call logs). One of the issues I've come across though, is that if you have call logs from multiple different providers, it can be somewhat of a challenge to link them together as not everyone uses the same naming conventions/standards/formats for everything.
Question:
Is this something that would be considered for addition to ECS, or is this type of data outside the scope of the intent for ECS to be considered?