Fixing typos (open-telemetry#1941)

Author: deining

Diff for: README.md

@@ -24,7 +24,7 @@ file in `/content/en/registry` for your project. You can find a template in
 
 ## Submitting a blog post
 
-You can submit a blog post either by forking this repository and writting it
+You can submit a blog post either by forking this repository and writing it
 locally or by using the GitHub UI. In both cases we ask you to follow the
 instructions provided by the [blog post template](archetypes/blog.md).
 

Diff for: content/en/blog/2022/debug-otel-with-otel/index.md

@@ -31,7 +31,7 @@ people how to instrument nginx with OpenTelemetry, but also how a distributed
 trace crossing the webserver would look like.
 
 While Jaeger showed us a trace flowing from the frontend application down to the
-nginx, the connection between nginx and python app was not visibile: we had two
+nginx, the connection between nginx and python app was not visible: we had two
 disconnected traces.
 
 This came as a surprise, because in a prior test with a Java application as
@@ -218,7 +218,7 @@ SDK, it looks like that Java is flexible in taking a `traceparent` with multiple
 values, even though such format is invalid per the W3C Trace Context specification. 
 So propagation from nginx to the Java service worked, while in contrast,
 Python (and other languages) do not provide that flexibility and propagation
-from nginx to the downstream service silenty fails.
+from nginx to the downstream service silently fails.
 
 Note, that we are not suggesting that the other languages should have the same
 flexibility as Java has with reading `traceparent` or vice-versa: the bug lives

Diff for: content/en/blog/2022/dotnet-instrumentation-first-beta.md

@@ -17,7 +17,7 @@ ASP.NET Core requests, you need to use the ASP.NET Core instrumentation package
 and initialize it with the OpenTelemetry SDK.
 
 Now, developers can use [automatic instrumentation](/docs/reference/specification/glossary/#automatic-instrumentation)
-to initalize [signal](/docs/reference/specification/glossary/#signals) providers
+to initialize [signal](/docs/reference/specification/glossary/#signals) providers
 and generate telemetry data for supported [instrumented libraries](/docs/reference/specification/glossary/#instrumented-library).
 This approach has several benefits:
 

Diff for: content/en/blog/2022/k8s-otel-expose/index.md

@@ -31,7 +31,7 @@ most used are probably:
 3. HTTP Basic Authentication
 
 This article focuses on **HTTP Basic Authentication** for simplicity. It is intended to show how
-a secure setup can be operated without key management or further thrid party services.
+a secure setup can be operated without key management or further third party services.
 
 
 For more information about TLS configuration I would like to refer to the article
@@ -116,7 +116,7 @@ metadata:
 ```
 
 In the next step we create an OpenTelemetry Collector using the `OpenTelemetryCollector`
-CRD. The most important entries are `mode`, `image` and the configured basicauth extention.
+CRD. The most important entries are `mode`, `image` and the configured basicauth extension.
 In the manifest below the mode `deployment` was chosen to guarantee that at least one
 collector pod is available for processing incoming information. Furthermore the default
 collector image was overwritten with the [contrib version](https://github.com/open-telemetry/opentelemetry-collector-contrib#opentelemetry-collector-contrib).
@@ -240,7 +240,7 @@ spec:
 
 In order to be able to determine the origin of the transmitted traces, the
 span-tags are extended by identifying metadata with the help of the
-[k8sattributes proccessor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.58.0/processor/k8sattributesprocessor).
+[k8sattributes processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.58.0/processor/k8sattributesprocessor).
 K8sattribute processor is available in the OpenTelemetry Collector contrib
 version. In the next step we create a service account with the necessary permissions.
 If you want to learn more about the k8s metadata, you can read this post
@@ -282,7 +282,7 @@ metadata:
 Lets have a quick look on the most important edge collector settings. A `daemonset` is
 used as deployment mode to ensure that one collector instance per node exists. The `basicauth`
 extension contains `username` and `password` to identify itself to the exposed remote collector.
-More container and node specific information are provided by the `k8sattributes` proccesor via
+More container and node specific information are provided by the `k8sattributes` processor via
 the kubernetes [kubernetes downward-api](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/).
 What is not covered is the cluster availability zone and the cluster name. To be able to
 identify the reported spans later, they are inserted manually with the help of the `resource`

Diff for: content/en/docs/collector/configuration.md

@@ -340,7 +340,7 @@ exporters:
   # Data sources: metrics
   prometheusremotewrite:
     endpoint: "http://some.url:9411/api/prom/push"
-    # For offical Prometheus (e.g. running via Docker)
+    # For official Prometheus (e.g. running via Docker)
     # endpoint: 'http://prometheus:9090/api/v1/write'
     # tls:
     #   insecure: true

Diff for: content/en/docs/instrumentation/cpp/manual.md

@@ -104,7 +104,7 @@ context to remote services using the W3C Trace Context HTTP headers.
 
 ## Metrics
 
-### Initalize Exporter and Reader
+### Initialize Exporter and Reader
 
 Initialize an exporter and a reader. In this case, we initialize an OStream Exporter which will print to stdout by default. The reader periodically collects metrics from the Aggregation Store and exports them.
 
@@ -114,7 +114,7 @@ std::unique_ptr<opentelemetry::sdk::metrics::MetricReader> reader{
     new opentelemetry::sdk::metrics::PeriodicExportingMetricReader(std::move(exporter), options)};
 ```
 
-### Initalize Meter Provider
+### Initialize Meter Provider
 
 Initialize a MeterProvider and add the reader. We will use this to obtain Meter objects in the future.
 
@@ -149,7 +149,7 @@ histogram_counter->Record(val, labelkv);
 
 ### Create Observable Counter
 
-Create a Observable Counter Instrument from the Meter, and add a callback. The callbackwould be used to record the measurement during metrics collection. Ensure to keep the Instrument object active for the lifetime of collection.
+Create a Observable Counter Instrument from the Meter, and add a callback. The callback would be used to record the measurement during metrics collection. Ensure to keep the Instrument object active for the lifetime of collection.
 
 ```cpp
 auto meter = provider->GetMeter(name, "1.2.0");

Diff for: content/en/docs/instrumentation/js/instrumentation.md

@@ -120,7 +120,7 @@ provider.register();
 ```
 
 You'll need to bundle this file with your web application to be able to use
-tracing throughought the rest of your web application.
+tracing throughout the rest of your web application.
 
 ### Picking the right span processor
 
@@ -442,7 +442,7 @@ SDK. The biggest difference, aside from initialization code, is that you'll have
 to manually set spans as active in the current context to be able to create
 nested spans.
 
-### Initilizing tracing with `sdk-trace-base`
+### Initializing tracing with `sdk-trace-base`
 
 Initializing tracing is similar to how you'd do it with Node.js or the Web SDK.
 

Diff for: content/en/docs/instrumentation/net/automatic.md

@@ -5,7 +5,7 @@ weight: 3
 ---
 
 You can use [automatic instrumentation](/docs/reference/specification/glossary/#automatic-instrumentation)
-to initalize [signal](/docs/reference/specification/glossary/#signals) providers
+to initialize [signal](/docs/reference/specification/glossary/#signals) providers
 and generate telemetry data for supported [instrumented libraries](/docs/reference/specification/glossary/#instrumented-library)
 without modifying the application's source code.
 

Diff for: content/en/docs/instrumentation/swift/manual.md

@@ -19,7 +19,7 @@ import OpenTelemetrySdk
 import OpenTelemetryProtocolExporter
 
 
-// initalize the OtlpTraceExporter
+// initialize the OtlpTraceExporter
 let otlpConfiguration = OtlpConfiguration(timeout: OtlpConfiguration.DefaultTimeoutInterval)
 
 let grpcChannel = ClientConnection.usingPlatformAppropriateTLS(for: MultiThreadedEventLoopGroup(numberOfThreads:1))
@@ -125,7 +125,7 @@ Sometimes it's useful to do something with the current/active span. Here's how t
 ### Span Attributes
 
 Spans can also be annotated with additional attributes. All spans will be automatically annotated with the `Resource` attributes attached to the tracer provider.
-The Opentelementry-swift sdk already provides instrumentation of common attributes in the `SDKResourceExtension` instrumentation.
+The Opentelemetry-swift sdk already provides instrumentation of common attributes in the `SDKResourceExtension` instrumentation.
 In this example a span for a network request capturing details about that request using existing [semantic conventions](/docs/reference/specification/trace/semantic_conventions/).
 
 ```swift
@@ -160,7 +160,7 @@ func myFunction() {
       span.status = .error(description: "something bad happened")
       return 
   }
-  // do somthing 
+  // do something 
 }
 ```
 

Diff for: content/en/registry/collector-receiver-httpcheck.md

@@ -9,7 +9,7 @@ tags:
     - collector
 repo: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/httpcheckreceiver
 license: Apache 2.0
-description: The HTTP Check Receiver can be used for synthethic checks against HTTP endpoints. This receiver will make a request to the specified `endpoint` using the
+description: The HTTP Check Receiver can be used for synthetic checks against HTTP endpoints. This receiver will make a request to the specified `endpoint` using the
 authors: OpenTelemetry Authors
 otVersion: latest
 ---