AI-agenter for infrastrukturen

Status200 AI kan se på mer enn telemetrien din mens den undersøker en hendelse eller et varsel. En liten agent som er installert ved siden av en av ressursene dine (en Docker- eller Podman-vert, en Docker Swarm-klynge, en Proxmox-klynge, et VMware vCenter, en Ceph-klynge, en databaseserver eller en Linux-vert), kjører de skrivebeskyttede kommandoene Status200 AI ber om, for eksempel docker logs --tail 200 web, pvesh get /cluster/status, ceph health detail, db long-queries --min-seconds 30 eller journalctl -u nginx -n 200 --no-pager, og sender utdataene tilbake, slik at rotårsaksanalysen siterer det ressursen selv sier. Hvis du tillater det, bruker den samme agenten også rettelser (starter en container på nytt, starter en VM, markerer en OSD som in igjen), hver av dem plassert i et nivå av en kommandopolicy og, med mindre du velger noe annet, godkjent av et menneske først.

Disse agentene er ressurs-AI-agentene. Hver ressurs side i dashbordet har en KI-seksjon med tre sider:

• Innsikt: det Status200 AI har funnet ut om ressursen de siste 30 dagene, altså problemene som stadig kommer tilbake og hvorfor, med det KI-en fant og trinnet den foreslår, delene av ressursen som står bak de fleste av dem, rettelser som ikke hjalp eller som venter på godkjenning, det KI-en rettet på egen hånd, og risikoene som ble oppdaget før noen ble varslet, med det KI-en selv gjorde der som fotnote. Den fungerer som en klynges; se Hva KI-en har lært på en klynge.
• Logger: alt Status200 AI har gjort på ressursen, nyeste først: hver undersøkelse med hendelsen eller varselet og sammendraget, hver rettelse den foreslo eller kjørte, og hver kommando den sendte gjennom agenten. (Denne siden het tidligere Innsikt.)
• AI-agent: om agenten er tilkoblet, hva KI-en kan gjøre på ressursen (undersøke, og hvordan rettelser kjører), alt som trenger oppmerksomhet med trinnet som løser det, og i menyen ⋯ ved siden av agentens status Test tilkoblingen og Tilbakestill agenten.

Ressursens Oversikt slutter med et AI-agent-kort som oppsummerer AI-agentens side: om agenten er tilkoblet, om undersøkelse er slått på, hvordan rettelser kjører (Av, Be om godkjenning, Automatisk eller Hopp over godkjenning), og hva som trenger oppmerksomhet, med en lenke til AI-agentens side, der de endres.

Slik fungerer det#

Agenten venter aldri på en tilkobling fra Status200: den kontakter selv Status200, ber om arbeid og kjører bare det dens egen kopi av kommandopolicyen tillater, med påloggingsinformasjonen den allerede har.

Forholdet til Kubernetes-AI-agenten#

Kubernetes-klynger har sin egen agent, Kubernetes-AI-agenten, som installeres av Kubernetes-agentens Helm-chart; se Klyngetilgang: la Status200 AI kjøre kubectl. Ingenting på denne siden endrer den. Ressurs-AI-agentene følger samme utforming:

• De samme nivåene og modusene. Hver kommando er Read, SafeWrite, RiskyWrite eller Denied, og rettelser er Av, Be om godkjenning, Automatisk eller Hopp over godkjenning, med samme betydning som på en klynge.
• De samme tre kontrollene. Den samme kommandopolicyen håndheves av Status200s KI-verktøy, igjen når Status200 setter kommandoen i kø, og igjen av agenten før den kjører noe.
• Den samme regelen om påloggingsinformasjon. Agenten bruker bare det dens eget miljø og dens monteringer gir den. Status200 sender den aldri påloggingsinformasjon.
• De samme standardene. KI-undersøkelser er slått på som standard: en ressurs starter med undersøkelse slått på og rettelser slått av, akkurat som en klynge, så Status200 AI undersøker med agenten sin så snart den kobler til, og endrer ingenting før noen tillater rettelser (se Koble til Status200).

Hva som er annerledes:

• Ett image for alle ressurser. status200/resource-ai-agent betjener alle åtte ressurstypene, og STATUS200_AI_AGENT_RESOURCE_TYPE sier hvilken en agent betjener. Den kjører ved siden av ressursens collector som én container til, ikke fra et Helm-chart.
• Skrivetilgang er en miljøvariabel. Først STATUS200_AI_ALLOW_WRITES=true på agenten lar den bruke rettelser i det hele tatt, og STATUS200_AI_WRITE_TARGETS begrenser hvilke containere, tjenester, VM-er, OSD-er, økter eller units de kan røre. På en klynge gjør chartets RBAC og aiAgent.remediation.namespaces dette.

I likhet med Kubernetes-AI-agenten er en ressurs-AI-agent ikke en Runner. Den vises aldri under Runbooks → Runbook-agenter, og den brukes aldri som Bash- eller SSH-vert for runbooks.

Støttede ressurser#

Databaseservere: Database-AI-agenten har diagnostikk for PostgreSQL, MySQL (og MariaDB og Percona Server), Redis (og Valkey, KeyDB og Dragonfly) og MongoDB. For alle andre motorer kjører den ingenting og sier det på databasens AI-agent-side.

Test tilkoblingen, i menyen ⋯ ved siden av agentens status på AI-agentens side, kjører disse skrivebeskyttede kommandoene gjennom agenten og viser utdataene i agentens kort:

På en Docker Swarm-worker feiler docker node ls: Docker Swarm-AI-agenten må kjøre på en managernode. En agent som startes på en worker, registrerer seg ikke for klyngen før noden dens er en manager, og Docker Swarm-installasjonsprogrammet utelater den på en node som ikke er manager.

Installer en AI-agent#

Hver ressurs-AI-agent er det samme imaget, status200/resource-ai-agent:release. Den trenger ingenting i dashbordet: så snart den kjører, registrerer den seg hos Status200 og dukker opp på ressursens AI-agent-side innen ett minutt.

Ved siden av en collector#

For Docker, Podman, Docker Swarm, Proxmox, VMware, Ceph og databaseservere kjører agenten ved siden av collectoren du allerede bruker for den ressursen, og deler dens .env: den har allerede STATUS200_URL, inntaksnøkkelen og ressursens navn. Hver collectors docker-compose.yml leverer agenten som én tjeneste til, og dens install.sh starter den.

En collector som ble installert før AI-agenten fantes, kjører den ikke ennå. Kjør install.sh for den på nytt: den starter nå også AI-agenten (installasjonsprogrammene for Proxmox, VMware, Ceph, databaser og Docker Swarm laster ned den gjeldende docker-compose.yml, som har AI-agentens tjeneste). Hvis du styrer filene selv, legger du tjenesten fra collectorens docker-compose.yml til i din egen og kjører docker compose up -d. Ressursens AI-agent-side viser den nøyaktige tjenesten for den ressursen, med navnet allerede fylt ut.

Uten installasjonsprogrammene er Docker-AI-agenten én docker run:

docker run -d \
  --name status200-docker-ai-agent \
  --user 0:0 \
  --restart unless-stopped \
  --read-only --tmpfs /tmp \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -e STATUS200_URL="https://status200.ru" \
  -e STATUS200_SERVICE_TOKEN="YOUR_TELEMETRY_INGESTION_TOKEN" \
  -e STATUS200_AI_AGENT_RESOURCE_TYPE=docker \
  -e DOCKER_HOST_NAME="my-docker-host" \
  status200/resource-ai-agent:release

DOCKER_HOST_NAME må være navnet Docker-agenten rapporterer. Installasjonsprogrammene for Docker og Podman tar --no-ai-agent (eller STATUS200_INSTALL_AI_AGENT=false) for å utelate AI-agenten, og det gjør også Docker Swarm-installasjonsprogrammet. For å kjøre en collector uten den senere, sletter du AI-agent-tjenesten dens fra docker-compose.yml, eller fjerner containeren dens med docker rm -f.

Verts-AI-agent#

En Linux-vert som rapporterer gjennom OpenTelemetry-collector på verten, har ingen Status200-container å stå ved siden av, så Verts-AI-agenten kommer med sitt eget installasjonsprogram (agents/HostAIAgent):

curl -fsSL <YOUR_STATUS200_URL>/docs/static/scripts/agents/HostAIAgent/install.sh -o install.sh
sudo bash install.sh

Det ber om Status200-URL-en din, prosjektets telemetri-inntaksnøkkel og vertens navn, skriver /opt/status200-host-ai-agent/.env og docker-compose.yml og starter containeren status200-host-ai-agent. Legg til --systemd for i stedet å kjøre den under systemd-uniten status200-host-ai-agent. Den trenger Docker (systemmotoren, ikke rootless Docker) med Compose-pluginen; rootful Podman kan kjøre den samme containeren.

Verts-AI-agenten kjører vertens egne programmer: hver kommando kjører som nsenter --target 1 --mount --uts --ipc --net --pid -- PROGRAM ARGS, som går inn i navnerommene til vertens init. Det krever pid: host, privileged: true og root; se Docker-socketen og Verts-AI-agenten er root på verten. La HOST_NAME være tom for å bruke maskinens vertsnavn, som er det collectoren rapporterer som host.name med mindre du har endret det; ellers setter du det til navnet som vises under Verter.

Koble til Status200#

Agenten registrerer seg med den samme identiteten som collectoren rapporterer (DOCKER_HOST_NAME, PROXMOX_CLUSTER_NAME, CEPH_CLUSTER_NAME, …; STATUS200_AI_AGENT_RESOURCE_NAME overstyrer den), slik at den betjener nøyaktig den ressursen collectorens telemetri opprettet. Når Status200 ennå ikke har noen ressurs med det navnet, oppretter registreringen den, så et navn som avviker fra collectorens, gir deg en ny, tom ressurs i stedet for en feil. En database registrerer seg med DATABASE_SERVER_ID når den er satt, ellers med motor, adresse og port; en DATABASE_SERVER_ID som ikke er en database i dette prosjektet, avvises.

Hvis collectoren fortsatt bruker standardnavnet sitt (docker-host, podman-host, docker-swarm, proxmox-cluster, vmware-vcenter, ceph), rapporterer hver ressurs som er installert med den standarden, til den samme ressursen i Status200, og kommandoer for den kan nå hvilken som helst av dem. Agenten advarer om dette i loggen sin; gi hver ressurs et unikt navn, både på collectoren og på agenten.

