AiHummer ir izstrādāts, lai pabeigtu atbildi pat tad, ja kanāla savienojums īslaicīgi pazūd vai instances darbība tiek restartēta. Šī lapa apraksta redzama uzvedība un darbības, ko administrators vajadzētu veikt. Tas apzināti neprasa, lai jūs saprastu platformas iekšējo piegādes mehānismu.
Ko lietotājiem vajadzētu redzēt
Pēc tam, kad lietotājs nosūta ziņu:
Sesija rāda ziņojumu, kas tika pieņemts.
Aģents to apstrādā un rada vienu redzamu atbildi.
Ja kanāls ir pagaidu nepieejams, piegāde tiek mēģināta atkārtoti.
Kad kanāls atgriežas, atbilde parādās bez lietotāja sūtīšanas
tas pats pieprasījums atkal.
Tāds pats pieprasījums nedrīkst radīt dublētus redzamus atbildes. Ja klients atkal pieslēdzas, tas var atkārtoti ielādēt neseno vēsturi, bet saruna pati par sevi paliek vienā nepārtrauktā sesijā.
Kas notiek pēc restartēšanas
Instanci atjauninājums, resursdatora pārstartēšana vai negaidīta restartēšana nedrīkst padarīt pieņemto pieprasījumu pazudušu. Darbs, ko var droši turpināt, tiek atsākts pēc tam, kad instance kļūst veselīga. Lietotājam jāredz vai nu pabeigtā atbilde, vai skaidra kļūmes stāvoklis, ko var atkārtoti mēģināt.
[!NOTE]
Nepieprasiet pieprasījumu atkārtoti, kamēr instances joprojām atjaunojas.
Vispirms pagaidiet, līdz veselības statuss atgriežas normālā stāvoklī, un atsvaidziniet sesiju.
Tas novērš jaunas patiesi jaunas pieprasījuma izveidi paralēli atjaunojošajam pieprasījumam.
Ja atbilde nenāk
Atvērt Statuss un apstipriniet, ka instances un ietekmētā kanāla ir
vesels.
Atveriet sesiju un atsvaidziniet to vienu reizi.
Pārbaudīt Paziņojumi piegādes vai kanāla brīdinājuma gadījumā.
Nosūtiet īsu jaunu testa ziņojumu tikai pēc tam, kad iepriekšējais pieprasījums ir redzams
veiksmes vai neveiksmes rezultāts.
Ja problēma atkārtojas, ierakstiet laiku, sesiju, kanālu un redzamo kļūdu,
tad sazinieties ar atbalstu. Nekad nelīmējiet API atslēgas vai kanāla noslēpumus biļetē.
Lai veiktu kanāla specifisko atjaunošanu, atveriet attiecīgo rokasgrāmatu zem Kanāli. Piemēram, veselības pārbaudes, skatīt Systemd un veselības pārbaudes.
Ko administratoriem vajadzētu uzraudzīt
Novērojiet lietotājam redzamos rezultātus, nevis īstenošanas detaļas:
atbildes pārstāj sasniegt vienu kanālu, kamēr citi kanāli darbojas;
sesijas ilgstoši turpinās neparasti ilgi;
instances atkārtoti mainās starp veselīgu un nepieejamu;
paziņojumi ziņo par atkārtotām piegādes neveiksmēm;
lietotāji redz dublētās atbildes uz vienu pieņemto pieprasījumu.
Šie simptomi kopā ar to laika zīmēm ir pietiekami, lai atbalsts varētu diagnosticēt problēmu.
AiHummer ir izstrādāts, lai pabeigtu atbildi pat tad, ja kanāla savienojums īslaicīgi pazūd vai instances darbība tiek restartēta. Šī lapa apraksta **redzama uzvedība** un darbības, ko administrators vajadzētu veikt. Tas apzināti neprasa, lai jūs saprastu platformas iekšējo piegādes mehānismu.
## Ko lietotājiem vajadzētu redzēt
Pēc tam, kad lietotājs nosūta ziņu:
1. Sesija rāda ziņojumu, kas tika pieņemts.
2. Aģents to apstrādā un rada vienu redzamu atbildi.
3. Ja kanāls ir pagaidu nepieejams, piegāde tiek mēģināta atkārtoti.
4. Kad kanāls atgriežas, atbilde parādās bez lietotāja sūtīšanas
tas pats pieprasījums atkal.
Tāds pats pieprasījums nedrīkst radīt dublētus redzamus atbildes. Ja klients atkal pieslēdzas, tas var atkārtoti ielādēt neseno vēsturi, bet saruna pati par sevi paliek vienā nepārtrauktā sesijā.
## Kas notiek pēc restartēšanas
Instanci atjauninājums, resursdatora pārstartēšana vai negaidīta restartēšana nedrīkst padarīt pieņemto pieprasījumu pazudušu. Darbs, ko var droši turpināt, tiek atsākts pēc tam, kad instance kļūst veselīga. Lietotājam jāredz vai nu pabeigtā atbilde, vai skaidra kļūmes stāvoklis, ko var atkārtoti mēģināt.
> [!NOTE]
> Nepieprasiet pieprasījumu atkārtoti, kamēr instances joprojām atjaunojas.
> Vispirms pagaidiet, līdz veselības statuss atgriežas normālā stāvoklī, un atsvaidziniet sesiju.
> Tas novērš jaunas patiesi jaunas pieprasījuma izveidi paralēli atjaunojošajam pieprasījumam.
## Ja atbilde nenāk
1. Atvērt **Statuss** un apstipriniet, ka instances un ietekmētā kanāla ir
vesels.
2. Atveriet sesiju un atsvaidziniet to vienu reizi.
3. Pārbaudīt **Paziņojumi** piegādes vai kanāla brīdinājuma gadījumā.
4. Nosūtiet īsu jaunu testa ziņojumu tikai pēc tam, kad iepriekšējais pieprasījums ir redzams
veiksmes vai neveiksmes rezultāts.
5. Ja problēma atkārtojas, ierakstiet laiku, sesiju, kanālu un redzamo kļūdu,
tad sazinieties ar atbalstu. Nekad nelīmējiet API atslēgas vai kanāla noslēpumus biļetē.
Lai veiktu kanāla specifisko atjaunošanu, atveriet attiecīgo rokasgrāmatu zem [Kanāli](/lv/v1.0/webui/channels). Piemēram, veselības pārbaudes, skatīt [Systemd un veselības pārbaudes](/lv/v1.0/operations/systemd-health).
## Ko administratoriem vajadzētu uzraudzīt
Novērojiet lietotājam redzamos rezultātus, nevis īstenošanas detaļas:
- atbildes pārstāj sasniegt vienu kanālu, kamēr citi kanāli darbojas;
- sesijas ilgstoši turpinās neparasti ilgi;
- instances atkārtoti mainās starp veselīgu un nepieejamu;
- paziņojumi ziņo par atkārtotām piegādes neveiksmēm;
- lietotāji redz dublētās atbildes uz vienu pieņemto pieprasījumu.
Šie simptomi kopā ar to laika zīmēm ir pietiekami, lai atbalsts varētu diagnosticēt problēmu.
## Kur uz nākamo
- [Vārteja un pagrieziena dzinējs](/lv/v1.0/architecture/gateway-turn-engine)
- [Novērojamība](/lv/v1.0/operations/observability)
- [Kanāli](/lv/v1.0/webui/channels)
