Support Elastic Common Schema in OpenTelemetry

text/0000-support-elastic-common-schema-in-opentelemetry.md

@@ -0,0 +1,251 @@
+# Support Elastic Common Schema in OpenTelemetry
+
+Collaborators: Alolita Sharma (OTEL GC, AWS), Cyrille Le Clerc (Elastic), Daniel Khan (Elastic), Christian Beedgen (Sumo), Jonah Kowall (Logz.io), Tigran N. (Splunk)
+
+
+## Introduction
+
+This proposal is to add support for the Elastic Common Schema (ECS) in the OpenTelemetry specification and provide full interoperability for ECS in OpenTelemetry component implementations.
+
+
+## Motivation
+
+Adding the Elastic Common Schema (ECS) to OpenTelemetry (OTEL) is a great way to accelerate the integration of vendor-created logging and OTEL component logs (ie OTEL Collector Logs Receivers). The goal is to define vendor neutral semantic conventions for most popular types of systems and support vendor created or open-source components (for example HTTP access logs, network logs, system access/authentication logs) extending OTEL correlation to these new signals.
+
+Adding the coverage of ECS to OTEL would provide guidance to authors of OpenTelemetry Collector Logs Receivers and help establish the OTEL Collector as a de facto standard log collector with a well-defined schema to allow for richer data definition.
+
+In addition to the use case of structured logs, the maturity of ECS for SIEM (Security Information and Event Management) is a great opportunity for OpenTelemetry to expand its scope to the security use cases.
+
+Another significant use case is providing first-class support for Kubernetes application logs, system logs as well as application introspection events. We would also like to see support for structured events (e.g. [k8seventsreceiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8seventsreceiver)) and using ‘content-type' to identify event types.
+
+We'd like to see different categories of structured logs being well-supported in the [OTEL Log Data Model](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md), presumably through [semantic conventions for log attributes](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-attributes). For example, NGINX access logs and Apache access logs should be processed the same way as structured logs. This would help in trace and metric correlation with such log data as well as it would help grow the ecosystem of curated UIs provided by observability backends and monitoring dashboards (e.g. one single HTTP Access log dashboard benefiting Apache HTTPD, Nginx, and HAProxy).
+
+
+## Customer Motivation
+
+Adoption of OTEL logs will accelerate greatly if ECS is leveraged as the common standard, using this basis for normalization. OTEL Logs adoption will be accelerated by this support. For example, ECS can provide the unified structured format for handling vendor generated along with open source logs.
+
+Customers will benefit from turnkey logs integrations that will be fully recognized by OTEL compatible observability products and services.
+
+OpenTelemetry logging is today mostly structured when instrumentation libraries are used. However, most of the logs which exist today are generated by software, hardware, and cloud services which the user cannot control. OpenTelemetry provides a limited set of "reference integrations" to  structure logs: primarily the [OpenTelemetry Collector Kubernetes Events Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8seventsreceiver) and an example of a regexp based parsing of Tomcat access logs with OpenTelemetry Collector File Receiver ([here](https://github.com/open-telemetry/opentelemetry-log-collection/blob/30807b96b2f0771e7d11452ebf98fe5e211ed6d7/examples/tomcat/config.yaml#L20)).
+
+The semantic conventions of a log are a challenge. What is a specific component defined in a log and how does it relate to other logs which have the same semantic component defined differently. ECS has already done some heavy-lifting on defining a unified set of semantic conventions which can be adopted in OTEL.
+
+OpenTelemetry has the potential to grow exponentially if the data from these other services can be correlated with instrumented code and components. In order to do this, industry stakeholders should leverage a common and standard logging data model which allows for the mapping of these different data types. The OpenTelemetry data protocol can provide this interoperable open standard. This unlocks countless use cases, and ensures that OpenTelemetry can work with other technologies which are not OpenTelemetry compliant.
+
+
+## Background
+
+
+### What is ECS?
+
+The [Elastic Common Schema (ECS)](https://github.com/elastic/ecs) is an open source specification, developed with support from Elastic's user community. ECS defines a common set of fields to be used when storing data in Elasticsearch, such as logs, metrics, and security and audit events.  The goal of ECS is to enable and encourage users of Elasticsearch to normalize their event data, so that they can better analyze, visualize, and correlate the data represented in their events. Learn more at: [https://www.elastic.co/guide/en/ecs/current/ecs-reference.html](https://www.elastic.co/guide/en/ecs/current/ecs-reference.html)
+
+The coverage of ECS is very broad including in depth support for logs, security, and network events such as "[logs.* fields](https://www.elastic.co/guide/en/ecs/current/ecs-log.html)" , "[geo.* fields](https://www.elastic.co/guide/en/ecs/current/ecs-geo.html)", "[tls.* fields](https://www.elastic.co/guide/en/ecs/current/ecs-tls.html)", "[dns.* fields](https://www.elastic.co/guide/en/ecs/current/ecs-dns.html)", or "[vulnerability.* fields](https://www.elastic.co/guide/en/ecs/current/ecs-vulnerability.html)".
+
+ECS has the following guiding principles:
+
+* ECS favors human readability in order to enable broader adoption,
+* ECS events include metadata to enable correlations across any dimension (host, data center, docker image, ip address...),
+    * ECS doesn't differentiate the metadata fields that are specific to each event of the event source and the metadata that are shared by all the events of the source the same way OTEL differentiates Resource Attributes and Log/Span Attributes),
+* ECS groups fields in namespaces in order to:
+    * Offer consistency and readability,
+    * Enable reusability of namespaces in different contexts,
+        * For example, the "geo" namespace is nested in the "client.geo", "destination.geo", "host.geo" or "threat.indicator.geo" namespaces
+    * Enable extensibility adding fields to namespaces and adding new namespaces,
+    * Prevent field name conflicts
+* ECS covers a broad spectrum of events with 40+ namespaces including detailed coverage of security and network events. It's much broader than simple logging use cases.
+
+
+### Example of a log message structured with ECS: NGINX access logs
+
+Example of a Nginx Access Log entry structured with ECS
+
+
+```json
+{
+   "@timestamp":"2020-03-25T09:51:23.000Z",
+   "client":{
+      "ip":"10.42.42.42"
+   },
+   "http":{
+      "request":{
+         "referrer":"-",
+         "method":"GET"
+      },
+      "response":{
+         "status_code":200,
+         "body":{
+            "bytes":2571
+         }
+      },
+      "version":"1.1"
+   },
+   "url":{
+      "path":"/blog"
+   },
+   "user_agent":{
+      "original":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36",
+      "os":{
+         "name":"Mac OS X",
+         "version":"10.14.0",
+         "full":"Mac OS X 10.14.0"
+      },
+      "name":"Chrome",
+      "device":{
+         "name":"Other"
+      },
+      "version":"70.0.3538.102"
+   },
+   "log":{
+      "file":{
+         "path":"/var/log/nginx/access.log"
+      },
+      "offset":33800
+   },
+   "host": {
+     "hostname": "cyrille-laptop.home",
+     "os": {
+       "build": "19D76",
+       "kernel": "19.3.0",
+       "name": "Mac OS X",
+       "family": "darwin",
+       "version": "10.15.3",
+       "platform": "darwin"
+     },
+     "name": "cyrille-laptop.home",
+     "id": "04A12D9F-C409-5352-B238-99EA58CAC285",
+     "architecture": "x86_64"
+   }
+
+}
+```
+
+
+
+## Comparison between OpenTelemetry Semantic Conventions for logs and ECS
+
+
+## Principles
+
+| Description | [OTel Logs and Event Record](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition) | [Elastic Common Schema (ECS)](https://www.elastic.co/guide/en/ecs/current/ecs-reference.html) |
+|-------------|-------------|--------|
+| Metadata shared by all the Log Messages / Spans of an application instance | Resource Attributes | ECS fields |
+| Metadata specific to each Log Message / Span | Attributes | ECS Fields |
+| Message of log events | Body | [message field](https://www.elastic.co/guide/en/ecs/current/ecs-base.html#field-message) |
+| Naming convention | Dotted names | Dotted names |
+| Reusability of namespaces | Namespaces are intended to be composed | Namespaces are intended to be composed |
+| Extensibility | Attributes can be extended by either adding a user defined field to an existing namespaces or introducing new namespaces. | Extra attributes can be added in each namespace and users can create their own namespaces |
+
+## Data Types
+
+| Category | <a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">OTel Logs and Event Record</a> (all or a subset of <a href="https://developers.google.com/protocol-buffers/docs/proto3">GRPC data types</a>) | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/mapping-types.html">ECS Data Types</a> |
+|---|---|---|
+| Text | string | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/text.html#text-field-type">text</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/text.html#match-only-text-field-type">match_only_text</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/keyword.html#keyword-field-type">keyword</a> <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/keyword.html#constant-keyword-field-type">constant_keyword</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/keyword.html#wildcard-field-type">wildcard</a> | 
+| Dates | uint64 nanoseconds since Unix epoch | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/date.html">date</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/date_nanos.html">date_nanos</a> | 
+| Numbers | number | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/number.html">long</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/number.html">double</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/number.html">scaled_float</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/boolean.html">boolean</a>… | 
+| Objects | uint32, uint64… | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/object.html">object</a> (JSON object), <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/flattened.html">flattened</a> (An entire JSON object as a single field value) | 
+| Structured Objects | No complex semantic data type specified for the moment (e.g. string is being used for ip addresses rather than having an "ip" data structure in Otel). <br/> Note that Otel supports arrays and nested objects. | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/ip.html">ip</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/geo-point.html">geo_point</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/geo-shape.html">geo_shape</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/version.html">version</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/range.html">long_range</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/range.html">date_range</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/range.html">ip_range</a> | 
+| Binary data | Byte sequence | <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/binary.html">binary</a> | 
+
+
+
+
+## Known Differences
+
+Some differences exist on fields that are both defined in OpenTelemetry Semantic Conventions and in ECS. In this case, it would make sense for overlapping ECS fields to not be integrated in the new specification.
+
+<!-- 
+As the markdown code of the tables is hard to read and maintain with very long lines, we experiment maintaining this one as an HTML table 
+-->
+
+<table>
+  <tr>
+   <td><strong><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">OTel Logs and Event Record</a></strong>
+   </td>
+   <td><strong><a href="https://www.elastic.co/guide/en/ecs/current/ecs-reference.html">Elastic Common Schema (ECS)</a></strong>
+   </td>
+   <td><strong>Description</strong>
+   </td>
+  </tr>
+  <tr>
+   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">Timestamp</a> (uint64 nanoseconds since Unix epoch)
+   </td>
+   <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-base.html#field-timestamp">@timestamp</a> (date)
+   </td>
+   <td>
+   </td>
+  </tr>
+  <tr>
+   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">TraceId</a> (byte sequence), <a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">SpanId</a> (byte sequence)
+   </td>
+   <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-tracing.html#field-trace-id">trace.id</a> (keyword), <a href="https://www.elastic.co/guide/en/ecs/current/ecs-tracing.html#field-trace-id">span.id</a> (keyword)
+   </td>
+   <td>
+   </td>
+  </tr>
+  <tr>
+   <td>N/A
+   </td>
+   <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-tracing.html#field-transaction-id">Transaction.id</a> (keyword)
+   </td>
+   <td>
+   </td>
+  </tr>
+  <tr>
+   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">SeverityText</a> (string)
+   </td>
+   <td>l<a href="https://www.elastic.co/guide/en/ecs/current/ecs-log.html#field-log-syslog-severity-name">og.syslog.severity.name</a> (keyword), <a href="https://www.elastic.co/guide/en/ecs/current/ecs-log.html#field-log-level">log.level</a> (keyword)
+   </td>
+   <td>
+   </td>
+  </tr>
+  <tr>
+   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">SeverityNumber</a> (number)
+   </td>
+   <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-log.html#field-log-syslog-severity-code">log.syslog.severity.code</a>
+   </td>
+   <td>
+   </td>
+  </tr>
+  <tr>
+   <td><a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition">Body</a> (any)
+   </td>
+   <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-base.html#field-message">message</a> (match_only_text)
+   </td>
+   <td>
+   </td>
+  </tr>
+  <tr>
+   <td>process.cpu.load (not specified but collected by Otel Collector)
+<p>
+<a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/process-metrics.md">process.cpu.time</a> (async counter)
+<p>
+<a href="https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/system-metrics.md">system.cpu.utilization</a>	
+   </td>
+   <td><a href="https://www.elastic.co/guide/en/ecs/current/ecs-host.html#field-host-cpu-usage">host.cpu.usage</a> (scaled_float) with a slightly different measurement than what otel metrics measure
+   </td>
+   <td>Note that most metrics have slightly different names and semantics between ECS and OpenTelemetry
+   </td>
+  </tr>
+</table>
+
+
+
+# Alternatives / Discussion
+
+
+## Prometheus Naming Conventions
+
+Prometheus is a de facto standard for observability metrics and OpenTelemetry already provides full interoperability with the Prometheus ecosystem.
+
+It would be useful to get interoperability between metrics collected by [official Prometheus exporters](https://prometheus.io/docs/instrumenting/exporters/) (e.g. the [Node/system metrics exporter](https://github.com/prometheus/node_exporter) or the [MySQL server exporter](https://github.com/prometheus/mysqld_exporter)) and their equivalent OpenTelemetry Collector receivers (e.g. Otel Collector [Host Metrics Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver) or [MySQL Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/mysqlreceiver)).
+
+Note that one of the challenges with Prometheus metrics naming conventions is that these are implicit conventions defined by each integration author which doesn't enable correlation due to the lack of consistency across integrations. For example, this inconsistency increases the complexity that an end-user has to deal with when configuring and monitoring alerts.
+
+Prometheus' conventions are restricted to the style of the name of the metrics (see [Metric and label naming | Prometheus](https://prometheus.io/docs/practices/naming/) ) but don't specify unified metric names.
+
+
+# Other areas that need to be addressed by OTEL (the project)
+
+Some areas that need to be addressed in the long run as ECS is integrated into OTEL include defining the innovation process, providing maintainer rights to Elastic contributors who maintain ECS today, ensuring the OTEL specification incorporates the changes to accommodate ECS, and a process for handling breaking changes if any (the proposal [Define semantic conventions and instrumentation stability #2180](https://github.com/open-telemetry/opentelemetry-specification/pull/2180) should tackle this point). Also, migration of existing naming (e.g. Prometheus exporter) to standardized convention (see [Semantic Conventions for System Metrics](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/system-metrics.md) , [Semantic Conventions for OS Process Metrics](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/process-metrics.md)).