Skip to main content
For a team using aiAxonIQ Cloud with services running on your own infrastructure. This is the default path.
Roughly an afternoon to something useful, spread over a week to a team that opens it daily. The sequence below is ordered to avoid rework — steps 2 and 3 in particular are cheap now and expensive to change once data has accumulated.

​
Day one

1

Accept your invitation and sign in

You become the Owner of your organization. Invitations expire after seven days — see Create your account.
2

Decide how you separate environments

Before sending anything. A deployment.environment resource attribute in one organization is what most teams want; a second organization is the answer only when the requirement is access control.Changing your mind later means re-tagging everything and losing continuity in every chart. See Organizations and multi-tenancy.
3

Agree service names

Ten minutes with your team, and it sets the vocabulary of every dashboard and alert you write afterwards. Use the name people say out loud, keep it identical across environments, and never encode the instance.See Resource attributes.
4

Create a license key and prove the path

Run the Quickstart — ten minutes with curl. It proves network, credential, ingest and query before any collector or SDK is involved, so anything that fails afterwards is your instrumentation rather than your setup.
5

Install a Collector

Not an SDK first. A Collector gives you host and container telemetry immediately, changes nothing in your applications, and becomes the single place you later add filtering, redaction and sampling.Docker · Docker Compose · Linux · Kubernetes
6

Instrument one service

One, not all of them. Auto-instrumentation, with OTEL_SERVICE_NAME and deployment.environment set. Confirm its traces, its logs and its service-map edges all look right before repeating the pattern.See Instrument your application.

​
Week one

1

Instrument the rest of the path

Follow one real request end to end and instrument every service it touches. A complete trace across five services is worth far more than partial coverage of twenty.
2

Check your traces actually join

Open a trace and confirm it spans every service you expect. A hole means context propagation broke or sampling is inconsistent — see Traces with a hole in them.
3

Set up alerting that will actually fire

Start with two or three rules, not twenty. Include one absence rule — it is the one that catches a crashed exporter, which no threshold on the data itself can detect.Test every rule after saving it. A rule saved with an unimplemented comparator is created without complaint and never fires. See Alerting.
4

Add a synthetic check on your front door

Everything else only exists if your code ran. A synthetic check tells you whether users can reach you at all. See Synthetic monitoring.
5

Build one dashboard people will open

Start from a template and cut it down. A dashboard with six panels that everyone reads beats forty nobody does. See Dashboards.

​
Month one

Not everyone needs Admin. Viewer for most people, Editor for whoever maintains dashboards and alerts, Auditor for a compliance reviewer who must not be able to change anything. See Roles and permissions.
Settings → Usage, in the first month rather than the third. Exceeding a volume allowance does not stop your ingest, so you will not be warned by a failure — see Plan limits.
Drop health-check traffic at the Collector, raise log levels in noisy services, and check no metric label carries a user or request id. In that order — the first is usually the largest and costs you nothing you read.See Reducing what you store.
On your most important user-facing path. Accept a suggestion rather than inventing a number, and alert on burn rate rather than on breach. See Service level objectives.
The knowledge base answers questions from your documents rather than from general knowledge. It is worth an hour, and it is the difference between a generic answer and a useful one. See AI features.

​
The mistakes worth avoiding

Instrumenting everything before checking anything. Instrument one service, verify it completely, then repeat. Twenty services instrumented identically wrong is twenty things to fix.
Building dashboards before setting service names. Every panel you build against unknown_service has to be rebuilt.
Creating forty alert rules on day one. Every rule that fires and is ignored trains your team to ignore the next one. Start with the handful you would genuinely get out of bed for.

​
Next

Docker

If your services run in containers on a few hosts.

Kubernetes

If they run on a cluster.

Enterprise

Many teams, single sign-on and a security review.