Concepts pages: copyedits for instrumentation pages (open-telemetry#4066

)

content/en/docs/concepts/instrumentation/_index.md

@@ -1,7 +1,6 @@
 ---
 title: Instrumentation
-description: >-
-  How OpenTelemetry instrumentations libraries and applications.
+description: How OpenTelemetry facilitates instrumentation
 aliases: [instrumenting]
 weight: 15
 ---
@@ -11,25 +10,24 @@ from the system's components must emit [traces](/docs/concepts/signals/traces/),
 [metrics](/docs/concepts/signals/metrics/), and
 [logs](/docs/concepts/signals/logs/).
 
-OpenTelemetry has two primary ways to instrument.
+Using OpenTelemetry, you can instrument your code in two primary ways:
 
 1. [Code-based solutions](/docs/concepts/instrumentation/code-based) via
-   official APIs and SDKs for eleven languages.
-2. [Zero-code solutions](/docs/concepts/instrumentation/zero-code/) that, when
-   installed, instrument libraries you use.
+   official [APIs and SDKs for most languages](/docs/languages/)
+2. [Zero-code solutions](/docs/concepts/instrumentation/zero-code/)
 
-Code-based solutions allow you to get rich telemetry from your application
-itself. They let you use the OpenTelemetry API to generate telemetry from your
-application, which acts as an essential complement to the telemetry generated by
-zero-code solutions.
+**Code-based** solutions allow you to get deeper insight and rich telemetry from
+your application itself. They let you use the OpenTelemetry API to generate
+telemetry from your application, which acts as an essential complement to the
+telemetry generated by zero-code solutions.
 
-The Zero-code solutions are great for getting started, or when you can't modify
+**Zero-code** solutions are great for getting started, or when you can't modify
 the application you need to get telemetry out of. They provide rich telemetry
 from libraries you use and/or the environment your application runs in. Another
 way to think of it is that they provide information about what's happening _at
 the edges_ of your application.
 
-It's generally recommended that you use both solutions when you can.
+You can use both solutions simultaneously.
 
 ## Additional OpenTelemetry Benefits
 

content/en/docs/concepts/instrumentation/code-based.md

@@ -1,10 +1,9 @@
 ---
 title: Code-based
-description: >-
-  Learn about the essential steps to instrument your code base.
+description: Learn the essential steps in setting up code-based instrumentation
 weight: 20
 aliases: [manual]
-cSpell:ignore: legitimatebusiness proxying
+cSpell:ignore: proxying
 ---
 
 ## Import the OpenTelemetry API and SDK
@@ -24,10 +23,10 @@ single default provider for these objects. You'll then get a tracer or meter
 instance from that provider, and give it a name and version. The name you choose
 here should identify what exactly is being instrumented -- if you're writing a
 library, for example, then you should name it after your library (for example
-`com.legitimatebusiness.myLibrary`) as this name will namespace all spans or
-metric events produced. It is also recommended that you supply a version string
-(i.e., `semver:1.0.0`) that corresponds to the current version of your library
-or service.
+`com.example.myLibrary`) as this name will namespace all spans or metric events
+produced. It is also recommended that you supply a version string (i.e.,
+`semver:1.0.0`) that corresponds to the current version of your library or
+service.
 
 ## Configure the OpenTelemetry SDK
 

content/en/docs/concepts/instrumentation/zero-code.md

@@ -2,7 +2,7 @@
 title: Zero-code
 description: >-
   Learn how to add observability to an application without the need to write
-  more code
+  code
 weight: 10
 aliases: [automatic]
 ---