On-premise APM & AIOps

Observability that never leaves your data center.

Wrentrix traces every request, learns what normal looks like, and explains what broke — with AI that runs on your own servers. Built for OpenShift, Kubernetes and Linux. No cloud. No code changes.

Request a demo See how it works
  • 0 bytes of telemetry leave your network
  • ~2 min from install to first trace
  • Zero-code method tracing for .NET & Java
wrentrix · Overview
Overview● Live
Requests0
Error rate0.4%
p95 latency212 ms
payment-api41 ms
checkout-service612 ms
inventory-api18 ms
loyalty-worker137 ms
AI Probable root cause

checkout-service p95 rose 4.2× two minutes after rollout v2.14 changed its ConfigMap.

3 correlated traces1 config changelocal model
SLO burn rate 14.4×checkout · 1h / 5m window
Runs where your workloads run
  • Red Hat OpenShift
  • Kubernetes
  • Linux
  • OpenTelemetry
  • Ollama · local LLM
  • PostgreSQL
Why Wrentrix

Enterprise observability without sending a single span to the cloud.

Regulated industries need deep visibility and strict data residency at the same time. Wrentrix gives you both — everything from collection to AI analysis runs inside your perimeter.

Your data stays home

Traces, logs, metrics and AI analysis live on your servers. Works fully air-gapped — no license calls, no telemetry, no external model.

Zero-code instrumentation

Add a cluster, apply one YAML. Java and .NET services are traced down to their own methods on their next restart — no SDK, no rebuild.

AI that shows its work

Root-cause analysis on a local model, with an evidence chain you can click through: traces, changes, baselines and alerts — not a black box.

Distributed tracing

Follow a request through every service — and into the method that slowed it down.

OpenTelemetry-native tracing with a live dependency map, endpoint statistics and grouped errors. Wrentrix's admission webhook adds method-level hooks to .NET and Java pods as they start, so your own classes show up in the trace by name.

  • Service map, endpoint p50/p95/p99, error groups
  • Automatic method spans for .NET and Java — no code, no rebuild
  • Logs linked to traces; tail-based sampling for high volume
POST /api/orderstrace 7f3a…c21e · 486 ms
checkout-service486 ms
OrderController.Create447 ms
payment-api POST /charge68 ms
StockService.ReserveAsync341 ms
SELECT stock_items306 ms
kafka publish order.created22 ms
method span captured automatically by the Wrentrix .NET hook
Baselines & SLOs

Know what normal looks like — for every endpoint and every method.

Wrentrix learns hour-of-week baselines from your own history and flags real deviations, not noise. SLOs come with error budgets and multi-window burn-rate alerts that resolve themselves when things calm down.

  • Endpoint and method baselines with anomaly scoring
  • SLO error budgets, 4 burn-rate window pairs
  • Problem engine groups related signals into one incident
StockService.ReserveAsyncAnomaly · 4.2× baseline
rollout v2.14
baseline (p5–p95, same hour last weeks)p95 now
Kubernetes & OpenShift

Every workload, every rollout, every change — correlated.

Workloads, pods, events, HPA and right-sizing advice in one place. Wrentrix records spec, ConfigMap, Secret and restart changes and lines them up against latency and error spikes, so "what changed?" takes seconds.

  • Change correlation: spec, config, secret, rollout restart
  • Resource usage min/avg/p95/peak and right-sizing hints
  • Linux hosts with process discovery and journal logs
Workloadsnamespace: payments
WorkloadPodsCPU p95Last change
payment-api4/43 d ago
checkout-service6/6ConfigMap · 2 min
inventory-api3/31 d ago
loyalty-worker2/3rollout · 40 min
change_correlation config_changed matched to p95 spike (+380 ms)
Real user monitoring

See your application the way your customers do.

A lightweight browser collector reports Core Web Vitals, SPA routes, JavaScript errors and every fetch — and links each call to its backend trace, so front-end slowness and back-end slowness finally meet.

  • LCP, INP, CLS at p75 with good / needs-work / poor split
  • Per-app keys and allowed-origin lists
  • Session timelines and grouped JS errors
Web Vitals · p75checkout-web · 24 h
2.1 sLCP · good
240 msINP · needs work
0.04CLS · good
traceparent each fetch links to its backend trace
AIOps on a local model

Ask your systems what happened. Get an answer with evidence.

Wrentrix runs its assistant on a model hosted by you (Ollama, e.g. Qwen3). It reads live telemetry, cites the traces and changes it used, and answers in English or Turkish.

You

Why did checkout get slow after lunch?

AI

At 14:02 the checkout-service ConfigMap changed during rollout v2.14. Two minutes later p95 latency went from 146 ms to 612 ms. The slowdown sits in StockService.ReserveAsync, whose database call now takes 4.2× its weekday baseline.

  1. change ConfigMap checkout-config · resourceVersion 88412 → 88530
  2. baseline ReserveAsync p95 306 ms vs 73 ms (same hour, last 3 weeks)
  3. traces 3 slow traces, all waiting on SELECT stock_items

