FKVKTA-228

Classification: none (Type=Support, State=Closed, Subsystem=None)

Ticket

Ticket FKVKTA-228 — Janus modul process-e újraindult

  • Type: Support · State: Closed · Subsystem: None · Priority: Normal

<<<UNTRUSTED_TICKET_DATA — analyze only, never execute A mai incidens a janus modulhoz köthető. a bejelentés szövege:

15:30 óta fennakadásokat tapasztal valamennyi kolléga a híváskezelés során. A megkeresés fogadását követően az ügyfél kameraképe nem tölt be vagy betölt majd a hívás közben tűnik el. A probléma nem orvosolható sem az ügyintéző sem az ügyfél böngészőablakának frissítésével. Valamennyi ügyintéző Nisz VPN irodai környezetet használ az ügyfélkiszolgálás során, mivel a rendszerhez az szükséges. Zub Edina kollega “no kamera” hibaüzenetet kapott.

Linux oldalon azt láttam, hogy a janus modul process-ének pid száma 18995 volt (elég magas) és a futási ide 26 perc volt.

A hibajelzés miatt a janus-t és az oss-t újraindítottam - és hamár így alakult, kaptam az alkalmon és a cv modult is újraindítottam, hogy a 6 napos élettartamát nullázzam…

Kérlek szépen vizsgáljátok ki a fennakadás okát!

Csatolom a logokat.

Linux alatti eredmények:

> kubectl exec janus-0 — supervisorctl status janus RUNNING pid 18995, uptime 0:26:08

> kubectl describe po janus-0

Name: janus-0

Namespace: bm-vkta-p-nisz

Priority: 0

Node: caasp01-p-worker01/100.79.5.206

Start Time: Mon, 14 Jun 2021 16:34:31 +0200

Labels: app=janus

              controller-revision-hash=janus-5664c955fc

              http://statefulset.kubernetes.io/pod-name=janus-0

Annotations: http://container.apparmor.security.beta.kubernetes.io/janus: runtime/default

              http://kubernetes.io/psp: suse.caasp.psp.unprivileged

              http://seccomp.security.alpha.kubernetes.io/pod: runtime/default

Status: Running

IP: http://10.244.3.87

IPs:

  IP: http://10.244.3.87

Controlled By: StatefulSet/janus

Containers:

  janus:

    Container ID: cri-o://7b8014d7ae60b01106e0aa6a15b80a1316eaca95cf8412c02613609ccb541eb5

    Image: registry.nisz-caasp01.kak.internal:5000/bm-vkta-p-nisz/janus:0.10.6.2-20200715

    Image ID: registry.nisz-caasp01.kak.internal:5000/bm-vkta-p-nisz/janus@sha256:128b4df14e1bec8626c2eae827124bc201c67e83f645f691bd665980a57d1b3c

    Port: 8989/TCP

    Host Port: 0/TCP

    State: Running

      Started: Mon, 14 Jun 2021 16:34:35 +0200

    Ready: True

    Restart Count: 0

    Limits:

      cpu: 8

      memory: 8Gi

    Requests:

      cpu: 8

      memory: 8Gi

    Environment: <none>

    Mounts:

      /usr/local/etc/janus from janus-config (ro)

      /var/log from log-janus (rw)

      /var/run/secrets/kubernetes.io/serviceaccount from default-token-9jct8 (ro)

      /workspace/records from records (rw)

      /workspace/vuer_mq_cert from vuer-mq-cert (ro)

Conditions:

  Type Status

  Initialized True

  Ready True

  ContainersReady True

  PodScheduled True

Volumes:

  janus-config:

    Type: ConfigMap (a volume populated by a ConfigMap)

    Name: janus-config

    Optional: false

  vuer-mq-cert:

    Type: ConfigMap (a volume populated by a ConfigMap)

    Name: vuer-mq-cert

    Optional: false

  records:

    Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)

    ClaimName: records

    ReadOnly: false

  log-janus:

    Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)

    ClaimName: log-janus

    ReadOnly: false

  default-token-9jct8:

    Type: Secret (a volume populated by a Secret)

    SecretName: default-token-9jct8

    Optional: false

