ADIM — AI-DRIVEN INFRASTRUCTURE MONITORING

One Step Ahead in Operations

Traditional monitoring stops at generating alerts — AI-driven infrastructure monitoring shouldn’t. ADIM analyzes alerts with AI, remediates safe ones through pre-approved runbooks, escalates risky ones to humans — and records every action in a full audit trail. In Turkish, ‘adım’ means ‘step’ — and that’s exactly what ADIM keeps you: one step ahead.

Does the 3:00 AM alert sound familiar?

How AI-Driven Infrastructure Monitoring Works in ADIM

Zabbix raises an alert → ADIM analyzes it (AI classification + operational memory of past incidents) → Is it safe? → Yes: an approved runbook executes and the result is verified → No or uncertain: escalation to a human, with full diagnostics already prepared.

In ADIM, the AI never executes free-form commands. Only pre-approved, allow-listed runbooks run. A runbook that changes something — a clean-up, a restart — runs automatically only when its class matches the alert’s class; a mismatch, or an alert ADIM cannot classify, goes to the approval path instead. The rules that classify an alert read the trigger fields only, never the model’s free-text reasoning. If the same alert has repeated three times within six hours, automated remediation stops and the incident is handed to a human. Any incident that doesn’t stabilize within 15 minutes exits auto-remediation mode and transitions to human ownership.

Every remediation runs in one of three recorded modes: automatic (the runbook passed every RCI gate), approved (a named operator approved it from chat), or suppressed (correlated as a symptom or duplicate — acknowledged, no action). The approver, the evidence and the result are stored with the incident. ADIM covers Linux, Windows and Docker hosts, VMware vSphere and — read-only — SNMP-monitored network devices, and it keeps the software on those hosts patched: vulnerabilities are detected, decided on and fixed in the same system.

Don’t trust automation blindly. Measure it.

RCI — Runbook Confidence Index

Every runbook is scored on predictability, reversibility, blast radius, historical success rate, and detection confidence. The result is one of four levels: Autonomous, AI Recommended, Approval Required, Manual Only. Your risk appetite — not an algorithm — decides what runs automatically.

Operational Memory

Every incident is recorded together with its outcome and root cause. When a new alert arrives, ADIM already knows the answer to: has this happened before, and what actually worked?

Full audit trail

Every action — successful, failed, skipped, or manually escalated — is reported. Designed for enterprise environments with audit and compliance requirements.

What ADIM covers today

Linux, Windows and Docker remediation

Service and container restarts, monitoring-gap checks and disk clean-up — with evidence, not guesswork. Containers you mark as protected — databases, the monitoring stack itself — restart only after approval. A service alert is re-checked before anything runs: if the service has since been disabled or removed on purpose, the alert is closed with that evidence instead of restarting it — a service you switched off should never page anyone. On Windows, the scripts ADIM runs are delivered as files and deleted after the run. When a disk fills up, ADIM first reports what filled it (directories, container logs, journals, rotated logs, large files, inodes), what grew since yesterday from its daily snapshots, the seven-day trend and the estimated time to 90% and 100%. Clean-up candidates are classed safe / review / never — data directories, volumes and databases are never on the list. Only safe items are offered for approval, item by item from chat, and the realised gain is reported next to the estimate. Linux and Windows alike.

Change-aware: an alert that follows a known change is closed, not escalated

Alerts that follow a planned change — an OS-update run, an unattended upgrade, a change you reported from chat — are recognised from the change log and closed with the evidence attached, instead of waking someone up. On Windows, ADIM reads the update history and the boot events to explain an “OS changed” or “restarted” alert; on Linux it traces who changed the installed packages — ADIM’s own update, a clean-up, an operator, or unknown — and escalates only the unknown. Account changes (passwd, shadow, group) get a deliberate exception: an explained change may auto-close, but it always produces a notice to a second person. “Explained” is not “harmless” — a compromised operator account can leave a backdoor user behind, and someone else has to see it.

Vulnerability management: inventory, detect, decide, fix

A vulnerability scanner runs on the ADIM server and checks your Linux and Windows hosts once a month — agentless: it logs in with the same service account ADIM already uses and reads the installed software, so nothing extra is installed on any host and no new account is created. The scanner and its feed are open source and updated by ADIM itself; there is no extra license fee. Vulnerability detail — which host, which CVE, which package — never travels through chat or e-mail. When new findings appear you receive one e-mail saying a report is ready, with counts by severity and a link; the report itself is downloaded only from the authenticated Actions History screen, and it always covers every scanned host, never one host at a time. A daily import keeps the open-vulnerability list in ADIM’s database, a Grafana dashboard shows the fleet, and the Monday digest follows the same link-only rule.