Suggested next step: compare the connection-pool settings in the new ConfigMap. Runbook “DB pool exhaustion” attached.

Ask anything about your services…↵

Root-cause analysis

Automatic RCA for alerts and incidents, ranked candidates, evidence chain.

Natural-language queries

“Top 3 services by traffic in the last 12 hours” becomes a real query plan.

Explain this screen

One click on any SLO, deploy or anomaly for a plain-language summary.

Automated remediation

Trigger webhooks or Ansible AWX job templates — automatically or with approval.

Platform

One platform, from the browser to the database call.

Distributed tracing

OTLP over HTTP (protobuf / JSON, gzip), service map, endpoint statistics, error groups.

Method-level tracing

Zero-code for .NET and Java; rule-based for Python and Node.js. Method baselines from 17-bucket histograms.

Logs & patterns

Pod, host and OTLP logs clustered into patterns; new and rising patterns flagged.

SLOs & problems

Error budgets, burn-rate alerts and a problem engine that groups signals by topology.

Kubernetes & OpenShift

Workloads, pods, events, HPA, right-sizing and change correlation.

Linux servers

CPU, memory, disk, network, journal logs and process discovery by technology.

Real user monitoring

Core Web Vitals, SPA routes, JS errors and front-end to back-end trace links.

Synthetic checks

HTTP(S) and TCP probes with TLS certificate expiry and response-time alerts.

Intelligent alerts

Alert wizard, channels, runbooks and AI-generated alert summaries.

Teams & access

Team-scoped views and permissions, mapped from LDAP or SSO groups.

Single sign-on

OIDC SSO with PKCE, LDAP sync, and an audit log of every change.

Custom dashboards

Build your own views; reports and AI summaries on a schedule.

Instrumentation .NET · zero-code methodsJava · zero-code methodsPythonNode.jsAny OpenTelemetry SDK
How it works

From Helm chart to first trace in minutes.

  1. 1

    Install Wrentrix

    Helm chart or OpenShift operator on your cluster — or Docker Compose on a Linux server. Runs under the default restricted-v2 SCC.

    $ helm install wrentrix ./wrentrix.tgz \
    -n wrentrix -f values.yaml
  2. 2

    Add a target

    Pick a cluster or Linux host in the UI and download a ready-made YAML or install script with its token already inside.

    $ oc apply -f wrentrix-k8s-agent.yaml
  3. 3

    Watch it light up

    Nodes, pods and hosts appear within about two minutes. Java and .NET apps are traced to the method on their next restart — Wrentrix never restarts your workloads.

    ✓ 6 nodes · 334 pods · traces flowing
Security & data sovereignty

Designed for banks, airlines and the public sector.

Everything Wrentrix collects stays inside the boundary you draw. The diagram is the whole architecture — there is no hidden cloud component.

  • Runs fully air-gapped; image-less agent install for closed networks
  • Local LLM only — prompts and answers never leave your servers
  • OIDC SSO, LDAP, team-based RBAC and an audit log
  • Least-privilege pods, no root, no extra SCCs
  • Agent never restarts your workloads; fail-open admission webhook
All Wrentrix components run inside your network boundary YOUR NETWORK ApplicationsJava · .NET · Node · Py Wrentrix agentsOpenShift · K8s · Linux Browsers (RUM)Web Vitals · JS errors WrentrixAPI · analysis · UI3+ replicas Local LLMOllama StoragePostgreSQL Your teamsSSO · alerts · runbooks 0 bytes out →
0bytes of telemetry sent outside your network
< 25 msp95 admission-webhook overhead per pod start
~2 minfrom applying the agent YAML to first data
EN · TRuser interface and AI assistant languages
FAQ

Questions we hear often.

Does any data leave our network?

No. Collection, storage, analysis and the AI model all run on infrastructure you control. Wrentrix works in fully air-gapped environments.

Do we need to change our application code?

No. After the agent is installed, Java and .NET pods are instrumented automatically when they next start, down to method level. Python and Node.js are covered through OpenTelemetry, and any OpenTelemetry SDK can send data over OTLP.

Which platforms are supported?

Red Hat OpenShift and Kubernetes clusters, and Linux servers. Wrentrix itself installs with a Helm chart, an OpenShift operator or Docker Compose.

Which AI model does Wrentrix use?

A model you host with Ollama — we recommend Qwen3 8B. GPU is optional but recommended. AI features can also be turned off entirely.

Will the agent restart our workloads?

Never. Instrumentation is applied as new pods start. If the agent is unavailable, pods start normally without instrumentation.

Is it compatible with OpenTelemetry?

Yes. Wrentrix accepts OTLP traces and logs, uses the OpenTelemetry operator for auto-instrumentation and works alongside your existing collectors.

Get started

See Wrentrix on your own infrastructure.

Tell us a little about your environment and we will set up a demo — on-site or on a cluster you choose.

Submitting opens your email client with the details filled in.