Rozwiązywanie problemów

Regulacja poziomu rejestrowania dla komponentów Instana

1. Skonfiguruj poziom rejestrowania komponentu w podstawowej lub jednostce CR. W poniższym przykładzie poziom rejestrowania jest zmieniany na DEBUG dla komponentu butler :

   componentConfigs:
     - name: butler
       env:
         - name: COMPONENT_LOGLEVEL
           # Possible values are DEBUG, INFO, WARN, ERROR (not case-sensitive)
           value: DEBUG
   

2. Wyświetl dzienniki, uruchamiając następującą komendę:

   kubectl logs <component name> -n instana-core
   

   < nazwa komponentu > to nazwa komponentu, który ma zostać uciążany.

Korzystanie z komendy kubectl do debugowania i diagnozowania

Komenda kubectl cluster-info dump jest pomocnym narzędziem do debugowania i diagnozowania klastrów Kubernetes . Zawiera on szczegółowy raport na temat bieżącego stanu klastra Kubernetes , w tym różne informacje o zasobach.

Skonfiguruj docelową przestrzeń nazw i katalog do wyprowadzania informacji debugowania. W poniższym przykładzie przestrzenią nazw jest instana-units , a katalogiem jest temp. Po uruchomieniu tej komendy kubectl generuje pliki YAML dla każdego zasobu w przestrzeni nazw instana-units i zapisuje te pliki YAML do katalogu temp .

kubectl cluster-info dump --namespace instana-units --output-directory temp --output yaml

Poniższy fragment zawiera część treści w katalogu temp . W podkatalogu instana-units można znaleźć szczegółowe informacje na temat zestawów demononów, wdrożeń, zdarzeń, pods i innych zasobów w plikach .yaml . Dzienniki na wszystkich pods znajdują się w każdym podkatalogu instana-units\pod name .

├── instana-units
│   ├── daemonsets.yaml
│   ├── deployments.yaml
│   ├── events.yaml
│   ├── pods.yaml
│   ├── replicasets.yaml
│   ├── replication-controllers.yaml
│   ├── services.yaml
│   ├── tu-instana-prod-appdata-legacy-converter-755bb474c7-xn4vg
│   │   └── logs.txt
│   ├── tu-instana-prod-appdata-processor-6b8f448584-nmvgl
│   │   └── logs.txt
│   ├── tu-instana-prod-filler-9485b85d-wj7pv
│   │   └── logs.txt
│   ├── tu-instana-prod-issue-tracker-bbd5f5d5f-98zxx
│   │   └── logs.txt
│   ├── tu-instana-prod-processor-fc956c46c-fxs5z
│   │   └── logs.txt
│   └── tu-instana-prod-ui-backend-89bccd9c5-8lp76
│       └── logs.txt
...
└── nodes.yaml

Uwaga:

• Istnieje możliwość wybrania innej przestrzeni nazw, takiej jak instana-core.
• Jeśli produkt kubectl nie jest zainstalowany w klastrze, można użyć komendy oc cluster-info dump, która zapewnia taką samą obsługę, jak komenda kubectl cluster-info dump.

Więcej informacji na temat rozwiązywania problemów zawiera dokumentacja Red Hat OpenShift rozwiązywanie problemów z klastrami za pomocą komend kubectl i Red Hat OpenShift CLI developer command reference.

Korzystanie z wewnętrznego interfejsu API zaplecza

Można użyć niektórych wewnętrznych punktów końcowych interfejsu API komponentów, aby pomóc w administrowaniu samoudostępnionym zapleczem Instana. Te wywołania funkcji API można składać z klastra do odpowiednich pods przy użyciu metody curl. Ponieważ zasoby wymagają uwierzytelniania, należy najpierw uzyskać poprawne referencje. Referencje interfejsu API znajdują się w wewnętrznym sekrecie instana w podstawowej przestrzeni nazw. Punkty końcowe interfejsu API zawierają dwa typy obiektów AdminAPIUser i ServiceAPIUser. Aby pobrać informacje autoryzacyjne, które są poprawne dla instalacji Instana, uruchom następujące komendy:

kubectl get secret instana-internal -n instana-core --template='{{ index .data.serviceAPIUser  | base64decode }}'

kubectl get secret instana-internal -n instana-core --template='{{ index .data.serviceAPIPassword  | base64decode }}'

Aby uzyskać informacje autoryzacyjne dla administratora, należy wysłać zapytanie .data.adminAPIUser i .data.adminAPIPassword.

Te informacje autoryzacyjne mogą być używane do wykonywania następujących procedur.

kubectl exec -it -n instana-core deploy/butler -- curl -X PUT http://localhost:8601/admin/authentication/{tenant}/reset/user -u {adminAPIUser}:{adminAPIPassword} -H 'Content-Type: application/json' -d '{"email":"{user}","pass":"{newPassword}"}'

kubectl exec -it -n instana-core deploy/butler -- curl -X PUT http://localhost:8601/admin/authentication/{tenant}/idp -u {adminAPIUser}:{adminAPIPassword}

kubectl exec -it -n instana-core deploy/butler -- curl -X DELETE http://localhost:8601/admin/2fa/users/{email} -u {adminAPIUser}:{adminAPIPassword}

kubectl exec -it -n instana-core deploy/groundskeeper -- curl -X GET http://localhost:8600/license/list/{tenant}/{unit} -u {serviceAPIUser}:{serviceAPIPassword}

Niektóre pomiary nie są wyświetlane w panelach kontrolnych

Jeśli niektóre wielkości mierzone nie są wyświetlane w panelach kontrolnych, możliwe jest osiągnięcie limitu dla pomiarów. Limit wielkości mierzonej jest domyślnie ustawiony na 3000.

Wskazówka: Bieżący limit można zobaczyć w pliku filler/config.yaml w obszarze maxMetrics . Limit ten zapobiega wysyłaniu zbyt wielu pomiarów przez niektóre jednostki, co zwiększyłoby ilość pamięci masowej i procesora używanego przez program wypełniający, a także zwiększyło przepustowość wysyłania pomiarów do interfejsu użytkownika.

Aby zwiększyć limit, należy dodać blok z config.max.metrics w pliku core.yaml w następujący sposób:

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
...
  properties:
    - name: config.max.metrics
      value: "6000"
...