docs(file source): fix some typos (vectordotdev#18401)

fix some typos

Signed-off-by: cui fliter <imcusg@gmail.com>
Co-authored-by: cui fliter <imcusg@gmail.com>

STYLE.md

@@ -229,7 +229,7 @@ would know that the queue size was _currently_ zero but we'd also know that we j
   [Component
   Specification](https://github.com/vectordotdev/vector/blob/master/docs/specs/component.md).
 - **Don't** emit metrics in tight loops. Each metric emission carries an overhead, and emitting them
-  in tight loops can cause that overhead to become noticable in terms of CPU usage and throughput
+  in tight loops can cause that overhead to become noticeable in terms of CPU usage and throughput
   reduction. Instead of incrementing a counter every time a loop iteration occurs, you might
   consider incrementing a local variable instead, and then emitting that sum after the loop is over.
 - **Don't** update a counter to measure the total number of operations/events/etc if you're already

docs/tutorials/sinks/1_basic_sink.md

@@ -273,7 +273,7 @@ emit the event. Change the body of `run_inner` to look like the following:
 
 ## EventSent
 
-[`EventSent`][events_sent] is emmitted by each component in Vector to
+[`EventSent`][events_sent] is emitted by each component in Vector to
 instrument how many bytes have been sent to the next downstream component.
 
 Add the following after emitting `BytesSent`:

lib/codecs/src/decoding/format/gelf.rs

@@ -22,7 +22,7 @@ use crate::{gelf_fields::*, VALID_FIELD_REGEX};
 
 /// On GELF decoding behavior:
 ///   Graylog has a relaxed decoding. They are much more lenient than the spec would
-///   suggest. We've elected to take a more strict approach to maintain backwards compatability
+///   suggest. We've elected to take a more strict approach to maintain backwards compatibility
 ///   in the event that we need to change the behavior to be more relaxed, so that prior versions
 ///   of vector will still work with the new relaxed decoding.
 

lib/codecs/src/encoding/format/gelf.rs

@@ -16,7 +16,7 @@ use vector_core::{
 
 /// On GELF encoding behavior:
 ///   Graylog has a relaxed parsing. They are much more lenient than the spec would
-///   suggest. We've elected to take a more strict approach to maintain backwards compatability
+///   suggest. We've elected to take a more strict approach to maintain backwards compatibility
 ///   in the event that we need to change the behavior to be more relaxed, so that prior versions
 ///   of vector will still work.
 ///   The exception is that if 'Additional fields' are found to be missing an underscore prefix and

lib/vector-core/src/event/estimated_json_encoded_size_of.rs

@@ -87,7 +87,7 @@ impl EstimatedJsonEncodedSizeOf for Value {
 /// need for UTF-8 replacement characters.
 ///
 /// This is the main reason why `EstimatedJsonEncodedSizeOf` is named as is, as most other types can
-/// be calculated exactly without a noticable performance penalty.
+/// be calculated exactly without a noticeable performance penalty.
 impl EstimatedJsonEncodedSizeOf for str {
     fn estimated_json_encoded_size_of(&self) -> JsonSize {
         JsonSize::new(QUOTES_SIZE + self.len())

rfcs/2021-07-27-7117-vrl-string-interpolation.md

@@ -1,7 +1,7 @@
 # RFC 7117 - 2021-07-27 - VRL string interpolation
 
 VRL needs a better way to format strings. Currently the only way to do this is
-to concatenate strings, which can get unwieldly.
+to concatenate strings, which can get unwieldy.
 
 ## Scope
 
@@ -13,7 +13,7 @@ literals, also known as string interpolation, to format strings.
 Currently the way to create strings is through either string concatenation or
 the `join` function.
 
-Syntactically this is unwieldly. It requires extra key presses and the code
+Syntactically this is unwieldy. It requires extra key presses and the code
 created doesn't necessarily give an instant idea of what the resulting string
 will look like. Thus the true intent behind the code is obfuscated, which can
 result in bugs.

rfcs/2022-03-15-11851-ingest-opentelemetry-traces.md

@@ -156,7 +156,7 @@ universal representation, there is two major possible approaches:
      certain degree of flexibility.
 
 The second option would have to provide a way to store, at least, all fields from both Opentelemetry and Datadog Traces.
-If we consider the protobuf definiton for both Datadog and OpenTelemetry, it is clear that the OpenTelemetry from come
+If we consider the protobuf definition for both Datadog and OpenTelemetry, it is clear that the OpenTelemetry from come
 with extra structured fields that are not present in Datadog traces. However having a generic key/value container in
 virtually all traces formats can be used to store data that do not have a dedicated field in some format. As a reflexion
 basis the Datadog and OpenTelemetry are provided below, there is no hard semantic differences.