Product Guide

The agent collects

Runs on the monitored host, connects to the database with a read-only account and reads host metrics from /proc.

Ships over gRPC

Streams to the API over a single outbound TLS connection (443/tcp). The agent opens no listening port.

The API processes and stores

Metadata goes to PostgreSQL, time-series metrics to InfluxDB; the anomaly, baseline and correlation engines run here.

The UI shows it

Served from the same 443 port: dashboards, alerts, RCA and reports.

Kind + Helm

Installs Kind, Helm and the complete ClusterEye stack on Ubuntu 24.04.

1curl -sSL https://archive.clustereye.com/clustereye-stack-install.sh | bash

Bare-metal Linux

Full platform directly on Linux — no Docker, no Kubernetes.

1curl -fsSL https://archive.clustereye.com/deploy/standalone/install.sh | sudo bash -s -- \
2  --api-version=VERSION --ui-version=VERSION \
3  --domain=YOUR_DOMAIN_OR_IP --postgres=local

Agent only (Linux)

Just the agent, talking to an existing ClusterEye server.

1curl -sSL https://archive.clustereye.com/install.sh | sudo bash -s -- \
2  -p postgres --api-url <clustereye-host> --tls

An operator starts it

One click from the alarm or incident drawer. There is no automatic triggering — no investigation ever runs unless you ask for it.

ClusterEye gathers evidence

Only data ClusterEye already stores: alarm history, metric series, event and change records, query statistics. No new database connection is opened.

The model plans and reads

The model says which evidence it needs, the server runs the permitted read-only tools and hands back the result. The model cannot write SQL and cannot step outside the tool list.

The answer cites its evidence

Competing hypotheses, the supporting and contradicting evidence ids for each, what is missing, and recommended next steps. When the evidence is not enough, the engine says so.

What it reads

• Alarm and incident records: when it started, how often it recurred, which alarms accompanied it, how it was resolved before.
• Metric series and their learned normals (seasonal baseline): CPU, memory, connections, wait time, storage.
• Engine evidence: blocking episodes, deadlock records, backup age, replication state, query statistics.
• The event stream: configuration changes, deployments, failovers, agent health.

What it never does

• It does not connect to your database. No live query is run during an investigation — this is a fixed limit, not a setting.
• Nothing the model writes is executed. It may only call registered read-only tools; it cannot produce, run or apply SQL.
• It does not trigger itself. There is no scheduled or alarm-triggered automatic investigation.
• Raw query text never leaves the server, and your data rows never reach the model.
• The model's reasoning steps are not stored — only the plan, the tools it called and the final result.

Sent

• Alarm/incident metadata: type, severity, node, database name, timestamps, occurrence count.
• Metric summaries: mean, peak, last value, sample count and the deviation from the learned expectation.
• Query fingerprints: verb + first table + length, with literals replaced by '?' (e.g. "SELECT … dbo.Orders … (redacted, 162 chars)").
• Event titles and configuration-change summaries.

Not sent

• Data rows from your tables — no tool reads rows.
• Raw SQL text, bind values, literals.
• Passwords, tokens and connection strings: every message passes a redaction layer before it reaches the model.
• The model's hidden chain of thought (never stored, never displayed).

Does the AI investigation connect to my database?

No. An investigation runs purely on data ClusterEye has already collected and stored: alarm history, metric series, event records, query statistics. The live database call budget is zero and cannot be raised by configuration, so starting an investigation adds no load to your production database.

Does my data leave the environment? Does it work air-gapped?

The model can run on your own infrastructure: any OpenAI-compatible endpoint (for example vLLM on your own hardware) is enough and no internet access is required. In that setup the evidence never leaves your network. A cloud provider can be configured instead; even then what reaches the model is limited to alarm metadata, metric summaries and query fingerprints — your data rows and raw SQL text are never sent.

What exactly is sent to the model?

Alarm and incident metadata, metric summaries (mean, peak, deviation from the learned expectation), event and configuration-change titles, and query fingerprints. Query text is reduced to verb + first table + length with the literals removed before it is sent. Passwords, tokens and connection strings are masked in every message. No tool reads rows from your tables.

Can the AI act on its own?

No. The model may only call registered, read-only tools; it cannot produce, run or apply SQL and it cannot change anything. Recommended actions are text, and the risky ones are explicitly flagged as requiring DBA approval. Investigations do not start by themselves either — there is no scheduled or alarm-triggered automatic run.

Who can start an investigation?

Admin and DBA roles can start one; it requires the 'ai' feature on an Enterprise licence and a per-user AI quota. Anyone who can see the alarm can read the result and leave 'useful / not useful' feedback. Every tool call and every investigation is written to the audit log together with who started it.

What if the AI names the wrong root cause?

The output is not a single answer but competing hypotheses, each with the evidence ids that support and contradict it and a list of what is missing. Confidence is bounded by deterministic rules — a hypothesis resting on a single signal, on history alone, or on contradicted evidence cannot be rated highly, whatever the model claimed. The engine is allowed to answer 'no clear root cause' or 'insufficient evidence', and it reports evidence it does not have as unavailable rather than guessing.

Is the agent service up?

If the service runs but the node never shows up in the UI, it is almost always networking or database credentials.

1systemctl status clustereye-agent
2journalctl -u clustereye-agent -f --no-pager

Can it reach the API?

Run this from the agent host. No answer means the 443/tcp rule; if you use a self-signed certificate install the agent with -k.

1curl -sS -o /dev/null -w '%{http_code}\n' https://<clustereye-host>/api/v1/health

Is the database account sufficient?

This succeeds once the baseline grants are in place. Use the equivalent for your engine (Oracle: V$SESSION, MSSQL: sys.dm_exec_sessions).

1psql -h <host> -U clustereye -c 'SELECT count(*) FROM pg_stat_activity;'

Query intelligence empty?

If metrics flow but the query list stays empty, the missing piece is almost certainly an engine prerequisite: pg_stat_statements, Query Store, performance_schema or log_queries.

1SELECT * FROM pg_extension WHERE extname = 'pg_stat_statements';