From 08e0243b4f3b75d19ebe14bfb48bac97730ef960 Mon Sep 17 00:00:00 2001 From: Sean ZO Marciniak Date: Thu, 11 Nov 2021 16:00:57 +1030 Subject: [PATCH] Fixing misspell issues --- ...classification.md => 0187-data-classification.md} | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) rename text/{187-data-classification.md => 0187-data-classification.md} (96%) diff --git a/text/187-data-classification.md b/text/0187-data-classification.md similarity index 96% rename from text/187-data-classification.md rename to text/0187-data-classification.md index 3a34121b9..136835d37 100644 --- a/text/187-data-classification.md +++ b/text/0187-data-classification.md @@ -7,7 +7,7 @@ Adding optional classification to the attributes and resources to support simpli As the scope of Observability changes to include user monitoring and analytics (Real User Monitoring for now), ensuring that data is handled correctly is becoming more problematic as the problem space changes to include more. The need for pre processing data in order that high cardinality, sensitive user data, and handling sparse data impacts the reliability and usability of the data. Furthermore, some vendors are not able to selectively remove sensitive user data or some agreements with customers mandate that sensitive data not to leave the internal edge. Moreover, attribute values that are known high cardinality (for example a container id within a cloud based environment) that are expensive to store within observability systems, making it easier to omit attributes as part of exporter or collector configuration can greatly reduce cost of the observability suite.; not all attributes and resource data hold the same value or have the same processing requirements. -Updating the SDK to include the convention of data classification would mean that users can extend their current telemetry via an opt in process to enable enhanced controls over the telemetry data without impacting the developer experience. Instrumentation authors are not limited by what attributes they can use when developing their telemetry and not a hinderance for existing standards within Open Telemetry. Organisations can define what resource classifications are allowed to be processed by an observability suite, what is subject to additional processing, and understand the types of data being sent. For example, all high cardinality data can be sent to on prem short term storage and then forwarded to a vendor with high cardinality attributes removed so that it can be viewed over a longer time period to show trends. +Updating the SDK to include the convention of data classification would mean that users can extend their current telemetry via an opt in process to enable enhanced controls over the telemetry data without impacting the developer experience. Instrumentation authors are not limited by what attributes they can use when developing their telemetry and not a hindrance for existing standards within Open Telemetry. Organisations can define what resource classifications are allowed to be processed by an observability suite, what is subject to additional processing, and understand the types of data being sent. For example, all high cardinality data can be sent to on prem short term storage and then forwarded to a vendor with high cardinality attributes removed so that it can be viewed over a longer time period to show trends. Having the ability to set data classification on resources means that: @@ -122,7 +122,7 @@ processors: service: pipeline: metrics: - recievers: + receivers: - otlp/metrics processor: - classifier/remove-highcardinality @@ -130,7 +130,7 @@ service: exporter: - external-metric-vendor traces: - recievers: + receivers: - otlp/traces processors: - classifier/tracesampler @@ -157,7 +157,7 @@ message KeyValue { // Defined at https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/metrics/v1/metrics.proto#L160 message Metric { -// ... ommitted +// ... omitted + // classification represents a bitwise flag + // that is used to represent metric classification type + int64 classification = 12; @@ -165,7 +165,7 @@ message Metric { // Defined at https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/trace/v1/trace.proto#L84 message Span { -// ... ommitted +// ... omitted + // classification represents a bitwise flag + // that is used to represent span classification type + int64 classification = 16; @@ -173,7 +173,7 @@ message Span { // Defined at https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/logs/v1/logs.proto#L113 message LogRecord { -// ... ommitted +// ... omitted + // classification represents a bitwise flag + // that is used to represent LogRecord classification type + int64 classification = 11;