AI-based observability for hybrid infrastructure

AI log analysis

Analyze with AI turns an error spike into a post-mortem. On a Graylog All Services source, when a service’s errors break from what is usual for that weekday and hour (or cross a threshold you set), Topologix collects up to 200 of its recent log lines, groups the repeated errors and asks the model what happened: the likely root cause with a confidence, the evidence it rests on and the next steps. You can also run an analysis by hand from the logs dialog.

• Every service is judged against its own usual error count for this weekday and hour, so a spike means unusual for that service, not just high.
• A new error type that a service has not logged in the last 7 days raises its own warning.
• The same log-error baselines run on the Syslog receiver, OpenTelemetry logs, Elasticsearch / OpenSearch, Aria Operations for Logs, Sentry and Elastic APM sources.
• The log lines pass through your organisation’s redaction rules before the model reads them.

Alerting guide: log error baselines →

AI incident explanation

Every flow has a monitoring bot. Describe a symptom in plain language and it answers from that flow’s evidence: the architecture and its dependencies, current values, open alerts and recent changes. With a model that supports tool use it looks things up itself, through read-only tools: it identifies what you named, searches for events and changes in the incident window, sizes the symptom with metrics, traces and logs, and only then confirms with a live read of a device or a database.

• Explain, on any row of the Alerts page or on an alert group, runs the same investigation in place and answers in three parts: likely cause, evidence and the next check.
• Every tool reports which sources it searched and which it could not, and why, so “no event found” is never claimed beyond what was read.
• Live reads are budgeted per answer, and every one is written to the audit log.
• Incidents on a service marked as a Business KPI can be investigated automatically in the background, without delaying the incident or its first notification.
• A finished answer can be exported as a PDF or e-mailed to the flow’s owner and the people it is shared with. The question you asked is never included.

AI model provider guide: the monitoring bot’s tools →

Alert correlation

Problems that start together are not always one problem. With alert grouping turned on, Topologix folds related problems into one alert group, and with evidence grouping it does so only over a relation it can name: the same entity, one running on the other, one service calling another, a shared change, vendor or platform, or the same specific error. Each group card says why it was joined, and problems that started together but share no relation stay apart, with what was tried.

• A group’s class (cascade, common cause, shared platform or burst) comes from rules. Where the rules are unsure, an automatic AI verdict decides and gives its reason, and the card shows which of the two decided.
• Explain on a group asks the monitoring bot whether the class is right. It can confirm it, name another, or conclude that the problems are separate events and split the group.
• RECAP, the companion root-cause engine, clusters raw error logs into ranked incidents with an LLM post-mortem. Attached to a log or trace alarm source, it marks each alarm row with whether RECAP already knows that error and links to the incident and its blast radius.

Alerting guide: alert groups →

AI workflows that investigate before they page

A workflow flow draws an investigation on the canvas: a trigger (a threshold breach, a monitor error, a log-error burst or a manual run), an AI analysis, a decision, an action that gathers more data and a notification. When the model is not confident enough, the confidence gate sends the run back for more evidence instead of letting it conclude.

• Every run is bounded: 60 steps, 5 minutes of wall clock and a token budget.
• An action marked external pauses the run until a person approves it.
• Runs are serialized per flow, so one workflow cannot fan out into many concurrent runs.

AI across daily operations

The same model provider serves the jobs around the alerts, each under its own role.

• Daily digest: Topologix computes the day’s numbers itself, and the model investigates with read-only tools and writes what changed and what looks suspicious. If the AI is unavailable, the digest still goes out with its numbers.
• Failover groups: the AI proposes standby pairs and active-active groups from the vCenter inventory, each with its evidence and a confidence, so right-sizing judges a standby by the load it must take over. Nothing changes until a proposal is accepted.
• Diagram import: a screenshot or PDF of an architecture diagram is read by a vision-capable model and turned into monitored nodes.
• Change reports: an AI assessment of each change report, on its own model role.

Your model, your data

AI in Topologix runs on the AI model provider you configure: Anthropic, AWS Bedrock, OpenAI, Azure OpenAI, Google Gemini, any OpenAI-compatible service, or a self-hosted model such as Ollama, vLLM or LM Studio. Each organisation decides which provider serves which job.

• With a self-hosted model nothing leaves your network: calls go to your own server, directly or through a proxy agent when the model runs on a LAN the Topologix server cannot reach.
• Prompts pass through your organisation’s redaction rules before they reach a cloud model.
• API keys are sealed at rest, masked in the API and never logged.
• The monitoring bot always acts as the flow’s owner, so nothing of another organisation is ever read.

AI model provider guide →