This is a ridiculously overengineered greeting service! Its sole purpose is to create a greeting composed of a name and a message. The name will be one of the 10 most popular baby names in the USA in a particular year. The year will be chosen at random. The message will be chosen from a pre-canned list of 10 or so messages.
The system is composed of several services, each with a specific responsibility:
- frontend - This service acts as an API aggregation layer. It depends on the name service and the message service.
- name-service - This service returns a random name. It depends on the year service.
- year-service - This service returns a random year.
- message-service - This service returns a random message from a list.
Each service can be written in any language, and they should use a combination of instrumentation techniques. Some will be instrumented with a Honeycomb beeline and some with other standards, like OpenTelemetry. The idea is to use these to test compatibility between various types of services. The motivating use case is testing trace context header compatibility between Honeycomb and OpenTelemetry.
.NET
- frontend using Honeycomb.OpenTelemetry
- message-service using Honeycomb.OpenTelemetry
- name-service using OpenTelemetry
- year-service using OpenTelemetry
Elixir
- frontend using opentelemetry-erlang
- message using opentelemetry-erlang
- name using opentelemetry-erlang
- year using opentelemetry-erlang
Go
- frontend using opentelemetry-go
- message-service using beeline-go
- name-service using opentelemetry-go
- year-service using honeycomb-opentelemetry-go
Java
- frontend using opentelemetry-javaagent
- message-service using honeycomb-opentelemetry-javaagent
- name-service using honeycomb-opentelemetry-javaagent
- year-service using honeycomb-opentelemetry-skd
Node
- frontend using opentelemetry-js
- message-service using beeline-nodejs
- name-service using beeline-nodejs
- year-service using opentelemetry-js
Python
- frontend using beeline-python
- message-service using opentelemetry-python
- name-service using opentelemetry-python
- year-service using beeline-python
Ruby
- frontend using opentelemetry-ruby
- message-service using beeline-ruby
- name-service using beeline-ruby
- year-service using beeline-ruby
Web
- A web app instrumented using opentelemetry-js
Port and host names are hardcoded.
- Frontend: Port 7777
- Name: Port 8000
- Year: Port 6001
- Message: Port 9000
Check out DEVELOPING.md for some additional tips and language-specific details.
Each service reads its configuration from the environment. Specific environment variables:
HONEYCOMB_API_KEY
- Your honeycomb API keyOTEL_EXPORTER_OTLP_ENDPOINT=https://api.honeycomb.io
Some services use vanilla OTEL:
OTEL_EXPORTER_OTLP_HEADERS='x-honeycomb-team=api-key'
If configuring non-prod API endpoint:
OTEL_EXPORTER_OTLP_ENDPOINT=https://api.some.place
HONEYCOMB_API_ENDPOINT=https://api.some.place
If using Classic Honeycomb, you'll also need a dataset and must include in the OTEL headers:
HONEYCOMB_DATASET
- The name of the dataset you want to write toOTEL_EXPORTER_OTLP_HEADERS='x-honeycomb-team=api-key,x-honeycomb-dataset=greetings'
There is a Tiltfile
to run these services on a local host using https://tilt.dev/.
After installing Tilt, running tilt up
should spin up all of the services.
NOTE: you need to use tilt version 0.32.2+ otherwise you will get an error
Docker Compose service "frontend-java" has a relative build path: "./frontend"
This tiltfile utilizes docker and docker compose. You can verify they are installed first by checking docker version
and docker compose version
The default tilt setup runs the go services.
NOTE: if you cancel the tilt up
command, docker resources will remain running. If you then try to start up another set of services, you will get a port collision. Run tilt down
which will remove any resources started by tilt previously.
To run services in another supported language, add the language name after the tilt command:
tilt up node
List of supported languages
go
py
rb
java
dotnet
node
elixir
It's also possible to run a combination of services in different languages, for example the following command would run each specific service mentioned along with the required services (collector, redis, curl greeting)
tilt up frontend-node message-go name-py year-rb
To configure a common set of services that are specific to ongoing development, or to override the default option of running all services in go, add a file tilt_config.json
and specify a group or set of services.
This file is ignored by git so it can be developer specific and allows running tilt up
without having to specify further arguments.
Example tilt_config.json
to override go as the default service
{
"to-run": ["node"]
}
Example tilt_config.json
to override the default with multiple services
{
"to-run": ["frontend-node", "message-go", "name-py", "year-rb"]
}
Once running, curl localhost:7777/greeting
to get a greeting and a trace!
ctrl+c to kill the session, and tilt down
to spin down all services.
To run the browser app inside of /web
run
tilt up web node
This will start up the browser app as well as all node backend services. The browser app makes requests to http://localhost:7777/greeting
so there has to be a set of backend services running. It could also be any one of our other supported languages (e.g. py
, go
etc.)