# 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](#api)). 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](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`](../SQL%20Scripts/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](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](servere-og-databaser.md#sql-login-adgangskoder)). 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.

```json
"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`.

```powershell
$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`.