Installing Self-Hosted Classic Edition (Docker)
The Classic Edition consists of a number of components and services, each of which runs as an individual Docker container, and has its own configuration in terms of sizing.
During the installation, Instana automatically configures the required size of each component, and this calculation is based on the overall size of available resources on your machine.
Self-Hosted Classic Edition (Docker) offers fewer features and capabilities. Install or migrate to Standard Edition for additional features and capabilities. If you are deploying Instana for the first time, install Standard Edition instead of Classic Edition.
The single-host installation is a lightweight, easy-to-use option that is ideal for small to medium-level environments. It involves running Instana on a single host with all the necessary components of the Instana platform as Docker containers.
The benefits of this installation method include its simplicity and quick setup, low resource requirements, and suitability for testing and development. However, this installation method has limited scalability, lacks redundancy, and offers limited high availability options.
For information about how to install Self-Hosted Classic Edition (Docker), see Installing Self-Hosted Classic Edition (Docker).
The dual-host installation is designed for environments where ClickHouse is deployed on one host with a ZooKeeper installation. The rest of the Instana components and data stores are deployed on a second host.
This approach allows for better scalability of ClickHouse separately from the rest of Instana, based on requests per second (load). Resource allocation can be more efficient with separate hosts as more resources can be allocated independently to Instana and ClickHouse as they require more CPU or memory.
However, a dual-host setup is slightly more complex than a single-host setup, as two hosts need to be maintained and configured, requiring more infrastructure.
For information about how to create a Dual-host Instana setup on Docker, see Installation: Dual-host.
Architecture

Components
To prevent full outages and to provide the ability to partially process or provide data in the scenario of a partial outage, each component in the backend is responsible for parts of the overall data processing, and not for the whole.
Component | Responsibility |
---|---|
acceptor | Metrics and traces ingress. |
serverless-acceptor | Serverless traces ingress. |
appdata-legacy-converter | Allows issue-detection by using the existing processing pipeline. |
appdata-processor | Extracts calls from traces. |
appdata-reader | Gateway for reading the application data. |
appdata-writer | Writes processed calls. |
butler | Public login and user settings management. |
cashier-ingest | Calculates usage statistics. |
cashier-rollup | Calculates usage statistics rollups. |
eum-acceptor | EUM beacons ingress. |
eum-processor | EUM processing. |
js-stack-trace-translator | Deminifies js stacktraces for EUM |
filler | Metrics and trace processing, along with graph maintenance |
groundskeeper | Internal access management for agents. |
issue-tracker | Events generation, management, and notification. |
nginx | The central point of contact for EUM and UI. |
processor | Issue recognition. |
eum-health-processor | Issue recognition for EUM. |
appdata-health-processor | Issue recognition for Application perspectives. |
ui-backend | The backend part of the UI, and API provider. |
ui-client | In-browser part of the UI. |
Database | Responsibility |
---|---|
cassandra | Metrics history, spans, and profiles. |
clickhouse | Calls, appdata graph, and EUM. |
elasticsearch | Graph history and EUM. |
kafka | Inter-component communication. |
PostgreSQL | User settings store and historic usage statistics. |
zookeeper | State management for Kafka and clickHouse. |
Component impact matrix
If individual backend components are unavailable, they cannot interrupt the processing pipeline completely, but some components can impact more than others.
Component | Live metrics | Live traces | Live EUM | Live maps | Live events | Historic metrics | Historic traces | Historic maps | Historic events | Notifications | UI | Login | API | Usage stats |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
acceptor | X | X |
|
X | X |
|
|
|
|
|
|
|
|
|
serverless-acceptor |
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
appdata-legacy-converter |
|
|
|
|
X |
|
|
|
|
X |
|
|
|
|
appdata-processor |
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
appdata-reader |
|
X | X |
|
|
|
X |
|
|
|
|
|
|
|
appdata-writer |
|
X | X |
|
|
|
X |
|
|
|
|
|
|
|
butler |
|
|
|
|
|
|
|
|
|
X |
|
X |
|
|
cashier-ingest |
|
|
|
|
|
|
|
|
|
|
|
|
|
X |
cashier-rollup |
|
|
|
|
|
|
|
|
|
|
|
|
|
X |
eum-acceptor |
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
eum-processor |
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
js-stack-trace-translator |
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
filler | X | X | X | X | X |
|
|
|
|
|
|
|
|
|
groundskeeper | X | X | X | X |
|
|
|
|
|
|
|
|
|
|
issue-tracker |
|
|
|
|
X |
|
|
|
|
X |
|
|
|
|
nginx | X | X | X | X |
|
|
|
|
|
|
X | X | X |
|
processor |
|
|
|
|
X |
|
|
|
|
X |
|
|
|
|
eum-health-processor |
|
|
|
|
X |
|
|
|
|
|
|
|
|
|
appdata-health-processor |
|
|
|
|
X |
|
|
|
|
|
|
|
|
|
ui-backend |
|
|
|
|
|
|
|
|
|
|
X | X | X |
|
ui-client |
|
|
|
|
|
|
|
|
|
|
X | X |
|
|
Installing, configuring, and troubleshooting
See the following topics to install Classic Edition, or do other operations based on your needs:
- Installing Classic Edition
- Configuring Classic Edition
- Enabling feature flags
- Operations for Classic Edition
- Outbound network access requirements
- Backup and restore
- License activation and renewal
- Configuring end-user monitoring
- Configuring service provider (SAML/OIDC)
- Configuring LDAP
- Troubleshooting