Finding is half the job. In the Actions History UI every open vulnerability has a decision screen with three choices: autofix — ADIM applies the fix itself; AI guide — for a system you would rather touch by hand, the engineer asks how to fix it and gets the steps; accept the risk — leave it open for a period you set, recorded with your name. Fixes run after a named approval and are verified afterwards: ADIM rescans that host and closes the finding only when the scan confirms it. The approval card names the host, the package and the target version — not the CVE, not the severity. On Linux the fix is a package update. On Windows it is the software that never gets updated — the Chrome or Notepad++ installed once, outside your software distribution — which is exactly where most findings sit: from a software catalog, the ADIM server downloads the current installer, verifies its hash, copies it to the host, checks the vendor’s code signature there and installs silently — or uninstalls the program, if that is the decision. Your hosts need neither internet access nor a package manager for any of this, and software outside the catalog is refused, never guessed. Fixes that the OS vendor ships only through an extended-support subscription — Ubuntu Pro ESM, for example — are recognised as such and not attempted on a host without that subscription; the decision screen says why.

VMware vSphere: correlate, collect evidence, act only with approval

A VM alert while its hypervisor is down is a symptom, not an incident; the same datastore alert from three hosts is one incident, not three. ADIM correlates first, collects vSphere evidence, classifies the case and proposes the corrective action — power a VM back on, reconnect a host, remove old snapshots — which runs only after a named approval and is verified afterwards. Everything else is escalated with L2 advice attached.

OS update automation

Maintenance windows per host live in a schedule you own — and the schedule is the approval. Nobody approves 200 servers one by one: ADIM announces the next day’s windows in a single message, runs pre-checks, the update and the post-reboot checks host by host, lists only the failures individually and sends one summary per window. An independent audit the next morning verifies what was actually installed. If a post-check fails, the maintenance is closed early and the normal runbooks take over. Interdependent systems update in tiers: stop the application services, update the database tier first, gate on its post-checks, then the application tier — and a dry run shows the whole sequence before any window runs for real.

Network devices — read-only by design

For SNMP-monitored switches and routers ADIM correlates (a device that stopped answering vs. its interfaces), collects read-only evidence — admin/oper status, errdisable, optical levels, error counters, logs, config diff, the far end — and notifies the right people with the evidence in hand. It takes no action on network devices, not even with approval: production traffic is not something a runbook should touch. Daily configuration snapshots are kept. Validated on a simulated Cisco IOS lab; vendor-specific validation is part of the pilot.

Maintenance control from chat

“Put the DB host in maintenance until 18:00.” “Monitoring off for host X tomorrow 09:00–16:00.” Natural language, immediate, reversible, logged. ADIM watches the host and tells you when it is back.

Onboarding: from a server list to monitored hosts

Hand ADIM your server inventory as a spreadsheet — uploaded through a form or posted to an endpoint, no shared drive needed. For each host ADIM runs a discovery over the access method the list names (SSH, Zabbix agent, SNMP or ICMP), identifies the OS and the running stack — database, web server, container runtime — registers it in Zabbix with the matching templates and one of three threshold profiles (standard / critical / light), keeps it in a 24-hour burn-in maintenance so the first day pages nobody, verifies the collected items and sends back a result workbook. Every batch can be rolled back with one call. Built for customers leaving another monitoring tool — or starting from none.

Capacity: disk trends and CPU/RAM right-sizing

Daily disk-fullness forecasts and a monthly CPU/RAM right-sizing report (30-day window, business hours weighted), built on Zabbix data and enriched with vSphere data where available. Deterministic rules — no AI guesswork in capacity numbers.

Actions History — the incident dossier

A web UI where every alert becomes a dossier: the timeline of each step ADIM took, the evidence it collected, who approved what and when, similar past incidents, and an AI narrative in English, German or Turkish. The same UI hosts the vulnerability decision screen. Role-based users (admin / operator / viewer), 18 months live retention with archive, Markdown export and a JSON API — so your auditor and your customers read the same record you do. And everything ADIM says — chat notifications, approval messages, L2 e-mails, the dossier UI, the installation docs — comes in English, German or Turkish, set per installation.

Start in shadow mode. Keep the monitor monitored.

A pilot starts in shadow mode: every action runbook is routed to the approval path and nothing runs on its own, while the read-only diagnostics and the AI triage already work — you see what ADIM would have done, with the evidence, before you let it. Zabbix keeps a notification channel of its own that does not pass through ADIM, so if ADIM’s engine ever stops you hear it from Zabbix within seconds, not from silence. Runbook decisions are regression-tested every night against a fixture set — a runbook that reports success without evidence fails the gate — the engine has been storm-tested with 300 simultaneous alerts without losing one, and a runbook that crashes mid-run is itself recorded and escalated rather than lost.

Dashboards, reports and self-improvement

Seven Grafana dashboards, including Runbook Outcomes, Alert Flow & Noise, AI Decision Quality, Host Health, Human in the Loop and ADIM Vulnerabilities; a daily shift-handover report; and a weekly noise review that lists which manual actions have become automation candidates. When ADIM finds a gap in its own coverage it files an improvement item for a person to review — it never modifies itself in production.

Runs on your servers, connects to your Zabbix

