Skip to main content
aiAxonIQ has four words for “a part of my system”: organization, project, service and environment. They are easy to confuse, and they do very different jobs. Only one of them — the organization — decides who can see what.

​
Organizations: the only boundary

Everything you send belongs to exactly one organization, and the license key on the request decides which. Users, license keys, dashboards and alert rules all belong to an organization too. Nothing narrower — not a project, not an environment — keeps one group of people from reading another group’s data.
If you need separation for access control, you need two organizations. Projects and environments are for organizing what you look at, not for hiding it. See Organizations and multi-tenancy.

​
Services: named by your telemetry

A service is whatever reports the same service.name. There is no service to create or register: a service appears as soon as telemetry arrives under a new name, and the Get started page names the services it has seen.
An unset service.name becomes unknown_service. Every service that forgets it merges into one entry that looks large and means nothing. Set it first. See Resource attributes.
Use the same service name in every environment. checkout-api in staging and checkout-api in production are one service in two environments; checkout-api-staging and checkout-api-prod are two services that can never be compared.

​
Environments: an attribute, not a container

An environment is the value of the deployment.environment resource attribute. aiAxonIQ also reads the newer spelling, deployment.environment.name, so either works.
There is nothing to create: the value arrives on your telemetry, and the product picks it up. The APM → Service map has an environment filter built from the values your traces carry, and you can search logs on the attribute — see Searching logs.
Without it, staging and production are the same service. Every chart shows the sum of the two, and a staging failure looks like a production one. The fix is one attribute on the sender. You cannot add it later to data that has already arrived.

​
The environment you picked on Get started is a different thing

When you set up your account, Get started asks how you are sending data — a Linux host, Docker, Kubernetes, an OpenTelemetry SDK or an OpenTelemetry Collector. That choice decides which install instructions and wording you see. It is not deployment.environment: it does not label your telemetry, and it does not separate one environment from another.

​
Projects: grouping services in APM

A project is a named group of services that the APM pages show together. You find them under APM → Projects. A project shows the telemetry of:
  • the service whose service.name is exactly the project’s name — no mapping needed, and
  • any other services you attach to it in the project’s Settings, under Services.
That second option is for a project named after a business capability — checkout — that is made up of services with other names. Each service can belong to only one project.
1

Create a project

In APM → Projects, select Add APM project and give it the name your service reports as its service.name. Creating a project needs the Editor role.
2

Attach any other services

Open the project’s Settings and add the other service names under Services.
3

Check it fills in

A new project is empty until one of its services sends traces in the selected time range. If it stays empty, compare the project name with the exact service.name your telemetry carries — the match is exact.
Some organizations have projects created automatically. Where this is turned on, a service that sends traces under a name no project claims gets a project of its own on its first span. Whether it is on depends on your deployment.

​
What a project does not do

A project is not an access boundary. Everyone in the organization can see every project. Rotating a project’s keys and deleting a project need the Admin role.
  • It does not change how you send OpenTelemetry data. OTLP is always sent with a license key, which belongs to the organization, not to a project. A project’s own keys are used by the browser agent for real user monitoring and to upload source maps.
  • It does not narrow logs or metrics. Logs and metrics are organization-wide. Projects group trace-based APM views.
  • Deleting a project deletes no telemetry. The data stays, and the project simply stops grouping it.

​
How they fit together

An environment and a project cut across each other. A project groups services by name; it does not know about environments. To look at one project in one environment, use an environment filter where the page offers one, such as the service map.

​
Next

Signals and the data model

How service.name and trace_id connect logs, metrics and traces.

Resource attributes

Setting service.name and deployment.environment, and naming services well.

Organizations

Isolation, membership, and when to use a second organization.