Add Collector icons to documentation (#393)

* Add Collector icons to documentation

Also add reference architecture information.

* Fix links

content/en/docs/_index.md

@@ -24,10 +24,29 @@ menu:
     weight: 10
 ---
 
-> For documentation and guides on specific languages or the Collector, please
-follow the links in the navigation bar.
-
 OpenTelemetry is a set of APIs, SDKs, tooling and integrations that are
 designed for the creation and management of _telemetry data_ such as traces,
-metrics, and logs. This documentation page is intended to broadly cover key
-terms, concepts, and instructions on how to use OpenTelemetry in your software.
+metrics, and logs. The OpenTelemetry documentation is intended to broadly cover
+key terms, concepts, and instructions on how to use OpenTelemetry in your
+software.
+
+<img src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/Reference_Architecture.svg"></img>
+
+OpenTelemetry provides an implementation of all of its components as well as a
+reference architecture. The project is flexible and extensible to support a
+broad range of open-source and commercial solutions as well as end-user needs.
+
+For greenfield environments, the OpenTelemetry Collector should be deployed as
+an agent on each host within an environment and configured to send telemetry
+data to the user's desired back-end(s). OpenTelemetry instrumentation libraries
+should then be added to each application. By default, these instrumentation
+libraries are configured to export their data to a locally running Collector.
+Optionally, a pool of Collector instances can be deployed in a region.
+
+For brownfield environments, the Collector supports many popular open-source
+wire formats including Jaeger, Prometheus, and Fluent Bit. The Collector can
+serve as a bridge for end-users who either desire to leverage OpenTelemetry or
+eventually move to the open standards OpenTelemetry supports.
+
+> For documentation and guides on language-specific instrumentation or the
+> Collector, please follow the links in the navigation bar.

content/en/docs/collector/_index.md

@@ -6,12 +6,14 @@ description: >
   Vendor-agnostic way to receive, process and export telemetry data
 ---
 
+<img src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/Otel_Collector.svg"></img>
+
 The OpenTelemetry Collector offers a vendor-agnostic implementation on how to
 receive, process and export telemetry data. It removes the need to run,
 operate, and maintain multiple agents/collectors in order to support
-open-source observability data formats (e.g. Jaeger, Prometheus, etc.) sending
-to one or more open-source or commercial back-ends. The Collector is the
-default location instrumentation libraries export their telemetry data.
+open-source observability data formats (e.g. Jaeger, Prometheus, Fluent Bit,
+etc.) sending to one or more open-source or commercial back-ends. The Collector
+is the default location instrumentation libraries export their telemetry data.
 
 Objectives:
 

content/en/docs/collector/configuration.md

@@ -14,9 +14,12 @@ Please be sure to review the following documentation:
 
 The Collector consists of three components that access telemetry data:
 
-- [Receivers](#receivers)
-- [Processors](#processors)
-- [Exporters](#exporters)
+- <img width="32" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Receivers.svg"></img>
+[Receivers](#receivers)
+- <img width="32" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Processors.svg"></img>
+[Processors](#processors)
+- <img width="32" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Exporters.svg"></img>
+[Exporters](#exporters)
 
 These components once configured must be enabled via pipelines within the
 [service](#service) section.
@@ -114,7 +117,7 @@ service:
       exporters: [otlp]
 ```
 
-## Receivers
+## <a name="receivers"></a><img width="35" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Receivers.svg"></img> Receivers
 
 A receiver, which can be push or pull based, is how data gets into the
 Collector. Receivers may support one or more [data
@@ -189,7 +192,7 @@ receivers:
   zipkin:
 ```
 
-## Processors
+## <a name="processors"></a><img width="35" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Processors.svg"></img> Processors
 
 Processors are run on data between being received and being exported.
 Processors are optional though [some are
@@ -267,7 +270,7 @@ processors:
       separator: "::"
 ```
 
-## Exporters
+## <a name="exporters"></a><img width="35" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Exporters.svg"></img> Exporters
 
 An exporter, which can be push or pull based, is how you send data to one or
 more backends/destinations. Exporters may support one or more [data

content/en/docs/concepts/data-collection.md

@@ -31,9 +31,12 @@ documentation](/docs/collector/getting-started).
 
 The Collector is made up of the following components:
 
-- `receivers`: How to get data into the Collector; these can be push or pull based
-- `processors`: What to do with received data
-- `exporters`: Where to send received data; these can be push or pull based
+- <img width="32" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Receivers.svg"></img>
+`receivers`: How to get data into the Collector; these can be push or pull based
+- <img width="32" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Processors.svg"></img>
+`processors`: What to do with received data
+- <img width="32" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Exporters.svg"></img>
+`exporters`: Where to send received data; these can be push or pull based
 
 These components are enabled through `pipelines`. Multiple instances of
 components as well as pipelines can be defined via YAML configuration.