Den autentiserer seg med prosjektets telemetri-inntaksnøkkel (den første som er satt av STATUS200_API_KEY, STATUS200_TELEMETRY_INGESTION_KEY og STATUS200_SERVICE_TOKEN, som collectorene allerede setter) og får sin egen nøkkel. Alle kallene dens er HTTPS-POST-er til <STATUS200_URL>/resource-ai-agent-ingest/…: den registrerer seg én gang ved oppstart, sender et heartbeat hvert 30. sekund (den regnes som tilkoblet i 5 minutter etter det siste), ber om arbeid hvert 3. sekund og melder seg av når den stopper. En annen agent med samme identitet avvises så lenge den første er tilkoblet: en container som stopper ryddig, melder seg av, slik at erstatningen slippes inn med en gang, men etter et krasj eller en kill venter erstatningen til den gamle har vært stille i 5 minutter. Avvises den fortsatt etter 10 minutter, bruker en annen aktiv agent samme identitet: agenten logger en feil som sier det, og spør bare hvert 5. minutt til du gir hver ressurs sitt eget navn eller stopper den andre agenten. Et prosjekt har plass til høyst 250 ressurs-AI-agenter, og høyst 30 nye registrerer seg per time. Når de 250 er nådd, fjernes agenter som ikke har latt høre fra seg på 7 dager, for å gi plass til en ny (ressursen beholder KI-innstillingene sine, og en slik agent som kommer tilbake, registrerer seg ganske enkelt på nytt).

Undersøkelse er slått på for hver ressurs fra starten, så Status200 AI undersøker med agenten så snart den kobler til. Utover det er det KI-en kan gjøre på ressursen, agentens egen innstilling (se Hva KI-en kan gjøre, satt av agenten). En agent som ikke nevner noen av de to innstillingene, bruker standardene sine: den slår på undersøkelse for ressursen sin og setter, hvis den tillater skriving (STATUS200_AI_ALLOW_WRITES=true), Rettelser til Be om godkjenning, ellers til Av. Standardene gjelder bare for en ressurs der ingen har valgt KI-innstillingene på AI-agentens side: innstillinger noen har lagret der, forblir som de er til agentens konfigurasjon nevner dem, så en ressurs der noen har slått av Undersøke-bryteren, forblir av. En agent som er eldre enn disse innstillingene, rapporterer ingen av dem, og AI-agentens side setter dem som før.

Tilbakestill agenten, i den samme menyen ⋯ på AI-agentens side, får Status200 til å glemme agentens nøkkel når du bekrefter; den som hadde den, er låst ute, og den ekte agenten registrerer seg på nytt innen noen få minutter. Agenten trenger en Status200-server med samme versjon som imaget sitt, eller nyere.

Hva KI-en kan gjøre, satt av agenten#

Undersøkelse og rettelser settes der agenten kjører (i .env-filen den deler med collectoren, eller i containerens miljø), og Status200 følger dem:

For eksempel for å la KI-en bruke rettelser der et menneske godkjenner hver enkelt:

STATUS200_AI_INVESTIGATION=true
STATUS200_AI_FIXES=ask-for-approval
STATUS200_AI_ALLOW_WRITES=true

Start deretter agenten på nytt (docker compose up -d, eller kjør collectorens install.sh på nytt med disse satt for en Docker- eller Podman-vert). Agenten rapporterer begge når den registrerer seg og med hvert heartbeat, og Status200 bruker dem på ressursen med en gang. Ressursens AI-agent-side viser dem da skrivebeskyttet: Endre viser disse linjene for alternativet du velger i stedet for å lagre noe, og Status200 avviser en endring som gjøres andre steder (API-et, Terraform, en master-administrator) så lenge agenten setter dem. Listen over tillatte kommandoer blir på siden. En verdi agenten ikke kan lese, holder den innstillingen av, og agenten logger hvilken.

Hva en undersøkelse kan kjøre#

En undersøkelse kjører bare Read-kommandoer: de ser på ressursen og endrer ingenting. Status200 AI ser ressursene som er koblet til hendelsen eller varselet (gjennom monitorene og telemetrien deres, høyst 10 per signal) der AI-agenten er tilkoblet og Undersøke-bryteren er på, og kjører så mange kommandoer som undersøkelsen trenger (opptil 200 per undersøkelse, et vern mot en løpsk løkke), hver sitert som ethvert annet bevis. Hver kommando er ett program med argumentene sine, aldri gjennom et skall, så pipes, omdirigeringer, ;, &&, $(…) og sudo avvises med en melding som sier det. En kommando får 30 sekunder som standard og høyst 2 minutter, og utdataene er begrenset til 1024 KB på agenten. Ingenting av de utdataene kuttes før Status200 AI ser dem: lange utdata vises én side om gangen (de første 40 000 tegnene, deretter resten på forespørsel). Hvis en agent ikke henter en kommando, slutter Status200 AI å sende kommandoer til den ressursen resten av undersøkelsen.

Hva hver ressurstype kan lese, står nedenfor. Det er den samme listen KI-en selv får; alt som ikke står på den, avvises.

Docker- og Podman-verter#

• Containere: docker ps -a (også -q, -n, -l, -s, --no-trunc, --filter, --format json), docker container inspect web, docker inspect --type container web, docker top web, docker port web, docker diff web. Miljøverdier i inspect-utdata kommer maskert tilbake.
• Logger og aktivitet: docker logs --tail 200 web eller docker logs --since 30m web; en --tail på høyst 2000 eller en --since er påkrevd (uten --tail må --since være en varighet på høyst 24h), og -f er aldri tillatt; docker stats --no-stream; docker events --since 30m --until 0s (begge grensene er påkrevd, --until som varighet, slik at vinduet alltid lukkes i fortiden).
• Motoren: docker info, docker version, docker system df (-v bare som tabell: -v --format json skriver ut kommandolinjen for hvert byggetrinn), docker images, docker image inspect nginx:1.27, docker network ls, docker network inspect bridge, docker volume ls, docker volume inspect data.
• Bare --format json (eller table for lister), aldri en Go-mal, og ingen av dockers globale flagg (-H, --context, --config, …): de ville peke CLI-et mot en annen motor.

En Podman-vert kjører det samme docker-CLI-et og den samme policyen gjennom Podmans Docker-kompatible API.

Docker Swarm-klynger#

• Noder: docker node ls, docker node ps node-1, docker node inspect node-1 --pretty.
• Tjenester: docker service ls, docker service ps web --no-trunc, docker service inspect web --pretty (miljøverdier kommer maskert tilbake), docker service logs --tail 200 web (en --tail på høyst 2000 eller en --since er påkrevd, og alene må den være en varighet på høyst 24h; aldri -f).
• Stakker: docker stack ls, docker stack ps shop, docker stack services shop.
• Managerens egen motor: docker ps -a, docker container inspect web, docker logs --tail 200 web, docker stats --no-stream, docker info, docker version, docker network ls og resten av en Docker-verts lesinger.

Proxmox-klynger#

Det finnes ingen pvesh i agenten. En kommando skrives i pvesh-grammatikk (get eller ls og en API-sti, med alternativer som --name value), og agenten gjør den om til nøyaktig én GET til Proxmox VE-API-et med sitt eget token. --output-format json|json-pretty|text velger utdataene; spørrestrenger godtas ikke, og en skriving må nevne noden sin (aldri localhost).

• Klyngen: pvesh get /version, pvesh get /cluster/status, pvesh get /cluster/resources --type vm, pvesh get /cluster/ha/status/current, pvesh get /cluster/log --max 50, pvesh get /cluster/tasks, pvesh get /nodes og listene over replikering, sikkerhetskopier, pools og lagring.
• En node: pvesh get /nodes/pve1/status, pvesh get /nodes/pve1/services, pvesh get /nodes/pve1/storage, pvesh get /nodes/pve1/disks/list, pvesh get /nodes/pve1/rrddata --timeframe hour, pluss nettverket, replikeringen, APT-oppdateringene og Ceph-statusen dens.
• Oppgaver og logger: pvesh get /nodes/pve1/tasks --errors 1 --limit 20, en oppgaves status og logg, pvesh get /nodes/pve1/syslog --limit 200, pvesh get /nodes/pve1/journal --lastentries 200.
• Gjester (qemu for VM-er, lxc for containere): pvesh get /nodes/pve1/qemu, pvesh get /nodes/pve1/lxc, pvesh get /nodes/pve1/qemu/101/status/current, pvesh get /nodes/pve1/qemu/101/config (hemmeligheter som cloud-init-passord kommer maskert tilbake), ventende endringer, øyeblikksbilder, pvesh get /nodes/pve1/qemu/101/rrddata --timeframe hour og informasjon fra QEMU-gjesteagenten som pvesh get /nodes/pve1/qemu/101/agent/get-fsinfo.
• Aldri: noe under /access (brukere, API-tokener, ACL-er), konsoller (vncproxy, termproxy, spiceproxy), QEMU-monitoren, gjesteagentens exec- og filkall.

VMware vCenter#

Kommandoen kommer først, så flaggene, og deretter navn eller inventarstier (govc ignorerer flagg som står etter et argument); -dc DATACENTER velger et datasenter.

• govc about, govc datacenter.info, govc ls /DC/vm, govc find . -type m -runtime.powerState poweredOff: vCenterets versjon og inventar (find filtrerer bare på navn, typer, helse og kjøretidsegenskaper; ls -json avvises fordi den laster inn alle egenskapene til hvert objekt den lister).
• govc vm.info web-01, govc host.info esx-01, govc datastore.info datastore1, govc pool.info /DC/host/cluster1/Resources: strømtilstand, vert, gjeste-OS, IP-adresse, VMware Tools, kapasitet. vm.info er bare tekst: -json og -e avvises fordi de skriver ut VM-ens extraConfig, der cloud-init-data og passord ligger.
• govc events -n 50 /DC/vm/web-01, govc tasks -n 50: nylige hendelser og oppgaver (høyst 500, aldri -f).
• govc metric.sample -n 12 /DC/vm/web-01 cpu.usage.average, govc metric.ls /DC/vm/web-01, govc object.collect -s /DC/vm/web-01 runtime.powerState (bare kjøretids- og helseegenskaper), govc host.service.ls -host esx-01, govc host.date.info -host esx-01, govc tags.ls.
• Aldri: flaggene for tilkobling, påloggingsinformasjon, TLS og feilsøking (-u, -k, -cert, -debug, -dump, …), gjesteoperasjoner (guest.*), filtilgang til datastores, esxcli, env og alle kommandoer som ikke står på listen.

Ceph-klynger#

• Klyngen: ceph status (eller ceph -s), ceph health detail, ceph df detail, ceph versions, ceph progress, ceph quorum_status, ceph log last 100.
• OSD-er: ceph osd tree, ceph osd df, ceph osd perf, ceph osd stat, ceph osd dump, ceph osd blocked-by, ceph osd find 3, ceph osd metadata 3, ceph osd ok-to-stop 3, ceph osd safe-to-destroy 3.
• Pools og placement groups: ceph osd pool ls detail, ceph osd pool stats, ceph osd pool get rbd size, ceph pg stat, ceph pg dump_stuck, ceph pg 1.2f query, ceph pg ls-by-osd 3.
• Daemoner, krasj og cephadm: ceph mon stat, ceph mgr services, ceph mgr module ls, ceph fs status, ceph mds stat, ceph balancer status, ceph crash ls, ceph crash stat, ceph orch ps, ceph orch ls, ceph orch host ls, ceph orch device ls.
• Legg til --format json (eller -f json, json-pretty, plain) for strukturerte utdata. Ingen andre alternativer godtas (aldri -c, --keyring, --id, --admin-daemon, -i, -o eller -w), og auth, config-key, config, tell og daemon kjører aldri.

