自定义字段
编辑自定义字段
编辑ECS 定义了字段、其数据类型和使用方法，并将它们分类为“核心”和“扩展”级别。
但是，ECS 没有定义关于自定义字段的任何内容。根据定义，它们是附加字段，完全按照用户或集成定义的方式，独立于 ECS。
用户和集成可以随意在其事件中捕获附加信息作为自定义字段。这种灵活性是设计使然，确保没有人因为 ECS 尚未支持某些内容而受到阻碍。
然而，ECS 正在积极开发中。添加自定义字段存在与未来 ECS 字段冲突的小风险。有一些方法可以对自定义字段进行建模，从而降低与未来版本的 ECS 冲突的可能性。本节概述了其中几种策略。
建模以降低冲突的可能性
编辑labels 字段
编辑任何时候，如果数据源有一些可以使用 keyword 数据类型建模的额外字段，捕获它们最简单的方法是使用 ECS 字段 labels。
示例
{ "labels": { "foo_id": "beef42", "env": "production" },
"message": "...",
"event": { ... }
}
如果 labels 不适用于您的用例，这里有一些额外的技巧可以避免冲突。
专有名词
编辑ECS 尝试通过使用概念名称来建模信息，并避免使用专有名词，例如工具名称、项目名称或公司名称。扩展来说，在专有名词下嵌套自定义字段是添加自定义字段的一种相对安全的方法。例如，Filebeats 模块采用的就是这种方法。
例如，来自 HAProxy 的 HTTP 日志将包含典型的 HTTP 信息，以及代理详细信息和统计信息。标准 HTTP 信息可以捕获在 ECS 字段集 http 和 url 中，额外详细信息可以在自定义 haproxy 部分中捕获。
{ "http": { "request": { "method": "get", ... },
"response": { "status_code": 200, ... } },
"url": { "original": "/favicon.ico", ... },
"haproxy": { "frontend_name": "myfrontend", "backend_name": "mybackend_prod",
"backend_queue": 0, ... }
}
大小写
编辑ECS 努力通过使用嵌套来分组相关概念，并使用下划线连接单词来保持一致的风格。遵循这些自定义字段准则可以确保在整个模式中保持相同的一致性体验。
但是，请注意，偏离这些自定义字段准则可以为您带来优势。这可能是区分 ECS 字段和自定义字段的好方法。由于 ECS 不对字段名称使用大写字母，因此这种方法实际上可以保证自定义字段不会与未来的 ECS 字段冲突。
常见的代理概念可以通过大写但通用的概念名称进行建模。
HAProxy 示例
{ "http": { "request": { "method": "get", ... } },
"url": { "original": "/favicon.ico", ... },
"Proxy": { "FrontendName": "myfrontend", "BackendName": "mybackend_prod" },
"event": { "module": "haproxy" }
}
NGINX 示例
{ "http": { "request": { "method": "get", ... } },
"url": { "original": "/favicon.ico", ... },
"Proxy": { "FrontendName": "another_frontend", "BackendName": "another_backend_prod" },
"event": { "module": "nginx" }
}
以上内容表明，在自定义字段中使用通用概念名称仍然有利于关联填充它们的多个来源。使用大写可以确保未来定义 proxy 字段集的 ECS 版本不会发生冲突。
这是一个示例事件，在从自定义字段迁移到使用新的等效 ECS 字段集期间。
{ "http": { "request": { "method": "get", ... } },
"Proxy": { "FrontendName": "myfrontend", "BackendName": "mybackend_prod" },
"proxy": { "frontend_name": "myfrontend", "backend_name": "mybackend_prod" }
}
迁移期间，以上内容看起来会很奇怪。但是，在事件中仍然存在自定义字段的同时开始填充 ECS 字段的能力，使得将升级到新版本的 ECS 与调整管道和分析内容的时间解耦成为可能。