ADIM is installed as Docker containers (workflow engine + PostgreSQL/pgvector) on a server in your environment by a scripted installer that ends with a 19-point verification. On your hosts ADIM installs no agent of its own: it needs a service account reachable over SSH, and Zabbix can watch the hosts with its agent, SNMP or SSH — whatever you already use. The optional vulnerability module adds a scanner on the same ADIM server, its UI bound to localhost; it reaches Linux hosts over SSH and Windows hosts over SMB from the ADIM server only, with the same service account. It connects to your existing Zabbix (6.0 or newer) — it does not replace it. Only the alert webhook endpoint is published, over HTTPS with an IP allowlist; the management UI is never exposed. Alerts, incident history, evidence, runbook outputs and the audit trail are stored on your server.

Four things cross your perimeter, and we say so: the AI model calls (a cloud LLM API by default, or a private on-premise LLM for isolated environments), the license heartbeat, the notification channels you choose, and — with the vulnerability module — the ADIM server’s outbound downloads of the vulnerability feed and vendor installers. Your hosts themselves never download anything from the internet for ADIM. Exactly what each one carries is documented on the Security & Data Flow page.

Security & Data Flow: what runs where, what leaves your network, and the guardrails →

Who is ADIM for?

• Enterprise IT operations teams — who want to cut alert noise and automate the L1 workload
• MSPs and outsourcing providers — who need a consistent, auditable remediation standard across multiple customers
• Regulated industries — who must keep a who/what/when record of every action

Setup + monthly managed service

After a one-time discovery and pilot deployment, ADIM operates AI-driven infrastructure monitoring as a monthly managed service: runbook development, integrations, dashboards, monthly reporting, and continuous tuning are all included. Pricing is based on the number of monitored systems and the runbook scope.

ADIM is built by Bigs Bilişim — a team with 26 years of enterprise systems experience, delivering SAP Basis, Windows/Linux, and monitoring operations services to enterprise customers including Daimler Truck AG. About Bigs Bilişim →

Frequently Asked Questions

Can the AI execute a wrong command?

No. The AI only performs classification and decision support; everything that executes is a pre-approved, allow-listed runbook. Free-form command generation is blocked at the architecture level. And an action runbook must also match the alert’s class — a disk clean-up cannot be triggered by a memory alert, whatever the reasoning text says.

Where does the AI run, and what does it see?

By default the classification and diagnosis calls go to a cloud LLM API over HTTPS. The model receives the alert text, the host name, the trigger, operating context (OS, recent changes, maintenance state) and short evidence excerpts from the runbooks — never credentials, keys or configuration files. Customers who cannot allow this run ADIM with a private LLM on their own hardware. The full list is on the Security & Data Flow page.

What happens if we end the service?

ADIM runs under a signed license lease that your installation renews every six hours. When the lease is no longer renewed, automation stops and alerts are forwarded as raw notifications — monitoring itself continues, and all data, runbooks and history stay on your server. Your Zabbix was always yours.

Does it work with monitoring tools other than Zabbix?

The current version is deeply integrated with Zabbix. Integration with other monitoring tools that can emit webhooks is evaluated as part of the project scope.

How long does deployment take?

A typical pilot — discovery, deployment, and the initial runbook set — goes live within 2–4 weeks.

Does it work behind a proxy or in an air-gapped environment?

Behind a proxy: yes, out of the box. Fully air-gapped: on request — it requires the private LLM option (inference on your hardware) and an offline license lease instead of the heartbeat. Talk to us before assuming either way.

Can we start without letting ADIM act on anything?

Yes — that is the default for a pilot. In shadow mode every action runbook goes to the approval path and nothing runs on its own; diagnostics, correlation and AI triage already work, so you watch what ADIM would have done, with evidence, and switch runbooks to automatic one at a time when you are ready.

Do we have to install an agent for vulnerability scanning?

No. The scan is agentless and credentialed: once a month the scanner on the ADIM server logs in with the service account ADIM already uses and reads the installed software. Linux hosts need nothing extra. Windows hosts need SMB reachable from the ADIM server only and, for a local service account, remote administrative access over SMB enabled — the installation guide lists the exact steps. If a local firewall rule blocks SMB, only the ADIM server’s address is exempted from it.

How does ADIM fix third-party software on hosts without internet access?

Through a software catalog you control. For a catalogued program the ADIM server downloads the vendor’s current installer, verifies its hash, copies it to the host, checks the vendor’s code signature on the host and installs silently — or uninstalls the program if that is the decision. The host needs no internet and no package manager. Closed sites only have to distribute the vendors’ code-signing root certificates, which the installation guide covers. Software outside the catalog is refused.

What if ADIM itself goes down?

Zabbix tells you. ADIM’s heartbeat is monitored by Zabbix through a notification channel that does not pass through ADIM, so an engine outage is reported within seconds. Your existing Zabbix alerting keeps working as before in any case — ADIM is one additional action, never a replacement for yours.