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.

single-host-architecture

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).

dual-host-architecture

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

architecture_overview
Figure 1. Instana 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.

Table 1. Component responsibility
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.
Table 2. Database responsibility
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.

Table 3. Component impact matrix
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: