IBM Bob

Operacje i rozwiązywanie problemów

Monitoruj, utrzymuj i rozwiązuj problemy z wdrożeniami bramy modelu, w tym aktualizacje konfiguracji modelu, rotację danych uwierzytelniających, monitorowanie kondycji, zbieranie dzienników i rozwiązywanie typowych problemów z łącznością i uwierzytelnianiem.

Po wdrożeniu bieżące zarządzanie operacyjne bramy modelu pomaga zapewnić niezawodny dostęp do skonfigurowanych modeli AI i minimalizuje zakłócenia usług. Administratorzy mogą przeglądać aktywne konfiguracje modeli, aktualizować dane uwierzytelniające dostawców, rotować sekrety, monitorować kondycję bramy i zbierać informacje diagnostyczne w przypadku wystąpienia problemów.

Przeglądanie skonfigurowanych modeli

Przeglądanie modeli odbywa się na dwóch poziomach — co jest w konfiguracji i co bob-inference faktycznie załadował w czasie uruchamiania.
  • Poziom konfiguracji — pobierz bieżącą konfigurację bramy modelu z ConfigMap wnioskowania: 
    oc get cm bob-inference-config -n <bob-namespace> -o yaml | yq '.data."config.yaml"'
    •
  • Poziom uruchamiania — co bob-inference zarejestrował i aktywnie do czego kieruje: 
    oc exec -n <bob-namespace> deploy/bob-gateway -- \
  curl -sk https://bob-inference.<bob-namespace>.svc.cluster.local:7330/v1/model/info | jq .
    •
Uwaga:

Punkt końcowy /v1/model/info w czasie uruchamiania wyświetla tylko modele z exposed: true. Plik konfiguracyjny jest jedynym sposobem na wyświetlenie pełnego zestawu skonfigurowanych modeli.

Aktualizowanie danych uwierzytelniających dostawców

Dane uwierzytelniające są przechowywane w sekcji bob.modelGateway.secrets w config.yaml. Użyj bobctl update-model-config --update-secrets, aby przesłać zaktualizowane dane uwierzytelniające do klastra.

Aktualizacja danych uwierzytelniających

Zaktualizuj dane uwierzytelniające w config.yaml w sekcji bob.modelGateway.secrets.

Przesłanie zaktualizowanego sekretu do klastra

bobctl update-model-config --update-secrets

Operator ibm-bob uzgadnia wdrożenie bob-inference i automatycznie montuje nowy sekret.

Wskazówka:

Jeśli aktualizujesz jednocześnie plik konfiguracyjny modelu i dane uwierzytelniające, możesz przesłać oba za pomocą jednego polecenia:

bobctl update-model-config --model-config ./my-model-config.yaml --update-secrets

Rotacja sekretów

Rotacja sekretów przebiega według tego samego wzorca co aktualizacja danych uwierzytelniających, z dodatkową dbałością o czas, aby uniknąć przestojów.

Zalecana sekwencja rotacji bez przestojów:
  1. Zaktualizuj bob.modelGateway.secrets w config.yaml nową wartością danych uwierzytelniających.
    2.
  2. Prześlij nowy sekret do klastra: bobctl update-model-config --update-secrets.
    3.
  3. Uruchom ponownie usługę Inference Service, aby zastosować nowy sekret: 
    oc rollout restart deploy/inference-service -n <bob-namespace>
    4.
  4. Potwierdź, że nowe dane uwierzytelniające działają, używając testu wnioskowania z artykułu Weryfikacja po instalacji.
    5.
  5. Unieważnij stare dane uwierzytelniające po stronie dostawcy dopiero po potwierdzeniu kondycji wdrożenia.
    6.

Uwagi specyficzne dla dostawców:
  • openai_compatible / klucze API — nowy klucz obowiązuje natychmiast po aktualizacji sekretu. Bezpiecznie jest unieważnić stary klucz po potwierdzeniu kondycji wdrożenia.
    •
  • bedrock — upewnij się, że nowy klucz dostępu IAM jest aktywny w AWS przed uruchomieniem update-model-config. Propagacja IAM może potrwać kilka sekund.
    •
  • vertex — wygeneruj i zakoduj w base64 nowy klucz konta usługi, zaktualizuj config.yaml, uruchom bobctl update-model-config --update-secrets, zweryfikuj, a następnie usuń stary klucz w GCP.
    •
  • ca_cert_pem — podczas odnawiania certyfikatu sprawdź, czy nowy certyfikat nie wygasł, przed zastosowaniem. Zobacz Weryfikacja certyfikatu TLS.
    •

Monitorowanie kondycji bramy

Liczba restartów podów — rosnąca liczba restartów to wczesny sygnał powtarzającej się awarii uruchamiania (zły montaż sekretu, błąd parsowania konfiguracji):

 
oc get pods -n <bob-namespace> -l app=bob-inference \
  -o custom-columns='NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount'