Databaseservere#

db er ikke et program: det navngir én operasjon fra en fast diagnostisk katalog, som agenten kjører gjennom databasens egen driver i en skrivebeskyttet økt, med en tidsgrense på hver setning. Status200 AI skriver aldri SQL, en Redis-kommando eller MongoDB-skallkode. Flagg finnes bare i lang form (--limit 20 eller --limit=20).

• db ping, db version: om serveren svarer, versjonen og oppetiden.
• db sessions --limit 20 (også --state active, --user, --database; db current-ops er det samme): øktene og hva hver av dem kjører.
• db long-queries --min-seconds 30, db blocking, db locks: trege setninger, og hvem som venter på en lås og hvem som holder den.
• db replication, db connections, db database-sizes, db table-sizes --limit 20, db top-statements --limit 10: replikeringsforsinkelse, tilkoblinger målt mot grensen, hvor plassen og tiden går.
• db settings work_mem (eller alle innstillinger): aldri en innstilling med påloggingsinformasjon som requirepass.
• Motorrapporter: db slowlog, db info memory, db innodb-status, db memory, db keyspace.

Spørringstekst i utdataene normaliseres (hver streng- og tall-literal blir til ?), slik at kundenes data i en setning aldri når Status200.

Verter#

• Tjenester: systemctl status nginx --no-pager -n 50, systemctl is-active nginx, systemctl list-units --failed --no-pager, systemctl list-timers --all, systemctl show nginx -p ActiveState,SubState,Result,NRestarts (-p er påkrevd, og bare egenskaper for unit-tilstanden er tillatt: aldri Environment og aldri en unit-fil).
• Logger: journalctl -u nginx -n 200 --no-pager; hver lesing trenger -n (høyst 2000) eller --since, aldri -f; også -p err, -k, -b, --until, -g, -t, -o short-iso|json; journalctl --list-boots, journalctl --disk-usage.
• Ressurser: uptime, free -m, df -h, df -i, lsblk -f, uname -a, hostnamectl, timedatectl, dmesg -T --level=err,warn.
• Prosesser: ps aux --sort=-%cpu, top -b -n 1 -o %MEM. Passord på kommandolinjer kommer maskert tilbake.
• Nettverk: ss -tulpn, ss -s, ip -br addr, ip route, ip route get 1.1.1.1.
• Kjernetellere: cat /proc/loadavg, cat /proc/meminfo, cat /proc/pressure/memory, cat /etc/os-release; cat leser bare en kort liste over /proc-filer og /etc/os-release, ingenting annet.
• Ett program per kommando, navngitt uten sti: aldri et skall, sudo eller noe annet program.

Slik fungerer rettelser#

Rettelser er slått av til du slår dem på, og det krever to innstillinger på agenten: STATUS200_AI_FIXES satt til en annen modus enn off (se Hva KI-en kan gjøre, satt av agenten) og STATUS200_AI_ALLOW_WRITES=true (se Skrivetilgang på agenten). Én av dem alene endrer ingenting. En agent som er eldre enn STATUS200_AI_FIXES, henter i stedet Rettelser fra ressursens AI-agent-side. Rettelser krever også at KI er aktivert for prosjektet (Aktiver AI under Prosjektinnstillinger → KI → AI Features), noe den er med mindre noen har slått den av.

Rettelsesmoduser#

Rettelser har de samme fire modusene som på en Kubernetes-klynge; STATUS200_AI_FIXES skriver dem som off, ask-for-approval, automatic og bypass-approval:

• Av: KI-en undersøker bare.
• Be om godkjenning: etter rotårsaksanalysen stiller Status200 AI en diagnose med lesekommandoer og setter sammen den minste planen som tar tak i årsaken, for eksempel docker restart web. Planen vises på hendelsen eller varselet med begrunnelse, forventet effekt og tilbakerulling; et menneske godkjenner den med ett klikk, og Status200 kjører nøyaktig de kommandoene.
• Automatisk: sikre endringer (SafeWrite) kjører av seg selv; en mer risikabel endring (RiskyWrite) foreslås for godkjenning, med mindre ressursens liste over tillatte kommandoer nevner den nøyaktige formen.
• Hopp over godkjenning: hver endring policyen tillater, også de mer risikable, kjører av seg selv. Det som alltid trenger et menneske, venter fortsatt på et.

Etter at en rettelse har kjørt, følger Status200 med på monitorene til hendelsen eller varselet. Hvis de ikke kommer seg, kjører planens tilbakerulling, og Status200 AI setter sammen én plan til, med det mislykkede forsøket foran seg: høyst to runder per hendelse eller varsel. I modusen Automatisk ber den andre runden om godkjenning; med Hopp over godkjenning kjører også den av seg selv. Uovervåkede rettelser har en sikring på tre per ressurs per time: utover det, eller mens en annen uovervåket runde fra Status200 AI fortsatt endrer eller verifiserer den samme ressursen, foreslår en runde planen sin for godkjenning i stedet for å kjøre den.

En hendelse eller et varsel får ett KI-rettelsesspor. Når det er koblet til en Kubernetes-klynge med rettelser slått på, kjører klyngens runde og ingen ressursrunde. Ellers får den første koblede ressursen med rettelser slått på og en klar agent runden, i denne rekkefølgen: Docker-vert, Podman-vert, Docker Swarm-klynge, Proxmox-klynge, VMware vCenter, Ceph-klynge, databaseserver, vert. Runden endrer bare den ressursen.

