Skip to main content
You are one engineer with one service and you want this working today. No rollout plan, no Kubernetes, no committee.
About an hour. Ten minutes of it is proving the pipeline works; the rest is instrumenting your service and checking you got it right.

​
1. Prove the path before writing any code

Run the Quickstart. Ten minutes, curl only, one log record.
Do not skip this because it looks trivial. It separates “my instrumentation is wrong” from “my network, key or endpoint is wrong”, and those two look identical from inside your application. Everything after this point is your code.

​
2. Instrument your service

Auto-instrumentation, which needs no code changes in most languages — frameworks, HTTP clients and database drivers are covered automatically.
Language-specific setup is on Instrument your application.
OTEL_EXPORTER_OTLP_ENDPOINT is the base URL. The SDK appends /v1/traces itself, so an endpoint that already ends in a signal path produces a 404 that reads as though the endpoint were wrong.

​
3. Generate traffic and look

Exercise your service, wait about ten seconds, then check three things:
1

Services

Your service is listed, under the name you chose. If you see unknown_service, OTEL_SERVICE_NAME did not reach the process.
2

Traces

Open one. You should see a span for the inbound request and a child span per outbound call or query.
3

Logs

Search for your service:
Ten seconds, not instantly. Ingest acknowledges before storage, and a batching consumer flushes at 50,000 rows or five seconds. On a quiet development account you are always waiting out the five seconds.

​
4. Connect your logs to your traces

This is the step that makes the tool genuinely useful, and the one most people skip.
A print() or a bare file logger produces log lines that are correct, searchable, and permanently disconnected from every trace. You will not get an error — you will get an empty “logs for this span” panel and assume the feature is broken.Use your language’s OpenTelemetry logging bridge. See Sending logs as well as traces.
Once connected: click a slow span, see the log lines written during it. That is the whole value proposition, and it is one configuration change away.

​
5. Add spans where you actually have questions

Auto-instrumentation stops at your framework’s boundary. If the interesting work is inside a function, add a span around it — but not around everything.
Do not instrument every function. A span per function produces traces hundreds of spans deep that nobody reads and that cost real money to store.A span is worth it when the operation could be slow, could fail on its own, or is a unit you would want timed separately. See Manual instrumentation.

​
Working locally

Point your local service at aiAxonIQ directly. It works, and it is the fastest way to iterate on instrumentation.
Tag it as development. Set deployment.environment=development so local runs do not sit alongside production in every chart and trip every alert. This is one environment variable and it saves an afternoon of confusion later.

​
Troubleshooting, in likelihood order

The full version is on Troubleshooting.

​
When you are ready for more

Take it to your team

The full journey: environments, alerting, dashboards, roles.

Searching logs

The query syntax, including the numeric comparisons.

API reference

Everything the product does, programmatically.