example

Example

This example instruments a simple HTTP server-client application.

The application is configured to send spans and metrics to a local instance of the OpenTelemetry Collector, which propagates them to Splunk Observability Cloud.

Prerequisites

• Docker
• Docker Compose

Usage

OpenTelmemtry Collector

Run the OpenTelemetry Collector and Jaeger instance:

SPLUNK_ACCESS_TOKEN=<access_token> docker compose up -d

The value for SPLUNK_ACCESS_TOKEN can be found here. Reference: docs.

Run the instrumented application:

export OTEL_SERVICE_NAME="splunk-otel-go-example"
export OTEL_RESOURCE_ATTRIBUTES="deployment.environment=$(whoami)"
go run .

You can find the collected telemetry in:

• OpenTelemetry Collector output
• Jaeger: http://localhost:16686/search
• Prometheus scrape handler: http://localhost:8889/metrics
• Splunk Observability Cloud: https://app.signalfx.com/#/apm?environments=YOURUSERNAME

  Note: Processing might take some time.

Cleanup:

docker compose down

Splunk Distribution of the OpenTelemetry Collector

Run the Splunk Distribution of the OpenTelemetry Collector instance:

SPLUNK_ACCESS_TOKEN=<access_token> docker compose -f docker-compose-splunk.yaml up -d

The value for SPLUNK_ACCESS_TOKEN can be found here. Reference: docs.

Run the instrumented application:

export OTEL_SERVICE_NAME="splunk-otel-go-example"
export OTEL_RESOURCE_ATTRIBUTES="deployment.environment=$(whoami)"
go run .

You can find the collected telemetry in:

• Splunk Observability Cloud: https://app.signalfx.com/#/apm?environments=YOURUSERNAME

  Note: Processing might take some time.

Cleanup:

docker compose -f docker-compose-splunk.yaml down

Direct to Splunk Observability Cloud

Run the instrumented application:

export OTEL_SERVICE_NAME="splunk-otel-go-example"
export OTEL_RESOURCE_ATTRIBUTES="deployment.environment=$(whoami)"
SPLUNK_REALM=<realm> SPLUNK_ACCESS_TOKEN=<access_token> go run .

You can find the collected telemetry in:

• Splunk Observability Cloud: https://app.signalfx.com/#/apm?environments=YOURUSERNAME

  Note: Processing might take some time.

FIPS mode - Linux

Note

As BoringSSL is FIPS 140-2 certified, an application built using GOEXPERIMENT=boringcrypto is more likely to be FIPS 140-2 compliant. Yet Google does not provide any liability about the suitability of this code in relation to the FIPS 140-2 standard. More information can be found here.

Run the instrumented applications using boringcrypto. For example:

CGO_ENABLED=1 GOEXPERIMENT=boringcrypto go run .

FIPS mode - Windows

Note

Microsoft maintains a fork of Go that is configurable to use a FIPS 140-2 compliant cryptography. All Go applications running on Windows and intended to be FIPS 140-2 compliant, should be built using this fork. More information can be found here.

Build the instrumented application using the container image containing the Microsoft build of Go. Make sure to set GOOS=windows GOEXPERIMENT=cngcrypto and add the requirefips Go build tag. For example, using Git Bash on Windows in the root of the repository:

MSYS_NO_PATHCONV=1 docker run --rm -w /app -v $(pwd):/app mcr.microsoft.com/oss/go/microsoft/golang sh -c \
"cd example && GOOS=windows GOEXPERIMENT=cngcrypto go build -tags=requirefips"

Before running the application make sure to enable the Windows FIPS policy. For testing purposes, Windows FIPS policy can be enabled via the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy dword value Enabled set to 1.