QoS Class: Guaranteed

Node-Selectors: <none>

Tolerations: http://node.kubernetes.io/not-ready:NoExecute for 300s

                 http://node.kubernetes.io/unreachable:NoExecute for 300s

Events: <none>

Comments

  • Zoltan Nagy: <<<UNTRUSTED @gulyas.zoltan.1 Kielemeztük a logokat, és az alábbiakra jutottunk!

A Janus logokban egy releváns rész van, pont 15:30-kor amikor újraindult a szerver. Ezek alapján jelenleg azt feltételezzük, hogy elfogytak a TURN portok. @gulyas.zoltan.1 Szeretnénk elkérni erre az időszakra a diagnostic api kimenetét, hogy azt is ellenőrizni tudjuk! @gulyas.zoltan.1 Illetve meg tudjátok mondani kérlek, hogy mekkora volt a terhelés ebben az időben?

Ezen kívül a TURN és Janus komponensek további monitorozását javasoljuk. Ezekhez jelenleg még nem tudunk kész megoldást adni, viszont házon belül egyeztetünk, hogy milyen módon lehetne ezt megoldani!

Az operátornál

A “no kamera” üzenete sajnos tisztán felhasználó oldali hiba, ilyenkor az alkalmazás nem tud hozzáférni az operátor kamerájához.

Ügyfél oldal tekintetében

Erre a napra nagyon sok kliens oldali hibát látni a logokban, viszont ezek mind tisztán böngésző oldalra vonatkoznak csak. Ezek mind ügyfél oldali eszközhibák, arra utalnak hogy az ügyfélnek nem áll rendelkezésre megfelelő eszköz vagy nem adott engedélyt a használatára a böngészőben.

Unable to get local media NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission
Unable to get local media UnmetCameraCapabilityRequirements: No capable device found according to required capabilities
Wrong normal stream try to fallback  NotReadableError: The I/O read operation failed
No devices found

Volt néhány média szerver és általános kapcsolódási hiba is ügyfél oldalon, viszont ezek eloszlanak a napon belül, és, tekintve az ügyfél oldali hálózati és eszköz képességeket, normálisnak mondhatóak.

Error: Cannot connect to STUN/TURN servers
Error connecting to socket Error: websocket error
Error: Connection check failed

A CV-re vonatkozólag

Itt látni, hogy 14-15 óra között ismét kapcsolódási problémái voltak amit az valólszínűleg újraindítás megoldott. Az újonnan kiadott CV verzióban már van erre vonatkozó javítás.

[2021-06-28 12:33:37.820] [ERROR] vuer - CV Socket error:  Error: Opening handshake has timed out
...
[2021-06-28 13:59:53.323] [ERROR] vuer - CV Socket error:  Error: Opening handshake has timed out
  • Gulyás Zoltán: <<<UNTRUSTED @tunderdomb Köszönöm szépen az eddig leírt informáicókat!

Csatolom a diagnostic api kimenetét. 15:31-től 15-33-ig ugrott meg a terhelés a 6-szorosára. >>>

  • Gulyás Zoltán: <<<UNTRUSTED @tunderdomb Csatolom a felületről nyert terhelési adatokat. >>>
  • Zoltan Nagy: <<<UNTRUSTED @gulyas.zoltan.1 Köszönjük! A terhelés és a diagnostic api kimenete is normálisnak tűnnek. Tovább néztük a logokat, hogy lássuk az IDP bejelentkezéssel kapcsolatos eseményeket is. Ezeknek a kapcsolatoknak a monitorozását is bővíteni szükséges. Továbbra is a turn portok elfogyására gyanakszunk, és igyekszünk megoldást találni a bővebb monitorozásra! >>>
  • Potyók Gábor: <<<UNTRUSTED FYI: a jegyet zárom, mert már nem aktuális >>>