Observability and monitoring

Akka provides a host of observability and monitoring capabilities and is designed to plug into your existing monitoring tools. This means that while the tools in Akka Console will allow you to understand what is happening, they are designed to feed other tools you use to monitor, log, and observe your applications and services over time.

You can view logs, metrics, and traces via the following:

To export this data into your other tools see Exporting metrics, logs, and traces for more information.

Telemetry from a service

Logs, metrics and traces

The runtime produces three kinds of telemetry for every service, with no instrumentation code from you.

Logs

What each service instance writes, aggregated per instance. You view them in the Akka Console or with the Akka CLI.

Metrics

Counts and rates per service and per component: requests, failures, replicas, commands received by entities, view updates, consumer progress and replication between regions. See the metrics reference for the full list.

Traces

The path of one request through the components it touches, as spans with timing and attributes. Each span carries the resource attributes of the service that produced it. Tracing is turned on per project.

Where you see it

In the Akka Console, the Control Tower shows dashboards of metrics, a trace viewer and logs for each project. It aggregates traces, spans, metrics and logs across the regions of a project. During development, the local console shows traces and component state for services on your machine. See Local console.

Exporting to your own tools

Akka is built to feed the tools you already run. You configure exporters for each project, once for all three kinds of telemetry or separately for each, and you can send the same data to several destinations. Supported destinations include OpenTelemetry collectors, Prometheus remote write and Splunk. The configuration can be kept in an observability descriptor, versioned with the rest of the project. Export is available in every deployment option, including self-managed. See Exporting metrics, logs and traces.

Traces can be sampled before export: you choose what share of traces is sent, to control volume and cost.

Your telemetry and the platform’s telemetry

When Akka operates the platform, it runs its own observability stack to monitor the platform underneath your services. Your application’s logs, metrics, traces and evaluations go to the destinations you configure. A subset of platform telemetry goes to the federation plane for reporting across regions. See Akka Automated Operations technical overview.

Observability and the ledger

Both observability and the ledger describe what a system did, but they are kept for different purposes and have different properties.

Observability The ledger

Purpose

Operating the system: performance, failures, capacity

Governance: what each agent did, under which controls, with what verdict

Coverage

Can be sampled; log volume per instance is bounded

Every interaction, never sampled

Integrity

Ordinary telemetry

Hash-chained and tamper-evident

Retention

Set by the tools you export to

Kept for the regulatory period, and can be put on legal hold

Readers

Operators and developers, in the console and in your monitoring tools

Governance, compliance and the processes that grade and train models

A trace can be saved as a record in the ledger, and a ledger record refers to the trace it belongs to, so you can move from one to the other. See Governance and the runtime.

Limits and trade-offs

  • Changes to the export configuration take effect when a service restarts.

  • The console aggregates a bounded amount of log data per instance. To keep every log line, export logs to a logging provider.

  • Traces appear only when tracing is turned on for the project.

  • Sampled traces are not a complete record. Use the ledger when you need every interaction.