sqlinsight-pro/docs/syntetiske-tjek.md

Syntetiske tjek

Et syntetisk tjek gør det, en bruger eller en applikation gør – forbinder til AOS-porten, henter en side, logger på SQL Server og kører en forespørgsel, slår et navn op, logger på Dynamics AX – med jævne mellemrum, fra agentens server og som agentens konto. Så opdages det også, når en applikationsserver ikke svarer på det syntetiske tjek, selv om tjenesten kører: noget, en tjenesteovervågning alene aldrig ser.

Tjekkene oprettes under Servere → Syntetiske tjek i webbrugerfladen eller med API'et (se nedenfor). Agenten kører dem inden for et minut efter oprettelsen og derefter efter tjekkets interval (standard hvert 5. minut, mindst hvert minut). Kør nu kører et tjek med det samme. Intet tjek ændrer noget på de servere, det tjekker.

Typer

Type	Hvad agenten gør	Succes
TCP-port	Åbner en TCP-forbindelse til server:port (fx AOS'en på 2712)	Porten svarer
HTTP(S)	GET på adressen, følger op til 5 omdirigeringer, eventuelt som agentens Windows-konto (Enterprise Portal, Reporting Services)	Status 200–399 eller de forventede koder, og eventuelt en forventet tekst i de første 1 MB
SQL-login og forespørgsel	Logger på SQL Server (agentens Windows-konto eller et SQL-login), skifter eventuelt database og kører forespørgslen (standard SELECT 1)	Login og forespørgsel lykkes; svartiden måles for login og forespørgsel hver for sig
DNS-opslag	Slår navnet op	Navnet giver adresser (og en af de forventede, hvis de er angivet)
Dynamics AX-logon	Tester AOS-porten, og logger derefter på AX gennem .NET Business Connector, hvis den er installeret på agentens server	Se nedenfor

HTTPS: certifikatets udløbsdato læses ved hvert tjek – også når certifikatet afvises. Et selvsigneret certifikat kan accepteres med Accepter ugyldigt certifikat; udløbsdatoen tjekkes stadig.

SQL: forespørgslen skal være én skrivebeskyttet SELECT (samme regler som community-reglerne, se regler.md): ingen INSERT, UPDATE, EXEC, INTO osv. Det tjekkes, når tjekket gemmes, og igen, før det køres, og forespørgslen køres i en transaktion, der altid rulles tilbage, med READ UNCOMMITTED og LOCK_TIMEOUT 5000. Standardforespørgslen virker på SQL Server 2005 og nyere. Det præcise SQL står i SQL Scripts/SQLI-SYN-001.sql.

Dynamics AX-logon

Tjekket gør sit bedste:

1. AOS-porten (standard 2712) skal svare. Gør den ikke, fejler tjekket.
2. Er .NET Business Connector (AX 2009 eller AX 2012) installeret på agentens server, logger agenten på AX gennem den – i en separat Windows PowerShell-proces med timeout (Business Connector er en .NET Framework-komponent og kan ikke indlæses i agenten) – og logger straks af igen. Der logges på som agentens Windows-konto, som derfor skal være oprettet som bruger i AX (i det angivne firma); der gemmes ingen adgangskode. Agenten læser intet i AX.
3. Er Business Connector ikke installeret (eller logon-testen slået fra), testes kun porten, og resultatet siger det tydeligt: "Kun porten er testet: .NET Business Connector (AX 2009/2012) er ikke installeret på agentens server, så et AX-logon kan ikke prøves."

Business Connector findes, hvor AX-installeren lægger den (…\Microsoft Dynamics AX\60\BusinessConnector\Bin, …\50\Client\Bin), eller hvor SQLInsight:SyntheticChecks:BusinessConnectorPath peger. AX 2009's Business Connector er bygget til .NET 2.0 og kræver Windows PowerShell 2.0-motoren (.NET Framework 3.5) på agentens server; mangler den, siger resultatet det. Object server angives som i AX-klientens konfiguration (fx 01@aos01:2712); standard er server:port. Et logon optager kortvarigt en AX-session.

Kør agenten som en gMSA eller domænekonto, hvis AX-logon skal testes: computerkontoen DOMÆNE\AGENTSERVER$ kan normalt ikke oprettes som AX-bruger.

Tjeneste bag tjekket

Et tjek kan knyttes til en Windows-server (se windows-servere.md) og en tjeneste på den, fx AOS'en AOS60$01 eller IIS W3SVC. Fejler tjekket, slår agenten tjenestens tilstand op, og fundet siger forskellen:

• "AOS01 AX-logon svarer ikke, selv om tjenesten AOS60$01 kører" – tjenesten hænger, er overbelastet, venter på databasen eller er blokeret af en firewall.
• "AOS01 AX-logon svarer ikke: tjenesten AOS60$01 er stoppet".

Tjenesten læses med de samme rettigheder som Windows-serverne (Service Control Manager).

Adgangskoder

Et SQL-login's adgangskode krypteres i webbrugerfladen i det øjeblik, den modtages, med agentens offentlige nøgle – præcis som i 1.3 (se servere-og-databaser.md). Kun agenten kan læse den; den vises aldrig igen og returneres aldrig af API'et (kun hasPassword). Den er bundet til server, port og login: ændres de, skal den indtastes igen. Kan agenten ikke bruge den (fx efter en geninstallation), siger tjekket det, og den indtastes igen. HTTP-, TCP-, DNS- og AX-tjek bruger ingen adgangskoder.

Regler

Regel	Fund	Tærskel
SQLI-SYN-001	Tjekket fejler (Høj) – med tjenestens tilstand, når den kendes	SQLInsight:SyntheticChecks:FailuresBeforeFinding 2 fejl i træk
SQLI-SYN-002	Tjekket svarer langsomt (Middel)	tjekkets Langsomt svar over (ms); SlowRunsBeforeFinding 3 gange i træk
SQLI-SYN-003	TLS-certifikatet udløber (Middel; Høj inden for CertificateCriticalDays 7; Kritisk når udløbet)	CertificateWarningDays 21

Ét tabt svar giver ingen alarm; to i træk gør. Fundet løses, når tjekket lykkes igen. Fund vises på tjekkets side og sammen med serverfundene, sendes som notifikationer og findes i API'et.

Firewall

Fra agentens server: de porte, tjekkene bruger (fx TCP 2712 til AOS'en, 80/443 til HTTP(S), 1433 eller instansens port til SQL Server, 53 til DNS). Tjenestens tilstand: som Windows-serverne (WinRM TCP 5985 eller DCOM/RPC).

Opbevaring og konfiguration

Hver kørsel gemmes i 14 dage (SQLInsight:SyntheticChecks:ResultDays). Højst MaxParallelChecks (standard 4) tjek kører samtidig. Timeout pr. tjek er standard 15 sekunder (AX-logon 60), højst 120.

"SyntheticChecks": {
  "Enabled": true,
  "MaxParallelChecks": 4,
  "FailuresBeforeFinding": 2,
  "SlowRunsBeforeFinding": 3,
  "CertificateWarningDays": 21,
  "CertificateCriticalDays": 7,
  "ResultDays": 14,
  "BusinessConnectorPath": null
}

API

Kald	Svar
GET /api/v1/synthetic-checks	Tjek med seneste resultat
POST /api/v1/synthetic-checks	Opret: name, kind (Tcp, Http, Sql, Dns, AxLogon), serverId, intervalSeconds, timeoutSeconds, settings, password; 201 med runRequestId
GET, PUT, PATCH, DELETE /api/v1/synthetic-checks/{id}	Ét tjek; ret (typen kan ikke ændres); pause; fjern
POST /api/v1/synthetic-checks/{id}/run	Kør nu (202, følg GET /api/v1/agent-requests/{id})
GET /api/v1/synthetic-checks/{id}/results?hours=24	Kørsler med svartid, certifikat og tjenestens tilstand
GET /api/v1/synthetic-checks/{id}/rule-states	Reglernes udfald

settings har felterne for typen: host, port, url, expectedStatus, expectedText, useWindowsAuthentication, allowInvalidCertificate, server, database, authentication (Windows/SqlLogin), userName, encryption, trustServerCertificate, query, expectedAddresses, company, objectServer, configuration, businessConnectorLogon, serviceName, warnMilliseconds.

$h = @{ Authorization = "Bearer $token" }
$body = @{ name = 'AOS01 AX-logon'; kind = 'AxLogon'; serverId = 3; settings = @{ host = 'aos01'; company = 'DAT'; serviceName = 'AOS60$01' } } | ConvertTo-Json
Invoke-RestMethod https://sqlinsight.domæne.local/api/v1/synthetic-checks -Method Post -Headers $h -Body $body -ContentType 'application/json'

Fejlbeskeder kan nævne logins og servere: for fejlede kørsler er beskeden og følsomme målinger [udeladt] i API'et, medmindre SQLInsight:Web:ApiIncludesSensitiveEvidence er slået til. At ændre kræver scope config:write eller SQLInsight:Web:AdminGroups.