The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)
• Update the centralized tracing doc

Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/tree/main/src/cartservice

Objective

Highlight the integration between OpenTelemetry and the greater cloud-native ecosystem by supporting Kubernetes.

The following are a non-exhaustive list of requirements for this --

• Minikube/local k8s as the minimum requirement for installation
• Self-deployment of services via ArgoCD
• OpenTelemetry deployment via OpenTelemetry Operator
• Kubernetes API Server Tracing enabled
• Kubernetes Metrics scraped by Collector
• Kubernetes resource detectors on Collector (and associated telemetry enhancement)

This issue is to track the addition of the feature flag service to the demo.

PR #26 has been opened with a proposed GRPC API for the service.

Objective

To allow for dynamic modification of service behavior through feature flags, and to demonstrate OpenTelemetry in another language, create a feature flag service in Erlang+Elixir/Phoenix.

• UI/API to perform CRUD operations on flags.
• UI to display flag state.
• API to query flag state.
• Flags should be persistent through restarts (stateful storage).

Other services in the application should be able to register with this service and query it for the state of any feature flags defined in their code.

If feasible, it would be good to see if we can align with OpenFeature for definitions/semantic conventions here.

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
  • Interprocess context propagation is demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)

Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/recommendationservice/README.md

As OpenTelemetry Logging has not fully stabilized, this list of requirements may change in future releases.

• Log events in existing services should be converted to span events where appropriate (i.e., the event occurs within a transaction)
• Logs should be emitted with OpenTelemetry resources and context for correlation where possible.
• Logs should be scraped by OpenTelemetry Collectors for further filtering and processing.

Objective

Re-implement the 'shippingservice' in Rust.

This should be a drop-in replacement.

Objective

Create an 'admin service' written in PHP for the web store.

The following features should be supported:

• Authentication for 'admin users'
• UI for CRUD operations on items in the product catalog.
• API for CRUD operations on items in the product catalog.

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
  • Interprocess context propagation is demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)

Referencing: #42

Dependent on this item: #34

The following are requirements for metrics in the project. Not all services will meet all requirements.

• Service metrics should not be duplicative of trace-derived metrics.
• Services should emit multiple business metrics where appropriate.
• Services should emit trace exemplars for their metrics.
• Services should use push metrics where possible.
• Services should explicitly read baggage where needed.
• Collectors should perform metric transforms to normalize resource and service metrics.

Referencing issue: #43

The docker compose build will build all services on all platforms

• Create a docker-compose.yml at the root of the repository
• Adapt all services Dockerfile files
  • Remove duplication of demo.proto file
  • Compile protobuf source files during build
• Testing

References

• https://docs.docker.com/compose/

Currently the "architecture diagram" is a PNG file https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/b28cb38af2f1f1273f92a321d713e0f7706536b6/docs/img/architecture-diagram.png.

I imagine we'll keep improving the architecture, and PNG is hard for change management / comment. I propose that we use mermaid. In OpenTelemetry .NET and C++ I've seen good results open-telemetry/opentelemetry-dotnet#2952.

If folks like the idea, I can take this work.

This has been discussed during the OpenTelemetry Demo Application SIG Meeting.

Here are the steps that we will be following:

• Create branch online-boutique
• Copy the code as-is from opentelemetry-microservices-demo
• Make minimum changes to clean up unnecessary parts (istio, cloudbuild and some docs)
• Update changelog
• Merge branch into main
• Delete branch online-boutique

FYI: @open-telemetry/demo-webstore-maintainers

We have it in the spec repo and many other languages SIGs.

e.g. https://github.com/open-telemetry/opentelemetry-specification/discussions

The following are requirements for metrics in the project. Not all services will meet all requirements.

• Service metrics should not be duplicative of trace-derived metrics.
• Services should emit multiple business metrics where appropriate.
• Services should emit trace exemplars for their metrics.
• Services should use push metrics where possible.
• Services should explicitly read baggage where needed.
• Collectors should perform metric transforms to normalize resource and service metrics.

Referencing issue: #43

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements.

• Automatic Instrumentation is being used where appropriate.
• Automatic instrumentation is being injected through the OpenTelemetry Operator.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
  • Interprocess context propagation is demonstrated.
  • Intraprocess context propagation is demonstrated.
• Trace links are being demonstrated in appropriate places (security boundary, fan-in/fan-out)
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)

grpc & http communication should be labeled between the different services as an enhancement to the initial graph like http is used at the top.

#27

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)
• Update the centralized tracing doc

Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/paymentservice/README.md

I want to see how the span header issues traceid through kafka redis.

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)
• Update the centralized tracing doc

Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/emailservice/README.md

Ruby dependent on this item: #37

The following are requirements for metrics in the project. Not all services will meet all requirements.

