What Is IyziTrace and Why Did We Build It?

Using OpenTelemetry data to understand incidents and determine the next steps

In our previous article, we introduced OpenTelemetry: an open standard for collecting and transporting traces, metrics and logs from applications. But collecting data is only the beginning. When an alert comes in, the real questions are: What happened? Why did it happen? And what should we do next?

Let’s start with a scenario.

It’s 9:40 p.m. Payment screens are taking longer to respond, and messages saying “the payment isn’t going through” are appearing in the support channel. Each team checks its own dashboards. The application team sees no obvious error in the logs. The infrastructure team finds CPU and memory usage within normal ranges. The database team says queries are returning in reasonable time.

Everything looks normal on its own. Meanwhile, the customer is still waiting.

We’ve seen this situation many times. The problem was often not a lack of data. The data was there, but spread across different tools and teams. Bringing the pieces of an incident together could take longer than fixing it. The answer wasn’t in a single chart; it was in the relationships between the signals. That’s why we built IyziTrace.

What is IyziTrace?

IyziTrace is an observability platform built on OpenTelemetry. It brings together traces, metrics and logs from applications and infrastructure, connecting the signals related to the same incident. OpenTelemetry collects the data; IyziTrace makes it useful for investigation.

First, where is the problem? The service map

The service map shows how application components are connected and the status of the calls between them in a single view. In our payment scenario, the team can focus on the connection between the payment service and the database, and check its status. Instead of scanning the entire system to answer “Where is the problem?”, the team can narrow its investigation.

Then, when and why? Metrics, traces and logs

In this scenario, metrics show that latency began to increase at 9:32 p.m. and response times rose several times above normal. A trace from a slow payment request shows that most of the time was spent waiting for a database connection. Logs associated with the same request also show warnings that the connection pool was full.

This explains why the database team’s queries looked normal: the queries themselves weren’t slow; requests were waiting for a database connection. Each signal on its own may tell only part of the story. Together, they reveal what was happening.

The user’s perspective: RUM and synthetic monitoring

RUM (Real User Monitoring) measures the performance real users experience in their browsers. Synthetic monitoring automatically tests critical flows, such as payment, at regular intervals. Together, they help teams assess how a technical delay affects the user experience and critical business flows. In the payment incident, that helps answer an important question: How many users are affected?

AI investigations: shortening the initial investigation

A team can do everything described above manually; it just takes time. Iyzi Agent, part of IyziTrace’s AI Investigations feature, helps with the initial investigation. When an alert comes in, it queries telemetry data, lists possible causes alongside relevant evidence, and suggests next steps. The organization controls its choice of model and integration settings.

In our payment scenario, one finding might be that the connection pool became full around the same time the latency started. A new release deployed at that time may have increased the number of connections opened per request. A suggested next step would be to review the release and the connection pool settings.

These findings are a starting point, not a final decision. The investigation depends on the coverage and quality of the available data, and the team remains responsible for the final assessment.

Open standards and straightforward licensing

Open standards and data control have been priorities from the beginning. Organizations should be able to continue using their existing OpenTelemetry setup and decide how their data is collected and routed.

Using OpenTelemetry reduces the risk of locking data into a single provider’s proprietary format. IyziTrace does not require an IyziTrace-specific agent. It can work with open storage components such as Tempo, Loki and Prometheus/Thanos. IyziTrace is available as SaaS or can be deployed in an organization’s own environment.

We also kept the licensing model straightforward: on-premises licensing is based on the number of hosts, while SaaS licensing is based on data volume. In some traditional APM products, costs can be split across agents, modules and users, making them harder to estimate in advance. With IyziTrace, the service map, RUM, synthetic monitoring and AI Investigations are included in the license; they don’t require separate module licenses. AI Investigations uses a model selected by the organization, so IyziTrace does not charge a separate AI usage fee. Model costs remain with the organization’s chosen provider. This makes costs easier to forecast using a single measure.

Our goal isn’t to move more data into one place. It’s to reduce the time teams spend turning that data into useful context.

Next: from understanding to action

In our payment scenario, the team now understands what happened. But understanding the problem is only half the job. Should the connection pool settings change, or should the release be rolled back? And after the change, has the system actually recovered?

Iyzi Remedy, IyziTrace’s action layer, supports this next step. It proposes a solution, applies the action when the team approves it, and then verifies whether the system has recovered. For recurring issues, the team decides which steps can run automatically and which ones require approval.

In our next article, we’ll take a closer look at Iyzi Remedy and show how controlled automation works using the same payment scenario.