mirror of https://github.com/istio/istio.io.git
50 lines
4.2 KiB
Markdown
50 lines
4.2 KiB
Markdown
---
|
||
title: Проблеми з спостереженням
|
||
description: Вирішення проблем зі збором телеметрії.
|
||
force_inline_toc: true
|
||
weight: 30
|
||
aliases:
|
||
- /uk/docs/ops/troubleshooting/grafana
|
||
- /uk/docs/ops/troubleshooting/missing-traces
|
||
owner: istio/wg-policies-and-telemetry-maintainers
|
||
test: n/a
|
||
---
|
||
|
||
## В Zipkin не зʼявляються трейси при запуску Istio локально на Mac {#no-traces-appearing-in-zipkin-when-running-istio-locally-on-mac}
|
||
|
||
Istio встановлено, і все здається працює, але в Zipkin не зʼявляються трейси, хоча повинні бути.
|
||
|
||
Це може бути викликано відомою [проблемою Docker](https://github.com/docker/for-mac/issues/1260), коли час всередині контейнерів може суттєво відрізнятися від часу на хост-машині. Якщо це так, коли ви вибираєте дуже довгий інтервал дат у Zipkin, ви побачите, що трейси зʼявляються на кілька днів раніше.
|
||
|
||
Ви також можете підтвердити цю проблему, порівнявши дату всередині Docker-контейнера з датою за його межами:
|
||
|
||
{{< text bash >}}
|
||
$ docker run --entrypoint date gcr.io/istio-testing/ubuntu-16-04-slave:latest
|
||
Sun Jun 11 11:44:18 UTC 2017
|
||
{{< /text >}}
|
||
|
||
{{< text bash >}}
|
||
$ date -u
|
||
Thu Jun 15 02:25:42 UTC 2017
|
||
{{< /text >}}
|
||
|
||
Щоб розвʼязати цю проблему, вам потрібно вимкнути та перезапустити Docker перед повторним встановленням Istio.
|
||
|
||
## Відсутній вивід Grafana {#missing-grafana-output}
|
||
|
||
Якщо ви не можете отримати вивід Grafana при підключенні з локального вебклієнта до віддалено розгорнутого Istio, слід перевірити, чи збігаються дати та час клієнта та сервера.
|
||
|
||
Час вебклієнта (наприклад, Chrome) впливає на вивід Grafana. Просте розвʼязання цієї проблеми — перевірити, чи працює сервіс синхронізації часу коректно в кластері Kubernetes та чи використовує машина вебклієнта також коректну службу синхронізації часу. Деякі поширені системи синхронізації часу — це NTP та Chrony. Це особливо проблематично в інженерних лабораторіях з брандмауерами. У таких випадках NTP може бути некоректно налаштований для роботи з лабораторними сервісами NTP.
|
||
|
||
## Перевірте, чи працюють podʼи Istio CNI (якщо використовуються) {#verify-istio-cni-pods-are-running-if-used}
|
||
|
||
Втулок Istio CNI виконує перенаправлення трафіку podʼів Istio mesh у фазі налаштування мережі життєвого циклу podʼа Kubernetes, таким чином усуваючи [необхідність для можливостей `NET_ADMIN` та `NET_RAW`](/docs/ops/deployment/application-requirements/) для користувачів, які розгортають podʼи в Istio mesh. Втулок Istio CNI замінює функціональність, що надається контейнером `istio-init`.
|
||
|
||
1. Перевірте, що podʼи `istio-cni-node` працюють:
|
||
|
||
{{< text bash >}}
|
||
$ kubectl -n kube-system get pod -l k8s-app=istio-cni-node
|
||
{{< /text >}}
|
||
|
||
2. Якщо в вашому кластері застосовується `PodSecurityPolicy`, переконайтеся, що службовий обліковий запис `istio-cni` може використовувати `PodSecurityPolicy`, яка [дозволяє можливості `NET_ADMIN` та `NET_RAW`](/docs/ops/deployment/application-requirements/).
|