Sondy liveness i readiness — sprawdź bieżącą konfigurację i status sond:

 
oc describe deploy/bob-inference -n <bob-namespace> | grep -A 10 "Liveness\|Readiness"

Okresowe sprawdzanie kondycji — punkt końcowy /v1/model/info służy jako prosta kontrola liveness. Jeśli zwraca prawidłową listę modeli, brama działa. Można go odpytywać z narzędzia monitorującego lub zadania cron wewnątrz klastra.

Zbieranie dzienników i diagnostyki

Dzienniki dla określonego okna czasowego (najbardziej przydatne podczas badania zgłoszonego incydentu):

 
oc logs -n <bob-namespace> deploy/bob-inference \
  --since-time="2025-01-01T12:00:00Z" > bob-inference.log

Dzienniki z poprzedniej instancji poda (jeśli pod był restartowany i dzienniki awarii zniknęły):

 
oc logs -n <bob-namespace> deploy/bob-inference --previous

Pełny pakiet diagnostyczny dla wsparcia:

 
oc describe pod -n <bob-namespace> -l app=bob-inference >> diagnostics.txt
oc get events -n <bob-namespace> --sort-by='.lastTimestamp' >> diagnostics.txt
oc logs -n <bob-namespace> deploy/bob-inference --since=1h >> diagnostics.txt
Uwaga:

Pakiet diagnostyczny zawiera nazwy zmiennych środowiskowych podów, ale nie wartości sekretów (sekrety są montowane, a nie drukowane w dziennikach). Przejrzyj dzienniki pod kątem przypadkowego wyjścia danych uwierzytelniających przed wysłaniem do wsparcia.

Rozwiązywanie problemów z łącznością i uwierzytelnianiem

Model nie pojawia się w /v1/model/info
  1. Sprawdź, czy ustawiono exposed: false — jeśli tak, to oczekiwane zachowanie.
    2.
  2. Sprawdź dzienniki startowe pod kątem błędu rejestracji dla tej wartości model_name.
    3.
  3. Zweryfikuj blok dostawcy — prawidłowy base_url, ID model i dane uwierzytelniające.
    4.

401 Unauthorized przy żądaniach wnioskowania
  1. Potwierdź, że wartość sekretu w bob.modelGateway.secrets jest prawidłowa i aktualna.
    2.
  2. Potwierdź, że odwołanie env.<VAR> w konfiguracji modelu dokładnie odpowiada nazwie klucza sekretu (rozróżniana jest wielkość liter).
    3.
  3. Uruchom ponownie usługę wnioskowania i spróbuj ponownie — sekret mógł zostać zaktualizowany bez restartu.
    4.
  4. Przetestuj dane uwierzytelniające poza pasmem. Zobacz Weryfikacja uwierzytelniania.
    5.

502 Bad Gateway lub connection refused
  1. Potwierdź, że punkt końcowy modelu jest dostępny z klastra. Zobacz Testowanie łączności.
    2.
  2. Sprawdź problemy z base_url — końcowe ukośniki, nieprawidłowy schemat (http vs https), nieprawidłowy port.
    3.
  3. Sprawdź zmiany zasad sieciowych, które mogły zablokować ruch wychodzący od czasu instalacji.
    4.

certificate signed by unknown authority
  1. Potwierdź, że ca_cert_pem jest ustawiony i odwołuje się do prawidłowej zmiennej środowiskowej.
    2.
  2. Potwierdź, że zmienna środowiskowa jest obecna w bob.modelGateway.secrets.
    3.
  3. Sprawdź, czy certyfikat nie wygasł: openssl x509 -noout -dates.
    4.
  4. Potwierdź, że certyfikat obejmuje nazwę hosta punktu końcowego, sprawdzając Subject Alternative Names.
    5.

Pod usługi wnioskowania w stanie CrashLoopBackOff
  1. Sprawdź dzienniki z poprzedniej instancji: oc logs --previous.
    2.
  2. Szukaj błędów parsowania konfiguracji — nieprawidłowy YAML w konfiguracji bramy modelu.
    3.
  3. Szukaj brakujących montowań sekretów w sekcji Events: oc describe pod.
    4.
  4. Sprawdź, czy YAML konfiguracji bramy modelu jest prawidłowy przed ponownym zastosowaniem.
    5.
Jak oceniasz ten temat?

Na tej stronie

Przeglądanie skonfigurowanych modeliAktualizowanie danych uwierzytelniających dostawcówAktualizacja danych uwierzytelniającychPrzesłanie zaktualizowanego sekretu do klastraRotacja sekretówMonitorowanie kondycji bramyZbieranie dzienników i diagnostykiRozwiązywanie problemów z łącznością i uwierzytelnianiem