• Service metrics should not be duplicative of trace-derived metrics.
• Services should emit multiple business metrics where appropriate.
• Services should emit trace exemplars for their metrics.
• Services should use push metrics where possible.
• Services should explicitly read baggage where needed.
• Collectors should perform metric transforms to normalize resource and service metrics.

Referencing issue: #43

As OpenTelemetry Logging has not fully stabilized, this list of requirements may change in future releases.

• Log events in existing services should be converted to span events where appropriate (i.e., the event occurs within a transaction)
• Logs should be emitted with OpenTelemetry resources and context for correlation where possible.
• Logs should be scraped by OpenTelemetry Collectors for further filtering and processing.

Referencing issue: #44

Service: Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/tree/main/src/cartservice

The following are requirements for metrics in the project. Not all services will meet all requirements.

• Service metrics should not be duplicative of trace-derived metrics.
• Services should emit multiple business metrics where appropriate.
• Services should emit trace exemplars for their metrics.
• Services should use push metrics where possible.
• Services should explicitly read baggage where needed.
• Collectors should perform metric transforms to normalize resource and service metrics.

Referencing issue: #43

As OpenTelemetry Logging has not fully stabilized, this list of requirements may change in future releases.

• Log events in existing services should be converted to span events where appropriate (i.e., the event occurs within a transaction)
• Logs should be emitted with OpenTelemetry resources and context for correlation where possible.
• Logs should be scraped by OpenTelemetry Collectors for further filtering and processing.

Referencing issue: #44

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/recommendationservice/README.md

As OpenTelemetry Logging has not fully stabilized, this list of requirements may change in future releases.

• Log events in existing services should be converted to span events where appropriate (i.e., the event occurs within a transaction)
• Logs should be emitted with OpenTelemetry resources and context for correlation where possible.
• Logs should be scraped by OpenTelemetry Collectors for further filtering and processing.

Referencing issue: #44

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/emailservice/README.md

Ruby dependent on this item: #37

The following are requirements for metrics in the project. Not all services will meet all requirements.

• Service metrics should not be duplicative of trace-derived metrics.
• Services should emit multiple business metrics where appropriate.
• Services should emit trace exemplars for their metrics.
• Services should use push metrics where possible.
• Services should explicitly read baggage where needed.
• Collectors should perform metric transforms to normalize resource and service metrics.

Referencing issue: #43

The following are requirements for metrics in the project. Not all services will meet all requirements.

• Service metrics should not be duplicative of trace-derived metrics.
• Services should emit multiple business metrics where appropriate.
• Services should emit trace exemplars for their metrics.
• Services should use push metrics where possible.
• Services should explicitly read baggage where needed.
• Collectors should perform metric transforms to normalize resource and service metrics.

Referencing issue: #43

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)
• Update the centralized tracing doc
  Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/productcatalogservice/README.md

README.md

See the Development Principles doc for more information.

our repo no /docs/development-principles.md

https://github.com/GoogleCloudPlatform/microservices-demo/blob/main/docs/development-principles.md

Objective

To demonstrate OTel integration w/storage layers, we need some stateful storage in the application. To this end, we should create some kind of abstraction to store and get products for the product catalog.

This service will be written to by the 'adminservice' and read by the 'productcatalog'.

The two basic storage types we should support are DB and blob-based storage.

#86 (comment)

It seems the current CI job doesn't prevent broken links. At minimum we should have gated CI job to prevent any relative link that is broken. Whether we should check absolute links or not is still to be decided due to the fragile nature.

One option is docfx, as been used in https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/.github/workflows/docfx.yml.
Another option is https://github.com/open-telemetry/opentelemetry-specification/blob/9abbdd39d0b35f635f833f072013431da419894e/.github/workflows/checks.yaml#L36, which can be configured to cover relative/absolute/both.

Objective

Re-write the emailservice to Ruby.

This should be a drop-in replacement.

The adservice fails to build at the RUN ./gradlew downloadRepos step

You must run

• ./gradlew installDist from /src/adservice/
• ./gradlew wrapper --gradle-version 7.4.2

Maybe only one of the above commands is necessary...

Then the following command should work:
docker compose build cartservice

Proposed Fix:

Make the docker compose up the only required command to run the whole project, so this might be simply upgrading the jar file: /src/adservice/gradle/wrapper/gradle-wrapper.jar to the 7.4.2 version done in the command found above.

The other changes to /src/adservice/gradle/wrapper/gradle-wrapper.properties and /src/adservice/gradlew are only related to line endings:

Currently the screenshots look bad under dark theme

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• #151
  • #152
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
  • Interprocess context propagation is demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)

Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/adservice/README.md

As OpenTelemetry Logging has not fully stabilized, this list of requirements may change in future releases.

• Log events in existing services should be converted to span events where appropriate (i.e., the event occurs within a transaction)
• Logs should be emitted with OpenTelemetry resources and context for correlation where possible.
• Logs should be scraped by OpenTelemetry Collectors for further filtering and processing.