Sikker, mer risikabel og aldri#

Noen mer risikable endringer trenger alltid et menneske i alle moduser, også Hopp over godkjenning, og ingen oppføring på listen over tillatte kommandoer endrer det; de er merket som det i tabellene nedenfor.

Rettelser på Docker- og Podman-verter#

Rettelser på Docker Swarm-klynger#

Rett før en endring kjører, slår AI-agentene for Docker, Podman og Docker Swarm opp målet i motoren og avviser en endring der målet gjør den til mer enn nivået sier: å stoppe eller drepe en container som er startet med --rm (docker ville slette den og de anonyme volumene dens), å starte en stoppet engangscontainer laget av docker compose run (jobben dens ville kjøre på nytt), og enhver oppdatering, skalering eller tilbakerulling av en Swarm-jobbtjeneste (replicated-job eller global-job: hver av dem kjører jobben på nytt). En slik endring overlates til et menneske, uansett hvem som godkjente den.

Rettelser på Proxmox-klynger#

En rettelse er create og en API-sti: én POST til Proxmox VE-API-et. {type} er qemu for en VM og lxc for en container. Agenten følger oppgaven en rettelse starter til den stopper, så en gjest som ikke starter, rapporteres som en mislykket rettelse, med oppgavens logg.

Rettelser på VMware vCenter#

Hver VM navngis nøyaktig (helst med den fullstendige inventarstien, siden govc bruker et bart navn på hver VM som har det, i hvilken som helst mappe) og hver ESXi-vert bare med navnet, siden en sti kan navngi en hel klynge. Ingen jokertegn og ingen referanser til administrerte objekter (vm-42), og flaggene står før navnene.

Rettelser på Ceph-klynger#

Hver rettelse navngir én OSD (3 eller osd.3), PG (1.2f), daemon (slik ceph orch ps lister den), tjeneste eller krasjrapport.

Rettelser på databaseservere#

12345 nedenfor er en økt-ID slik db sessions skriver den ut: PostgreSQL-pid-en, MySQL-processlist-ID-en, Redis-klient-ID-en eller MongoDB-opid-en. Agenten slår først opp økten og rører aldri sin egen tilkobling, en server- eller replikeringstråd eller en økt som ikke finnes.

Rettelser på verter#

Units navngis med fullt navn: systemctl restart nginx starter nginx.service på nytt.

Listen over tillatte kommandoer#

I modusen Automatisk lar ressursens Tillatte kommandoer på AI-agentens side de mer risikable kommandoene du nevner, kjøre uten godkjenning. Listen sammenlignes ord for ord med kommandoen, ikke som tekst:

• * står for nøyaktig ett helt ord (et navn, en ID, en verdi), aldri en del av et ord og aldri ekstra ord eller flagg. docker update --memory * web tillater enhver minnegrense for web; docker stop web-* samsvarer ikke med noe, fordi * aldri står for en del av et ord.
• Hvert ord i kommandoen må stå i oppføringen, flagg inkludert, og oppføringen må ha minst to ord etter programmet. * kan ikke stå for verbet: docker * og docker * web avvises når du lagrer dem.
• En oppføring som aldri kan forhåndsgodkjenne en endring, avvises: en skrivebeskyttet kommando (lesinger trenger aldri godkjenning), en kommando policyen nekter, eller en for en annen ressurstype. En liste har høyst 50 oppføringer på høyst 500 tegn.
• En oppføring med en * der målet står (docker stop * forhåndsgodkjenner å stoppe hver container), ber deg bekrefte før den lagres.
• En Proxmox-sti er ett ord, så den kan ikke inneholde en *: skriv én oppføring per gjest, for eksempel pvesh create /nodes/pve1/qemu/100/status/shutdown.
• Ingenting på listen overstyrer en endring som alltid trenger et menneske, eller en kommando policyen nekter.

Én gyldig oppføring per ressurs: docker stop web (Docker og Podman), docker service update --image nginx:1.27 web (Docker Swarm), pvesh create /nodes/pve1/qemu/100/status/shutdown (Proxmox), govc vm.power -off web-01 (VMware), ceph osd out 3 (Ceph), db terminate-session 12345 (databaser), systemctl stop nginx (verter).

Hvem som kan endre den#

Så lenge agenten setter undersøkelse og rettelser, endres de der den kjører, uansett hvem du er, og det som følger, gjelder bare listen over tillatte kommandoer. For en agent som er eldre enn disse innstillingene og overlater dem til AI-agentens side: å slå på rettelser (enhver overgang fra Av, også til Be om godkjenning) og å løsne dem (bytte til Automatisk eller Hopp over godkjenning, eller legge til en oppføring på listen) krever en Project Owner, en Project Admin eller tillatelsen Edit AI Rule, de samme personene som kan opprette en AI-regel som retter uten å spørre. Tilbakestill agenten krever de samme personene. Å stramme inn (Av, en mindre autonom modus, å fjerne oppføringer fra listen) og Undersøke-bryteren er åpne for alle som kan redigere ressursen, og det samme gjelder Test tilkoblingen og å godkjenne en rettelse som Status200 AI foreslår for den. Alt dette krever tillatelse til å redigere nettopp den ressursen: en tillatelse som er begrenset til bestemte etiketter, eller til ressursene du eller teamene dine eier, når bare de ressursene, og en blokkeringsoppføring med etiketter fjerner ressursene som bærer dem.