Referencing issue: #44

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/adservice/README.md

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate. - not appropriate
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
  • Interprocess context propagation is demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)

Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/tree/main/src/frontend

Objective

Re-write the 'currencyservice' in C++.

This should be a drop-in replacement.

Objective

Bring out a bit of the project's personality by rebranding from 'Online Boutique' to something else. Maybe 'Astronomy Shop'? :)

• Update frontend logo
• Update product key art/product names
• Rebrand colors/fonts to align with opentelemetry.io styles

Feature Request

Save a copy of grpc_health_probe binary to the repository. 10MB.

Is your feature request related to a problem?

Each of our services downloads this health probe (and will soon use with Dockerfile HEALTHCHECK)) using wget.
Example: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/adservice/Dockerfile#L35

Describe the solution you'd like:

Instead of downloading each time which a version has to be specified in each Dockerfile or possibly one main GRPC_HEALTH_PROBE_VERSION value in the .env file that we'd have to add to each service's environment section in the compose.yml file, we simply copy the file from /bin/ to the docker image.

Pros:

• Don't need to install wget in each service's build
• No external dependencies (network)
• Don't have to download 10MB file each new build (around 10 times), some issues have been seen with this command
• Simplifies the task of using the same version of the health probe
• Less boilerplate code

Cons:

• Checking in a binary is usually considered a no-no
• Git repository size increases (from 20MB to 30MB)

Describe alternatives you've considered.

If the Docker compose command is able to download this binary and it be copied to each image during the build process could alleviate most of the network download required from 100MB total to 10MB total. However, each clean install will still need network access to get this file, so the offline-friendly approach of including the binary to the repository seems worthwhile.

The following are requirements for metrics in the project. Not all services will meet all requirements.

• Service metrics should not be duplicative of trace-derived metrics.
• Services should emit multiple business metrics where appropriate.
• Services should emit trace exemplars for their metrics.
• Services should use push metrics where possible.
• Services should explicitly read baggage where needed.
• Collectors should perform metric transforms to normalize resource and service metrics.

Question

Hi,
I've given a rough preview of the technology stack used in the webstore demo, and I noticed the grpc framework is involved.
But, from my point of view, the content of the Java technology stack involves less, especially the more popular springboot/springcloud.

Do we have a plan on this?

BTW, I can participate in this part of the enhancement. :-P

Use Github Discussions.

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)
• Update the centralized tracing doc
  Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/checkoutservice/README.md

The following are requirements for metrics in the project. Not all services will meet all requirements.

• Service metrics should not be duplicative of trace-derived metrics.
• Services should emit multiple business metrics where appropriate.
• Services should emit trace exemplars for their metrics.
• Services should use push metrics where possible.
• Services should explicitly read baggage where needed.
• Collectors should perform metric transforms to normalize resource and service metrics.

Referencing issue: #43

The local build time from docker compose is slow. To improve the build time we can use cache_from in the docker compose file.

This item is dependent on: #78

The most recent build of the community demo should be available for download on Docker Hub & have automated deployment from the repo.

The community demo should be posted by the community "otel" user on the docker hub.

• Define image_name image_tag format
• Setup CI workflow to build the image
• Setup CI workflow to push image to GitHub package (via GitHub action)
• docker hub credentials
• push image to docker hub (via GitHub action)

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)
• Update the centralized tracing doc

Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/currencyservice/README.md

C++ dependent on this item: #36

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)
• Update the centralized tracing doc

Referencing: #42

Dependent on this item: #40

The following are requirements for metrics in the project. Not all services will meet all requirements.

• Service metrics should not be duplicative of trace-derived metrics.
• Services should emit multiple business metrics where appropriate.
• Services should emit trace exemplars for their metrics.
• Services should use push metrics where possible.
• Services should explicitly read baggage where needed.
• Collectors should perform metric transforms to normalize resource and service metrics.

Referencing issue: #43

The following is a list of requirements that we need to evaluate before declaring v1 for trace telemetry. These requirements are across the entire application; Not all services will meet all requirements. Determine the relevant features for this service.

• Automatic Instrumentation is being used where appropriate.
• Library instrumentation is being used if automatic instrumentation is unavailable.
• Services extend automatic instrumentation.
  • New attributes/events attached to existing spans.
  • New spans are being created from existing spans.
• Automatic and Manual Context Propagation are being demonstrated.
• Telemetry is not being sampled upfront.
• Telemetry is not being filtered upfront.
• Baggage is being set and read appropriately (i.e., baggage must be explicitly set as attributes on spans)
• Update the centralized tracing doc

Referencing: #42

Service: https://github.com/open-telemetry/opentelemetry-demo-webstore/blob/main/src/shippingservice/README.md

Rust dependent on this item: #35