Skrivetilgang på agenten#

Uansett hva AI-agentens side sier, avviser agenten selv alle endringer med mindre den ble startet med skrivetilgang. Miljøet dens bestemmer:

Sett dem i .env-filen agenten deler med collectoren (eller i containerens miljø), og start den på nytt med docker compose up -d. En liste med mer enn 64 oppføringer, eller med en oppføring på mer enn 256 tegn, holder agenten skrivebeskyttet til den er rettet.

Agenten rapporterer disse innstillingene til Status200 med hvert heartbeat, så Status200 avviser allerede en rettelse utenfor dem når Status200 AI foreslår den, og igjen når noen godkjenner den; den når aldri agenten som en mislykket rettelse. Agenten avviser den også, før den kjører noe.

Skrivemål per ressurs#

Hva agenten beskytter selv#

Status200 AI endrer aldri agenten selv eller det den kjører i, uansett hva STATUS200_AI_WRITE_TARGETS sier:

• Docker, Podman og Docker Swarm: agentens egen container (etter navn og ID) og Swarm-tjenesten dens, og containerne til Status200s Docker-, Podman- og Docker Swarm-agenter, altså collectorene, Swarm-inventarpolleren og AI-agentene deres. Til agenten har funnet sin egen container, avviser den alle endringer.
• VMware vCenter: VM-en som er oppkalt etter verten i VCENTER_ENDPOINT (og kortnavnet dens), normalt selve vCenter-appliansen, uansett hvilken inventarsti en kommando navngir den med. Agenten kjenner appliansen bare under det navnet: når VCENTER_ENDPOINT er en IP-adresse (agenten advarer da ved oppstart), eller appliansens VM har et annet navn, setter du den VM-en i STATUS200_AI_PROTECTED_TARGETS.
• Databaseservere: agentens egen økt.
• Verter: hver Status200-unit (oneuptime-*, inkludert Verts-AI-agentens egen), OpenTelemetry-collectoren (otelcol-contrib.service, otelcol.service), Docker-motoren den kjører i (docker.service, docker.socket, containerd.service), og agentens egen prosess og prosessene over den.
• Proxmox: agenten kan ikke se hvilken gjest den kjører i. Hvis den kjører i en VM eller container i den samme klyngen, setter du den VMID-en i STATUS200_AI_PROTECTED_TARGETS; gjør det samme med agentens VM på VMware.

Påloggingsinformasjon og minste rettighet#

Agenten bruker bare påloggingsinformasjonen i sitt eget miljø og sine monteringer, for det meste collectorens, fra den samme .env. En jobb som har med seg påloggingsinformasjon, avvises: Status200 sender aldri noe slikt. Uansett hva kommandopolicyen tillater, lar ressursen selv bare agenten gjøre det den påloggingsinformasjonen har lov til, så påloggingsinformasjonen er den harde grensen. Gi undersøkelser en skrivebeskyttet identitet, og rettelser en egen identitet med nøyaktig de rettighetene de trenger.

Collectorenes README-er har de nøyaktige kommandoene: pveum-kommandoene for et Proxmox-token for rettelser ([ProxmoxAgent](<YOUR_STATUS200_URL>/docs/static/scripts/agents/ProxmoxAgent)), vSphere-rollen for rettelser ([VMwareAgent](<YOUR_STATUS200_URL>/docs/static/scripts/agents/VMwareAgent)), Ceph-capsene for lesing og rettelser ([CephAgent](<YOUR_STATUS200_URL>/docs/static/scripts/agents/CephAgent)) og databaserettighetene per motor ([DatabaseAgent](<YOUR_STATUS200_URL>/docs/static/scripts/agents/DatabaseAgent)).

Sikkerhetsmodell#

Tre håndhevingspunkter#

Hver kommando er en argumentliste, aldri en skallinje, og den samme kommandopolicyen (én kopi i Status200, en byte-identisk kopi i agenten) avgjør nivået dens på tre punkter:

1. Status200 AIs verktøy. Undersøkelsesverktøyet avviser alt annet enn en Read; rettelsesverktøyene avviser Denied-kommandoer, bruker modusen, listen over tillatte kommandoer og agentens rapporterte skrivetilgang, og sender en endring som trenger et menneske, til godkjenning.
2. Når Status200 setter den i kø. Hver kommando kontrolleres på nytt: en Denied-kommando avvises, en undersøkelse kan bare sette Reads i kø, ressursen må tilhøre dette prosjektet og agenten dens være tilkoblet, bryteren for undersøkelse eller rettelser må være på, jobben kan ikke ha med seg påloggingsinformasjon, og en endring må passe til agentens rapporterte skrivetilgang. Et prosjekt kan sette høyst 240 undersøkelseskommandoer og 30 rettelseskommandoer i kø per time.
3. På agenten, før noe kjører. Agenten avviser en jobb som ikke er en KI-kommando for dens egen ressurs (identiteten den registrerte seg med, og Status200-ID-en dens), et program ressursen ikke kjører, en kommando dens egen policy nekter eller plasserer høyere enn nivået Status200 sendte, alt annet enn en Read i en undersøkelse, og en endring så lenge STATUS200_AI_ALLOW_WRITES ikke er true, eller utenfor skrivemålene.

Slik kjører en kommando#

• Ett program, som en argumentliste, aldri gjennom et skall: pipes, omdirigeringer, ;, && og $(…) avvises før noe kjører, og det samme gjør sudo.
• Et miljø som bygges for den ene kommandoen: ingenting av agentens eget (verken inntaksnøkkelen eller proxyinnstillingene) når programmet, og docker, govc og ceph får en privat, tom hjemmekatalog under /tmp for den ene kommandoen. docker-CLI-et får en tom privat DOCKER_CONFIG, så ingen kontekst eller credential helper kan endre hvor den peker; govc får påloggingsinformasjonen i miljøet sitt, aldri på kommandolinjen; ceph får agentens egne --conf, --keyring og --id, og en kommando kan ikke velge andre.
• En tidsgrense (høyst 2 minutter), deretter drepes programmet; utdata begrenset til 50 KB.
• Hemmeligheter i utdataene (miljøverdier i docker inspect, Proxmox' cloud-init-passord, nøkler, tokener og passord i logger og kommandolinjer) maskeres på agenten før utdataene forlater den, og igjen av Status200 før de lagres eller vises for modellen.
• Containerne kjører med et skrivebeskyttet rotfilsystem. AI-agentene for Proxmox, VMware, Ceph og databaser kjører som UID 1000 uten capabilities.

Docker-socketen og Verts-AI-agenten er root på verten#

Vær klar over hva to av disse agentene har i hendene:

• Docker- og Podman-socketen er root på verten. Den som kan snakke med den, kan starte en privilegert container som monterer vertens filsystem. Å montere den skrivebeskyttet (:ro) endrer ikke det: en prosess kan fortsatt koble til en socket på en skrivebeskyttet montering, og hvert API-kall går gjennom. På en Docker Swarm-manager styrer socketen hele swarmen. AI-agentene for Docker, Podman og Docker Swarm kjører som root fordi socketen eies av root.
• Verts-AI-agenten er root på verten. Den kjører privilegert, som root, i vertens pid-navnerom, og går inn i vertens navnerom for hver kommando.

Det finnes ingen mer finkornet påloggingsinformasjon for noen av dem, så for disse fire agentene er kommandopolicyen, STATUS200_AI_ALLOW_WRITES og STATUS200_AI_WRITE_TARGETS grensen, ikke kontoen. Policyen kjører aldri exec, run, rm, prune, et skall eller et program utenfor listen sin, og agenten endrer aldri seg selv eller collectoren sin. Hvis det er mer tillit enn du vil gi den, lar du STATUS200_AI_ALLOW_WRITES være usatt (undersøkelser fungerer fortsatt), eller lar være å kjøre agenten på den verten.

Hva Status200 aldri sender#

Status200 sender en agent en kommando (programmet, argumentene og nivået) og ingenting annet. Den sender aldri et passord, et token, en nøkkel eller en tilkoblingsinnstilling; en jobb som har med seg noe slikt, avvises når den settes i kø, når agenten henter den, og av agenten selv. Agentens egen nøkkel utstedes ved registreringen, og bare hashen av den lagres. Status200s API viser en agent bare til personer som kan lese ressursen dens.

Feilsøking#

Logger og status#

Begynn med agentens logg, deretter statusen. Hver agent svarer på port 3877 (Kubernetes-AI-agenten bruker 3876, så begge kan kjøre på én maskin), bare på 127.0.0.1 i sitt eget nettverk (STATUS200_AI_AGENT_HEALTH_HOST=0.0.0.0 tilbyr den på alle grensesnitt, for å publisere porten), med /status/live, /status/ready (ingen av dem venter på Status200) og /status: om den har registrert seg, ressursen den betjener, siste heartbeat og feil, om den når ressursen og hvorfor ikke, og om Status200-en din er for gammel for den:

docker logs --tail 100 status200-docker-ai-agent
docker exec status200-docker-ai-agent wget -qO- http://127.0.0.1:3877/status

Bruk containernavnet for ressursen din: status200-docker-ai-agent, status200-podman-ai-agent (med podman i stedet for docker), status200-docker-swarm-ai-agent, status200-proxmox-ai-agent, status200-vmware-ai-agent, status200-ceph-ai-agent, status200-host-ai-agent. Database-agentens tjeneste har ikke noe fast containernavn, så bruk docker compose logs --tail=100 status200-database-ai-agent og docker compose exec status200-database-ai-agent wget -qO- http://127.0.0.1:3877/status i /opt/status200-database-agent. Verts-AI-agenten bruker vertens nettverk, så curl -s http://127.0.0.1:3877/status fungerer på selve verten.

En manglende innstilling får ikke agenten til å krasje: den holder seg oppe og frisk, sier hva som mangler i loggen sin og i /status, og gjør ikke noe annet, så containeren aldri starter på nytt i en løkke.

Vanlige feil#

README-ene for agentene for [Proxmox](<YOUR_STATUS200_URL>/docs/static/scripts/agents/ProxmoxAgent), [VMware](<YOUR_STATUS200_URL>/docs/static/scripts/agents/VMwareAgent), [Ceph](<YOUR_STATUS200_URL>/docs/static/scripts/agents/CephAgent) og [databaser](<YOUR_STATUS200_URL>/docs/static/scripts/agents/DatabaseAgent), og for [Verts-AI-agenten](<YOUR_STATUS200_URL>/docs/static/scripts/agents/HostAIAgent), har en feilsøkingstabell for sine egne tilkoblingsfeil.

Hva som ikke er dekket#

Kubernetes-klynger bruker Kubernetes-AI-agenten. Serverless-funksjoner og andre skyressurser, IoT-flåter og nettverksenheter har ingen AI-agent: å handle på dem krever påloggingsinformasjon for skyen eller enheten, som Status200 AI bare bruker gjennom en Runner du kjører selv.

Neste steg#