mirror of https://github.com/istio/istio.io.git
zh: switch to discuss.istio.io (#3079)
* zh: switch to discuss.istio.io Refer to https://github.com/istio/istio.io/pull/3071 * Replace 跟踪 with 追踪 * Fix yaml format
This commit is contained in:
Jimmy Song
istio-bot
parent
78ef1282a2
commit
303ae56378
|
|
@ -129,7 +129,7 @@ title: Istio
|
|||
<h5 class="card-title text-center">观测</h5>
|
||||
<hr class="card-line">
|
||||
<p class="card-text">
|
||||
通过丰富的自动跟踪、监控和记录所有服务，了解正在发生的情况。
|
||||
通过丰富的自动追踪、监控和记录所有服务，了解正在发生的情况。
|
||||
</p>
|
||||
</div>
|
||||
</a>
|
||||
|
|
|
|||
|
|
@ -15,9 +15,7 @@ Istio 是一个开源项目，拥有一个支持其使用和持续开发的活
|
|||
<tr>
|
||||
<td class="logo"><img src="/about/community/join/discourse.svg" alt="Discourse"/></td>
|
||||
<td class="desc">
|
||||
Head for the <a href="https://discuss.istio.io">Istio discussion board</a> to participate in
|
||||
discussions
|
||||
and get help troubleshooting problems.
|
||||
前往 <a href="https://discuss.istio.io">Istio discussion board</a> 参与讨论获取帮助。
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -51,7 +49,7 @@ Istio 是一个开源项目，拥有一个支持其使用和持续开发的活
|
|||
<td class="logo"><img src="/about/community/join/group.svg" alt="Working Groups"/></td>
|
||||
<td class="desc">
|
||||
如果您想参与 Istio 项目，请考虑加入我们的
|
||||
<a href="https://github.com/istio/community/blob/master/WORKING-GROUPS.md">工作组 </a>。
|
||||
<a href="https://github.com/istio/community/blob/master/WORKING-GROUPS.md">工作组</a>。
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ keywords: [翻译，贡献]
|
|||
|telemetry|遥测|
|
||||
|tenancy|租户|
|
||||
|timeouts|超时|
|
||||
|tracing|跟踪|
|
||||
|tracing|追踪|
|
||||
|traffic-management|流量管理|
|
||||
|traffic-shifting|流量转移|
|
||||
|understanding What happened|理解原理|
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ icon: feature-status
|
|||
| [Zipkin/Jaeger 的分布式追踪](/zh/docs/tasks/telemetry/distributed-tracing/) | Alpha
|
||||
| [服务追踪](/zh/docs/tasks/telemetry/distributed-tracing/) | Alpha
|
||||
| [Fluentd 日志记录](/zh/docs/tasks/telemetry/fluentd/) | Alpha
|
||||
| [跟踪采样](/zh/docs/tasks/telemetry/distributed-tracing/overview/#trace-sampling) | Alpha
|
||||
| [追踪采样](/zh/docs/tasks/telemetry/distributed-tracing/overview/#trace-sampling) | Alpha
|
||||
|
||||
### 安全和策略实施
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ icon: notes
|
|||
|
||||
- **新协议**。Mesh 范围内对 WebSocket 连接的支持，MongoDB 代理和 Kubernetes [Headless 服务](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)。
|
||||
|
||||
- **其他改进**。Ingress 正确支持 gRPC 服务，更好地支持健康检查和 Jaeger 跟踪。
|
||||
- **其他改进**。Ingress 正确支持 gRPC 服务，更好地支持健康检查和 Jaeger 追踪。
|
||||
|
||||
## 遥测和增强策略
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ icon: notes
|
|||
|
||||
- **Mixer 适配器更新**。所有内置适配器都已重写，以适应新的适配器型号,已为此版本添加了 `stackdriver` 适配器,实验性 redis 配额适配器已在 0.2 版本中删除，但预计将在 0.3 版本中恢复生产质量。
|
||||
|
||||
- **Mixer 呼叫跟踪**。现在可以在 Zipkin 仪表板中跟踪和分析 Envoy 和 Mixer 之间的调用。
|
||||
- **Mixer 呼叫追踪**。现在可以在 Zipkin 仪表板中追踪和分析 Envoy 和 Mixer 之间的调用。
|
||||
|
||||
## 安全
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ icon: notes
|
|||
|
||||
- Pilot 的性能和伸缩性有了很大提升。现在每秒钟之内，Pilot 可以向 500 个 Sidecar 发送端点更新信息。
|
||||
|
||||
- 缺省的[跟踪采样]被设置为 `1%`。
|
||||
- 缺省的[追踪采样]被设置为 `1%`。
|
||||
|
||||
## 策略和遥测
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ WeaveWorks 的 [Weave Cloud](https://www.weave.works/blog/istio-weave-cloud/)
|
|||
|
||||
* [istio.io](/zh) 提供文档和示例。
|
||||
|
||||
* 用于供大家讨论的邮件列表 [`istio-users@googlegroups.com`](https://groups.google.com/forum/#!forum/istio-users)，或者用于公告项目相关信息的 [`istio-announce@googlegroups.com`](https://groups.google.com/forum/#!forum/istio-announce)。
|
||||
* [Istio discussion board](https://discuss.istio.io) 综合交流区。
|
||||
|
||||
* [Stack Overflow](https://stackoverflow.com/questions/tagged/istio) 用于问答
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Sidecar proxy 模式成就了很多奇迹。Sidecar 身处微服务的数据路
|
|||
|
||||
## AppSwitch
|
||||
|
||||
和容器运行时相比，AppSwitch 由客户端和一个守护进程组成，二者通过 HTTP 协议的 REST API 进行通信。客户端和守护进程构建为一个自包含的二进制文件 `ax`。客户端透明的注入s应用程序，并跟踪网络相关的系统调用，随后通知守护进程。例如一个应用进行了 `connect(2)` 系统调用，目标是一个 Kubernetes 服务的 IP。AppSwitch 客户端拦截这一调用并令其失效，然后把这一事件及其参数和上下文环境告知守护进程。守护进程会处理系统调用，例如代表应用程序直接连接到上游服务器的 Pod IP。
|
||||
和容器运行时相比，AppSwitch 由客户端和一个守护进程组成，二者通过 HTTP 协议的 REST API 进行通信。客户端和守护进程构建为一个自包含的二进制文件 `ax`。客户端透明的注入s应用程序，并追踪网络相关的系统调用，随后通知守护进程。例如一个应用进行了 `connect(2)` 系统调用，目标是一个 Kubernetes 服务的 IP。AppSwitch 客户端拦截这一调用并令其失效，然后把这一事件及其参数和上下文环境告知守护进程。守护进程会处理系统调用，例如代表应用程序直接连接到上游服务器的 Pod IP。
|
||||
|
||||
值得注意的一点是，AppSwitch 的客户端和服务器之间不做任何数据转发。它们中间会通过 Unix socket 交换文件描述符，从而避免数据拷贝。另外客户端也不是独立进程，而是运行在应用本身的上下文之中的，因此应用和 AppSwitch 之间也不存在数据拷贝的操作。
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ FitStation 建立在对用户生物识别数据的最终安全性和隐私承诺
|
|||
通过在基础架构级别管理这些方面，我们专注于解决业务问题，而不是花时间在安全服务通信的单独实现上。
|
||||
使用 Istio 可以大大降低维护大量库和服务的复杂性，从而提供安全的通信服务。
|
||||
|
||||
作为使用 Istio 1.0 的额外好处，我们获得了网络可见性，指标和开箱即用的跟踪。这极大地改善了我们开发和 DevOps 团队的的决策和响应质量
|
||||
作为使用 Istio 1.0 的额外好处，我们获得了网络可见性，指标和开箱即用的追踪。这极大地改善了我们开发和 DevOps 团队的的决策和响应质量
|
||||
。团队深入了解包括新应用程序和传统应用程序在内的整个平台的网络通信。 Cilium 与 Envoy 的整合，
|
||||
让 Istio 服务网格网络通信能力的性能取得了显著提升，同时还提供了内核驱动的细粒度 L7 网络安全层。这归功于 Cilium 为 Istio 提供的 BPF 功能。
|
||||
我们认为未来将推动 Linux 的内核安全。
|
||||
|
|
@ -29,4 +29,4 @@ FitStation 建立在对用户生物识别数据的最终安全性和隐私承诺
|
|||
跟随 Istio 的成长一直非常令人兴奋。我们已经能够看到不同开发版本的性能和稳定性的明显改进。
|
||||
版本 0.7 和 0.8 之间的改进使我们的团队对 1.0 版本感到满意，我们可以说 Istio 现在已经准备好用于实际生产。
|
||||
|
||||
我们期待着 Istio 、Envoy 、Cilium 和 CNCF 充满希望的路线图。
|
||||
我们期待着 Istio 、Envoy 、Cilium 和 CNCF 充满希望的路线图。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: 2019 年的博客文章
|
||||
description: 2019 年的博客文章。
|
||||
weight: 9
|
||||
icon: blog
|
||||
---
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: 宣布 discuss.istio.io
|
||||
subtitle: Istio 讨论板
|
||||
description: Istio 推出新的讨论板。
|
||||
publishdate: 2019-01-10
|
||||
attribution: The Istio Team
|
||||
weight: 100
|
||||
---
|
||||
|
||||
Istio 社区一直致力于为用户寻找与社区成员互动的最佳媒介——提出问题、互帮互助、与项目开发人员互动等。
|
||||
|
||||
我们尝试了几种方式，但每种方式都有些缺点。我们最近尝试的是 RocketChat，但它缺乏某些功能（例如分线程），这意味着它不适合针对单个问题做长时间的讨论。这还导致一些用户陷入两难境地——到底什么时候发邮件到 istio-users@googlegroups.com，什么时候使用 RocketChat？
|
||||
|
||||
我们高兴地宣布 [discuss.istio.io](https://discuss.istio.io)，我们认为在这个单一平台上找到了很好的功能平衡。这是一个功能齐全的论坛，我们将从这里开始讨论 Istio。它将允许您提出问题并获得分线程回复！更棒的是您可以使用 GitHub 身份登录。
|
||||
|
||||
如果您更喜欢电子邮件，则可以将其配置为像 Google group 一样发送电子邮件。
|
||||
|
||||
我们会将 Google group 标记为 “read only”，以便保留内容，但我们会要求您将更多问题发送至 [discuss.istio.io](https://discuss.istio.io)。如果您在小组中有任何未解决的问题或讨论，请转移到讨论板。
|
||||
|
||||
Happy meshing!
|
||||
|
|
@ -5,7 +5,7 @@ weight: 50
|
|||
keywords: [performance,scalability,scale,benchmarks]
|
||||
---
|
||||
|
||||
我们对 Istio 性能评估、跟踪和改进采用四管齐下的方法：
|
||||
我们对 Istio 性能评估、追踪和改进采用四管齐下的方法：
|
||||
|
||||
* 代码级微基准测试
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ keywords: [performance,scalability,scale,benchmarks]
|
|||
|
||||
查看 Mixer 的[示例微基准测试]({{< github_file >}}/mixer/test/perf/singlecheck_test.go)，以衡量属性处理代码的性能。
|
||||
|
||||
开发人员还可以利用黄金文件（golden-file）的方式来捕获源代码树中基准测试结果的状态，以达到保持跟踪和引用的目的。 GitHub 上有该[基线文件]({{< github_file >}}/mixer/test/perf/bench.baseline)。
|
||||
开发人员还可以利用黄金文件（golden-file）的方式来捕获源代码树中基准测试结果的状态，以达到保持追踪和引用的目的。 GitHub 上有该[基线文件]({{< github_file >}}/mixer/test/perf/bench.baseline)。
|
||||
|
||||
由于这种测试的性质，机器间的延迟数据可能存在很大差异。建议以这种方式捕获的微基准数据仅与同一台机器上先前运行的数据进行比较。
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ Fortio 也是 100％ 开源的，除了 go 和 gRPC 之外没有外部依赖，
|
|||
|
||||
<iframe src="https://fortio.istio.io/?xMin=2&xMax=110&xLog=true&sel=qps_400-s1_to_s2-0.7.1-2018-04-05-22-06&sel=qps_400-s1_to_s2-0.6.0-2018-04-05-22-33" width="100%" height="1024" scrolling="no" frameborder="0"></iframe>
|
||||
|
||||
跟踪该场景所有测试版本的进度：
|
||||
追踪该场景所有测试版本的进度：
|
||||
|
||||
<iframe src="https://fortio.istio.io/?s=qps_400-s1_to_s2" width="100%" height="1024" scrolling="no" frameborder="0"></iframe>
|
||||
|
||||
|
|
@ -100,7 +100,7 @@ Acmeair 基准测试应用程序可以在这里找到：[IBM's BluePerf](https:/
|
|||
* [https://fortio-daily.istio.io/](https://fortio-daily.istio.io/)
|
||||
* [https://ibmcloud-perf.istio.io/regpatrol/](https://ibmcloud-perf.istio.io/regpatrol/)
|
||||
|
||||
这使我们能够及早发现回归并跟踪一段时间内的改进。
|
||||
这使我们能够及早发现回归并追踪一段时间内的改进。
|
||||
|
||||
## 可伸缩性和规模调整指南
|
||||
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ Istio 假定进入和离开服务网络的所有流量都会通过 Envoy 代理
|
|||
|
||||
Istio 负载均衡服务网格中实例之间的通信。
|
||||
|
||||
Istio 假定存在服务注册表，以跟踪应用程序中服务的 pod/VM。它还假设服务的新实例自动注册到服务注册表，并且不健康的实例将被自动删除。诸如 Kubernetes、Mesos 等平台已经为基于容器的应用程序提供了这样的功能。为基于虚拟机的应用程序提供的解决方案就更多了。
|
||||
Istio 假定存在服务注册表，以追踪应用程序中服务的 pod/VM。它还假设服务的新实例自动注册到服务注册表，并且不健康的实例将被自动删除。诸如 Kubernetes、Mesos 等平台已经为基于容器的应用程序提供了这样的功能。为基于虚拟机的应用程序提供的解决方案就更多了。
|
||||
|
||||
Pilot 使用来自服务注册的信息，并提供与平台无关的服务发现接口。网格中的 Envoy 实例执行服务发现，并相应地动态更新其负载均衡池。
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Istio 提供一种简单的方式来为已部署的服务建立网络，该网
|
|||
|
||||
* 可插入的策略层和配置 API，支持访问控制、速率限制和配额。
|
||||
|
||||
* 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。
|
||||
* 对出入集群入口和出口中所有流量的自动度量指标、日志记录和追踪。
|
||||
|
||||
* 通过强大的基于身份的验证和授权，在集群中实现安全的服务间通信。
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ Istio 的安全功能使开发人员可以专注于应用程序级别的安全
|
|||
|
||||
### 可观察性
|
||||
|
||||
Istio 强大的跟踪、监控和日志记录可让您深入了解服务网格部署。通过 Istio 的监控功能，可以真正了解服务性能如何影响上游和下游的功能，而其自定义仪表板可以提供对所有服务性能的可视性，并让您了解该性能如何影响您的其他进程。
|
||||
Istio 强大的追踪、监控和日志记录可让您深入了解服务网格部署。通过 Istio 的监控功能，可以真正了解服务性能如何影响上游和下游的功能，而其自定义仪表板可以提供对所有服务性能的可视性，并让您了解该性能如何影响您的其他进程。
|
||||
|
||||
Istio 的 Mixer 组件负责策略控制和遥测收集。它提供后端抽象和中介，将 Istio 的其余部分与各个基础架构后端的实现细节隔离开来，并为运维提供对网格和基础架构后端之间所有交互的细粒度控制。
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ keywords: [traffic-management,routing]
|
|||
|
||||
## 概述
|
||||
|
||||
微服务应用部署到 Istio 服务网格中之后，就可以在外部对服务进行监控和跟踪、请求（版本）路由、弹性测试、安全控制以及策略实施等。这一系列功能都是使用一致的方式完成的，并且这些功能都是跨服务、将应用作为一个整体进行控制的。
|
||||
微服务应用部署到 Istio 服务网格中之后，就可以在外部对服务进行监控和追踪、请求（版本）路由、弹性测试、安全控制以及策略实施等。这一系列功能都是使用一致的方式完成的，并且这些功能都是跨服务、将应用作为一个整体进行控制的。
|
||||
|
||||
本文中，我们会使用 [Bookinfo 示例应用](/zh/docs/examples/bookinfo/)，演示运维人员对运行中的应用进行请求路由的动态配置以及故障注入的方法。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,17 +1,17 @@
|
|||
---
|
||||
title: 深入遥测
|
||||
description: 演示如何使用 Istio Mixer 和 Istio sidecar 获取指标和日志，并在不同的服务间进行跟踪。
|
||||
description: 演示如何使用 Istio Mixer 和 Istio sidecar 获取指标和日志，并在不同的服务间进行追踪。
|
||||
weight: 30
|
||||
keywords: [telemetry,metrics,logging,tracing]
|
||||
---
|
||||
|
||||
演示如何使用 Istio Mixer 和 Istio sidecar 获取指标和日志，并在不同的服务间进行跟踪。
|
||||
演示如何使用 Istio Mixer 和 Istio sidecar 获取指标和日志，并在不同的服务间进行追踪。
|
||||
|
||||
## 概述
|
||||
|
||||
微服务应用部署到 Istio 服务网格中之后，就可以在外部对服务进行监控和跟踪、请求（版本）路由、弹性测试、安全控制以及策略实施等。这一系列功能都是使用一致的方式完成的，并且这些功能都是跨服务、将应用作为一个整体进行控制的。
|
||||
微服务应用部署到 Istio 服务网格中之后，就可以在外部对服务进行监控和追踪、请求（版本）路由、弹性测试、安全控制以及策略实施等。这一系列功能都是使用一致的方式完成的，并且这些功能都是跨服务、将应用作为一个整体进行控制的。
|
||||
|
||||
本文中，我们会使用 [Bookinfo 示例应用](/zh/docs/examples/bookinfo/)来进行演示，无需开发人员对这一多语言应用进行任何修改，运维人员直接就可以从运行中的应用中获取指标和跟踪信息，
|
||||
本文中，我们会使用 [Bookinfo 示例应用](/zh/docs/examples/bookinfo/)来进行演示，无需开发人员对这一多语言应用进行任何修改，运维人员直接就可以从运行中的应用中获取指标和追踪信息，
|
||||
|
||||
## 开始之前
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ keywords: [telemetry,metrics,logging,tracing]
|
|||
|
||||
1. [查询指标](/zh/docs/tasks/telemetry/querying-metrics/)：安装 Prometheus 插件，用来收集指标，并在 Prometheus 服务中查询 Istio 指标。
|
||||
|
||||
1. [分布式跟踪](/zh/docs/tasks/telemetry/distributed-tracing/)：这个任务会使用 Istio 来对应用中请求的流动路径进行跟踪。最终用户所体验的总体延迟在服务之间是如何分布的？分布式跟踪能够解决这一疑问，从而帮助开发人员更快的解决问题，这也是对分布式应用进行分析和排错的有力工具。
|
||||
1. [分布式追踪](/zh/docs/tasks/telemetry/distributed-tracing/)：这个任务会使用 Istio 来对应用中请求的流动路径进行追踪。最终用户所体验的总体延迟在服务之间是如何分布的？分布式追踪能够解决这一疑问，从而帮助开发人员更快的解决问题，这也是对分布式应用进行分析和排错的有力工具。
|
||||
|
||||
1. [使用 Istio Dashboard](/zh/docs/tasks/telemetry/using-istio-dashboard/)：安装 Grafana 插件，这一插件中带有一个预配置 Dashboard，可以用来对服务网格中的流量进行监控。
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ $ istio_ca [flags]
|
|||
| `--log_rotate_max_age <int>` | 日志文件超过文件分割的最大寿命，将自动分割（以天为单位,0 表示无限制）（默认为 `30`） |
|
||||
| `--log_rotate_max_backups <int>` | 删除旧文件之前要保留的最大日志文件备份数（0表示无限制）（默认为 `1000`） |
|
||||
| `--log_rotate_max_size <int>` | 日志文件的最大大小（以兆为单位），超过该值日志文件将分割文件（默认为 `104857600`） |
|
||||
| `--log_stacktrace_level <string>` | 捕获堆栈跟踪的日志记录级别，逗号分隔的最小的每个范围，格式为 `<scope>` : `<level>` ，`<scope: level>`，...其中 scope 可以是\[default，model\]之一和 level 可以是\[debug，info，warn，error，none\]之一（ 默认 `default: none`） |
|
||||
| `--log_stacktrace_level <string>` | 捕获堆栈追踪的日志记录级别，逗号分隔的最小的每个范围，格式为 `<scope>` : `<level>` ，`<scope: level>`，...其中 scope 可以是\[default，model\]之一和 level 可以是\[debug，info，warn，error，none\]之一（ 默认 `default: none`） |
|
||||
| `--log_target <stringArray>` | 输出日志的路径集。这可以是任何路径以及特殊值 `stdout` 和 `stderr`（ 默认 `[stdout]`） |
|
||||
| `--max-workload-cert-ttl <duration>` | 已发布工作负载证书的最大 TTL（默认为 `2160h0m0s`） |
|
||||
| `--monitoring-port <int>` | 用于监控 Citadel 的端口号。如果未指定，Citadel 将禁用监控。（ 默认 `9093`） |
|
||||
|
|
@ -76,7 +76,7 @@ $ istio_ca probe [flags]
|
|||
| `--log_rotate_max_age <int>` | 日志文件超过文件分割的最大寿命（以天为单位，0表示无限制），将分割文件（默认为 `30`） |
|
||||
| `--log_rotate_max_backups <int>` | 删除旧文件之前要保留的最大日志文件备份数（0表示无限制）（默认为 `1000`） |
|
||||
| `--log_rotate_max_size <int>` | 日志文件的最大大小（以兆为单位），超过该值日志文件将分割文件（默认为 `104857600`） |
|
||||
| `--log_stacktrace_level <string>` | 捕获堆栈跟踪的日志记录级别，逗号分隔的最小的每个范围，格式为 `<scope>` : `<level>` ，`<scope: level>`，...其中 scope 可以是\[default，model\] 之一和 level 可以是\[debug，info，warn，error，none\]之一（ 默认 `default: none`） |
|
||||
| `--log_stacktrace_level <string>` | 捕获堆栈追踪的日志记录级别，逗号分隔的最小的每个范围，格式为 `<scope>` : `<level>` ，`<scope: level>`，...其中 scope 可以是\[default，model\] 之一和 level 可以是\[debug，info，warn，error，none\]之一（ 默认 `default: none`） |
|
||||
| `--log_target <stringArray>` | 输出日志的路径集。这可以是任何路径以及特殊值 `stdout` 和 `stderr`（ 默认 `[stdout]`） |
|
||||
| `--probe-path <string>` | 用于检查可用性的文件的路径。（ 默认 `''`） |
|
||||
|
||||
|
|
@ -100,6 +100,6 @@ $ istio_ca version [flags]
|
|||
| `--log_rotate_max_age <int>` | | 日志文件超过文件分割的最大寿命（以天为单位，0表示无限制），将分割日志文件（默认为 `30`） |
|
||||
| `--log_rotate_max_backups <int>` | | 删除旧文件之前要保留的最大日志文件备份数（0表示无限制）（默认为 `1000`） |
|
||||
| `--log_rotate_max_size <int>` | | 日志文件的最大大小（以兆为单位），超过该日志文件将分割文件（默认为 `104857600`） |
|
||||
| `--log_stacktrace_level <string>` | | 捕获堆栈跟踪的日志记录级别，逗号分隔的最小的每个范围，格式为 `<scope>` : `<level>` ，`<scope: level>`，...其中 scope 可以是\[default，model\] 之一和 level 可以是\[debug，info，warn，error，none\]之一（ 默认 `default: none`） |
|
||||
| `--log_stacktrace_level <string>` | | 捕获堆栈追踪的日志记录级别，逗号分隔的最小的每个范围，格式为 `<scope>` : `<level>` ，`<scope: level>`，...其中 scope 可以是\[default，model\] 之一和 level 可以是\[debug，info，warn，error，none\]之一（ 默认 `default: none`） |
|
||||
| `--log_target <stringArray>` | | 输出日志的路径集。这可以是任何路径以及特殊值 `stdout` 和 `stderr`（ 默认 `[stdout]`） |
|
||||
| `--short` | `-s` | 显示简短的版本信息 |
|
||||
| `--short` | `-s` | 显示简短的版本信息 |
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ $ mixc check [flags]
|
|||
| `--stringmap_attributes <string>` | | 名称/值字符串 map 属性的列表，指定为 `name1=k1:v1; k2:v2`，`name2=k3:v3` ...（默认为 `''`） |
|
||||
| `--timestamp_attributes <string>` | `-t` | 名称/值时间戳属性列表，指定为 `name1=value1`，`name2=value2`，...（默认为 `''`） |
|
||||
| `--trace_jaeger_url <string>` | | Jaeger HTTP 收集器的 URL（例如: `http://jaeger:14268/api/traces?format=jaeger.thrift` ）。（默认 `''`） |
|
||||
| `--trace_log_spans` | | 是否记录跟踪 span。|
|
||||
| `--trace_log_spans` | | 是否记录追踪 span。|
|
||||
| `--trace_zipkin_url <string>` | | Zipkin 收集器的 URL（例如: `http://zipkin:9411/api/v1/spans` ）。（默认 `''`） |
|
||||
|
||||
## `mixc` report
|
||||
|
|
@ -59,7 +59,7 @@ $ mixc report [flags]
|
|||
| `--stringmap_attributes <string>` | | 名称/值字符串 map 属性的列表，指定为 `name1=k1:v1`; `k2:v2`，`name2=k3:v3` ...（默认为 `''`） |
|
||||
| `--timestamp_attributes <string>` | `-t` | 名称/值时间戳属性列表，指定为 `name1=value1`，`name2=value2`，...（默认为 `''`） |
|
||||
| `--trace_jaeger_url <string>` | | Jaeger HTTP 收集器的 URL（例如: `http://jaeger:14268/api/traces?format=jaeger.thrift` ）。（默认 `''`） |
|
||||
| `--trace_log_spans` | | 是否记录跟踪 span。|
|
||||
| `--trace_log_spans` | | 是否记录追踪 span。|
|
||||
| `--trace_zipkin_url <string>` | | Zipkin 收集器的 URL（例如: `http://zipkin:9411/api/v1/spans` ）。（默认 `''`） |
|
||||
|
||||
## `mixc` version
|
||||
|
|
@ -74,4 +74,4 @@ $ mixc version [flags]
|
|||
|
||||
| 参数 | 缩写 | 描述 |
|
||||
| --- | --- | --- |
|
||||
| `--short` | `-s` | 显示简短形式的版本信息 |
|
||||
| `--short` | `-s` | 显示简短形式的版本信息 |
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ $ mixs probe [flags]
|
|||
| `--log_rotate_max_age <int>` | 日志文件超过文件分割的最大寿命（以天为单位）（0表示无限制），将分割日志（默认为 `30`） |
|
||||
| `--log_rotate_max_backups <int>` | 删除旧文件之前要保留的最大日志文件备份数（0表示无限制）（默认为 `1000`） |
|
||||
| `--log_rotate_max_size <int>` | 日志文件的最大大小（以兆字节为单位），超过该值将分割文件（默认为 `104857600`） |
|
||||
| `--log_stacktrace_level <string>` | 捕获堆栈跟踪的逗号分隔的最小每范围日志记录级别，格式为`<scope>:<level>`，`<scope:level>`，...其中 scope 可以是\[`adapters，api，attributes，default，grpcAdapter，mcp，mcp-creds`\]之一和 level 可以是\[debug，info，warn，error，none\]之一（默认为`default:none`） |
|
||||
| `--log_stacktrace_level <string>` | 捕获堆栈追踪的逗号分隔的最小每范围日志记录级别，格式为`<scope>:<level>`，`<scope:level>`，...其中 scope 可以是\[`adapters，api，attributes，default，grpcAdapter，mcp，mcp-creds`\]之一和 level 可以是\[debug，info，warn，error，none\]之一（默认为`default:none`） |
|
||||
| `--log_target <stringArray>` | 输出日志的路径集。这可以是任何路径以及特殊值 `stdout` 和 `stderr`（默认`\[stdout\]`） |
|
||||
| `--probe-path <string>` | 用于检查可用性的文件的路径。（默认 `''`） |
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ $ mixs server [flags]
|
|||
| `--log_rotate_max_age <int>` | | 日志文件超过文件分割的最大寿命（以天为单位）（0表示无限制）（默认为 `30`） |
|
||||
| `--log_rotate_max_backups <int>` | | 删除旧文件之前要保留的最大日志文件备份数（0表示无限制）（默认为 `1000`） |
|
||||
| `--log_rotate_max_size <int>` | | 日志文件的最大大小（以兆字节为单位），超过该日志文件将分割文件（默认为 `104857600`） |
|
||||
| `--log_stacktrace_level <string>` | | 捕获堆栈跟踪的逗号分隔的最小每范围日志记录级别，格式为`<scope>`:`<level>`，`<scope:level>`，...其中 scope 可以是\[`adapters`，`api`，`attributes`，`default`，`grpcAdapter`，`mcp`，`mcp-creds`\]之一和 level 可以是\[debug，info，warn，error，none\]之一（默认为`default:none`） |
|
||||
| `--log_stacktrace_level <string>` | | 捕获堆栈追踪的逗号分隔的最小每范围日志记录级别，格式为`<scope>`:`<level>`，`<scope:level>`，...其中 scope 可以是\[`adapters`，`api`，`attributes`，`default`，`grpcAdapter`，`mcp`，`mcp-creds`\]之一和 level 可以是\[debug，info，warn，error，none\]之一（默认为`default:none`） |
|
||||
| `--log_target <stringArray>` | | 输出日志的路径集。这可以是任何路径以及特殊值 `stdout` 和 `stderr`（默认`[stdout]`） |
|
||||
| `--maxConcurrentStreams <uint>` | | 每个连接的最大未完成 RPC 数（默认为 `1024`） |
|
||||
| `--maxMessageSize <uint>` | | 单个 gRPC 消息的最大大小（默认为 `1048576`） |
|
||||
|
|
@ -103,7 +103,7 @@ $ mixs server [flags]
|
|||
| `--readinessProbePath <string>` | | 准备探针的文件路径。（默认 `''`） |
|
||||
| `--singleThreaded` | | 如果为 true，则每个对 `Mixer` 的请求将在单个 go 例程中执行（对于调试很有用） |
|
||||
| `--trace_jaeger_url <string>` | | Jaeger HTTP 收集器的 URL（例如:`http://jaeger:14268/api/traces?format=jaeger.thrift`）。（默认 `''`） |
|
||||
| `--trace_log_spans` | | 是否记录跟踪 span。|
|
||||
| `--trace_log_spans` | | 是否记录追踪 span。|
|
||||
| `--trace_zipkin_url <string>` | | Zipkin 收集器的 URL（例如:`http://zipkin:9411/api/v1/spans`）。（默认 `''`） |
|
||||
|
||||
## `mixs version`
|
||||
|
|
@ -117,4 +117,4 @@ $ mixs version [flags]
|
|||
|
||||
| 参数 | 缩写 | 描述 |
|
||||
| --- | --- | --- |
|
||||
| `--short` | `-s` | 显示简短形式的版本信息 |
|
||||
| `--short` | `-s` | 显示简短形式的版本信息 |
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ $ node_agent [flags]
|
|||
| `--log_rotate_max_age <int>` | 日志文件超过文件分割的最大寿命(以天为单位，0表示无限制），将分割日志文件(默认为 `30`） |
|
||||
| `--log_rotate_max_backups <int>` | 删除旧文件之前要保留的最大日志文件备份数(0表示无限制）(默认为 `1000`） |
|
||||
| `--log_rotate_max_size <int>` | 日志文件的最大大小(以兆字节为单位），超过该值将分割文件(默认为 `104857600`） |
|
||||
| `--log_stacktrace_level <string>` | 捕获堆栈跟踪的最小日志记录级别可以是\[debug、info、warn、error、none\]之一(默认为“default:none”） |
|
||||
| `--log_stacktrace_level <string>` | 捕获堆栈追踪的最小日志记录级别可以是\[debug、info、warn、error、none\]之一(默认为“default:none”） |
|
||||
| `--log_target <stringArray>` | 输出日志的路径集。 这可以是任何路径以及特殊值 `stdout` 和 `stderr`( 默认 `[stdout]`） |
|
||||
| `--org <string>` | 证书组织(默认 `''`） |
|
||||
| `--platform <string>` | 平台 `istio` 运行于：`vm` | `k8s`( 默认 `vm`） |
|
||||
|
|
@ -52,6 +52,6 @@ $ node_agent version [flags]
|
|||
| `--log_rotate_max_age <int>` | | 日志文件超过文件分割的最大寿命(以天为单位，0表示无限制），将分割日志(默认为 `30`） |
|
||||
| `--log_rotate_max_backups <int>` | | 删除旧文件之前要保留的最大日志文件备份数(0表示无限制）(默认为 `1000`） |
|
||||
| `--log_rotate_max_size <int>` | | 日志文件的最大大小(以兆字节为单位），超过该日志文件将分割文件(默认为 `104857600`） |
|
||||
| `--log_stacktrace_level <string>` | | 捕获堆栈跟踪的最小日志记录级别可以是\[debug、info、warn、error、none\]之一(默认为 `default:none`） |
|
||||
| `--log_stacktrace_level <string>` | | 捕获堆栈追踪的最小日志记录级别可以是\[debug、info、warn、error、none\]之一(默认为 `default:none`） |
|
||||
| `--log_target <stringArray>` | | 输出日志的路径集。 这可以是任何路径以及特殊值 `stdout` 和 `stderr`( 默认 `[stdout]`） |
|
||||
| `--short` | `-s` | 显示简短形式的版本信息 |
|
||||
| `--short` | `-s` | 显示简短形式的版本信息 |
|
||||
|
|
|
|||
|
|
@ -858,7 +858,7 @@ spec:
|
|||
|
||||
## `OutlierDetection`
|
||||
|
||||
熔断器的实现需要对每个上游服务主机进行跟踪。对 HTTP 和 TCP 服务都可以生效。对 HTTP 服务来说，如果有主机持续返回 `5xx` 给 API 调用，会被踢出服务池，并持续一个预定义的时间长度；而对于 TCP 服务，到指定主机的连接超时和连接失败都会被记为错误次数，作为持续失败的指标进行统计。参考 Envoy 的 [outlier detection](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/outlier) 可以获取更多信息。
|
||||
熔断器的实现需要对每个上游服务主机进行追踪。对 HTTP 和 TCP 服务都可以生效。对 HTTP 服务来说，如果有主机持续返回 `5xx` 给 API 调用，会被踢出服务池，并持续一个预定义的时间长度；而对于 TCP 服务，到指定主机的连接超时和连接失败都会被记为错误次数，作为持续失败的指标进行统计。参考 Envoy 的 [outlier detection](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/outlier) 可以获取更多信息。
|
||||
|
||||
下面的规则为 `reviews` 服务设置了一个 100 个 TCP 连接，以及 1000 个 HTTP2 并发请求同时每个连接不能超过 10 请求的连接池。另外其中还配置了每五分钟扫描一次上游服务主机，连续失败 7 次返回 `5xx` 错误码的主机会被移出连接池 15 分钟。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: Trace Span
|
||||
description: 该模板用于表达分布式跟踪数据中的一个 Span。
|
||||
description: 该模板用于表达分布式追踪数据中的一个 Span。
|
||||
weight: 120
|
||||
---
|
||||
`tracespan` 模板用在分布式跟踪中，用于表达一个单独的 Span。
|
||||
`tracespan` 模板用在分布式追踪中，用于表达一个单独的 Span。
|
||||
|
||||
配置样例：
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ spec:
|
|||
source.version: source.labels["version"] | ""
|
||||
{{< /text >}}
|
||||
|
||||
请参照[分布式跟踪](/zh/docs/tasks/telemetry/distributed-tracing/)任务来了解更多相关信息。
|
||||
请参照[分布式追踪](/zh/docs/tasks/telemetry/distributed-tracing/)任务来了解更多相关信息。
|
||||
|
||||
## 模板
|
||||
|
||||
|
|
@ -42,13 +42,13 @@ spec:
|
|||
|
||||
|字段|类型|说明|
|
||||
|---|---|---|
|
||||
|`traceId`|`string`|必要字段。Trace ID 是一次跟踪的唯一标识符。一次跟踪中的所有 Span 都会使用同一个 Trace ID|
|
||||
|`spanId`|`string`|可选字段。Span ID 是跟踪中一个 Span 的唯一标识符，在创建 Span 时生成|
|
||||
|`traceId`|`string`|必要字段。Trace ID 是一次追踪的唯一标识符。一次追踪中的所有 Span 都会使用同一个 Trace ID|
|
||||
|`spanId`|`string`|可选字段。Span ID 是追踪中一个 Span 的唯一标识符，在创建 Span 时生成|
|
||||
|`parentSpanId`|`string`|可选字段。该 Span 的上级 Span ID。如果这是一个根级 Span，那么这个字段必须为空|
|
||||
|`spanName`|`string`|必要字段。对于该 Span 的操作内容的描述。例如可以是一个方法的完全限定名，或者是方法所在的文件名和行号。建议的最佳实践是，一个应用中，在同一个调用点使用同样的名称，以便于在不同跟踪中识别出正确的 Span|
|
||||
|`spanName`|`string`|必要字段。对于该 Span 的操作内容的描述。例如可以是一个方法的完全限定名，或者是方法所在的文件名和行号。建议的最佳实践是，一个应用中，在同一个调用点使用同样的名称，以便于在不同追踪中识别出正确的 Span|
|
||||
|`startTime`|[`istio.policy.v1beta1.TimeStamp`](/docs/reference/config/policy-and-telemetry/istio.policy.v1beta1/#TimeStamp)|必要字段：Span 的开始时间|
|
||||
|`endTime`|[`istio.policy.v1beta1.TimeStamp`](/docs/reference/config/policy-and-telemetry/istio.policy.v1beta1/#TimeStamp)|必要字段：Span 的结束时间|
|
||||
|`spanTags`|`map<string,` [`istio.policy.v1beta1.Value`](/docs/reference/config/policy-and-telemetry/istio.policy.v1beta1/#Value)`>`|可选字段。Span 标签是一组键值对，用于表达 Span 的元数据。其中的值部分可以使用表达式动态生成|
|
||||
|`httpStatusCode`|`int64`|可选字段。HTTP 状态码，代表 Span 的状态。如果没有值或者值为 0，可以假设该 Span 成功完成|
|
||||
|`clientSpan`|`bool`|可选字段。表示 Span 的类型。如果值为 `True`，则代表是一个客户端 Span。因为 Mixer 不支持枚举值，因此该字段目前临时使用布尔型|
|
||||
|`rewriteClientSpanId`|`bool`|可选字段。用于确定是否为 Zipkin 的共享 Span 模型创建一个新的客户端 Span。有的跟踪系统，例如 Stackdriver 会把一个 RPC Span 分为客户端和服务器端。为了解决这个不兼容问题，可以把客户端 Span 和服务端 Span 的上级 Span 的 ID 重写为新生成的 ID|
|
||||
|`rewriteClientSpanId`|`bool`|可选字段。用于确定是否为 Zipkin 的共享 Span 模型创建一个新的客户端 Span。有的追踪系统，例如 Stackdriver 会把一个 RPC Span 分为客户端和服务器端。为了解决这个不兼容问题，可以把客户端 Span 和服务端 Span 的上级 Span 的 ID 重写为新生成的 ID|
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ draft: true
|
|||
|
||||
## 仅安装 Ingress 控制器
|
||||
|
||||
将 Istio 用作 Ingress 控制器是可行的，可以用于在七层提供路由方面的支撑，例如基于版本的路由、基于 Header 的路由、gRPC/HTTP2 代理、跟踪等。仅部署 Istio Pilot，并禁用其他组件。不要部署 Istio 的 `initializer`。
|
||||
将 Istio 用作 Ingress 控制器是可行的，可以用于在七层提供路由方面的支撑，例如基于版本的路由、基于 Header 的路由、gRPC/HTTP2 代理、追踪等。仅部署 Istio Pilot，并禁用其他组件。不要部署 Istio 的 `initializer`。
|
||||
|
||||
## Ingress 控制器，并提供遥测和策略支持
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ draft: true
|
|||
|
||||
## 智能路由和遥测
|
||||
|
||||
如果要在深度遥测和分布式请求跟踪之外，还希望享受 Istio 的七层流量管理能力，就需要部署 Istio Pilot 和 Mixer；另外还可以在 Mixer 上禁用策略支持。
|
||||
如果要在深度遥测和分布式请求追踪之外，还希望享受 Istio 的七层流量管理能力，就需要部署 Istio Pilot 和 Mixer；另外还可以在 Mixer 上禁用策略支持。
|
||||
|
||||
## 定制示例：支持安全和流量管理的最小集合
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ keywords: [kubernetes,gke,google]
|
|||
[Bookinfo](/zh/docs/examples/bookinfo/) 样例应用、
|
||||
[Grafana](/zh/docs/tasks/telemetry/using-istio-dashboard/) 、
|
||||
[Prometheus](/zh/docs/tasks/telemetry/querying-metrics/) 和
|
||||
[跟踪](/zh/docs/tasks/telemetry/distributed-tracing/) 。
|
||||
[追踪](/zh/docs/tasks/telemetry/distributed-tracing/) 。
|
||||
接下来你可以了解一下怎样访问所有这些功能。脚本只在 `default` 的命名空间中启用 Istio 自动注入。
|
||||
|
||||
1. 点击 **Deploy**:
|
||||
|
|
|
|||
|
|
@ -9,5 +9,5 @@ keywords: [kubernetes,sidecar,sidecar-injection]
|
|||
|
||||
1. **需要给端口正确命名**：服务端口必须进行命名。端口名称只允许是`<协议>[-<后缀>-]`模式，其中`<协议>`部分可选择范围包括 `grpc`、`http`、`http2`、`https`、`mongo`、`redis`、`tcp`、`tls` 以及 `udp`，Istio 可以通过对这些协议的支持来提供路由能力。例如 `name: http2-foo` 和 `name: http` 都是有效的端口名，但 `name: http2foo` 就是无效的。如果没有给端口进行命名，或者命名没有使用指定前缀，那么这一端口的流量就会被视为普通 TCP 流量（除非[显式](https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service)的用 `Protocol: UDP` 声明该端口是 UDP 端口）。
|
||||
1. **关联服务**：Pod 必须关联到 [Kubernetes 服务](https://kubernetes.io/docs/concepts/services-networking/service/)，如果一个 Pod 属于多个服务，这些服务不能再同一端口上使用不同协议，例如 HTTP 和 TCP。
|
||||
1. **Deployment 应带有 `app` 以及 `version` 标签**：在使用 Kubernetes `Deployment` 进行 Pod 部署的时候，建议显式的为 `Deployment` 加上 `app` 以及 `version` 标签。每个 Deployment 都应该有一个有意义的 `app` 标签和一个用于标识 `Deployment` 版本的 `version` 标签。`app` 标签在分布式跟踪的过程中会被用来加入上下文信息。Istio 还会用 `app` 和 `version` 标签来给遥测指标数据加入上下文信息。
|
||||
1. _**Application UID**_：**不要**使用 ID（UID）值为 **1337** 的用户来运行应用。
|
||||
1. **Deployment 应带有 `app` 以及 `version` 标签**：在使用 Kubernetes `Deployment` 进行 Pod 部署的时候，建议显式的为 `Deployment` 加上 `app` 以及 `version` 标签。每个 Deployment 都应该有一个有意义的 `app` 标签和一个用于标识 `Deployment` 版本的 `version` 标签。`app` 标签在分布式追踪的过程中会被用来加入上下文信息。Istio 还会用 `app` 和 `version` 标签来给遥测指标数据加入上下文信息。
|
||||
1. _**Application UID**_：**不要**使用 ID（UID）值为 **1337** 的用户来运行应用。
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: 分布式跟踪
|
||||
description: 该任务展示了如何为启用了 Istio 支持的应用进行跟踪。
|
||||
title: 分布式追踪
|
||||
description: 该任务展示了如何为启用了 Istio 支持的应用进行追踪。
|
||||
weight: 10
|
||||
keywords: [telemetry,tracing]
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ keywords: [telemetry,tracing,lightstep]
|
|||
---
|
||||
|
||||
此任务说明如何配置 Istio 以收集追踪 span 并将其发送到 LightStep [𝑥]PM。
|
||||
[𝑥]PM 让您可以从大规模生产软件中分析 100％ 未抽样的事务数据，从而产生有意义的分布式跟踪信息和 metrics，用于帮助解释性能行为并加快根本原因分析。
|
||||
[𝑥]PM 让您可以从大规模生产软件中分析 100％ 未抽样的事务数据，从而产生有意义的分布式追踪信息和 metrics，用于帮助解释性能行为并加快根本原因分析。
|
||||
更多信息请访问 [LightStep 网站](https://lightstep.com)。
|
||||
在此任务的最后，Istio 将从代理发送 span 到一个 LightStep [𝑥]PM Satellite pool，使得它们在 web 界面上可用。
|
||||
|
||||
|
|
@ -91,11 +91,11 @@ keywords: [telemetry,tracing,lightstep]
|
|||
|
||||
{{< image link="/docs/tasks/telemetry/distributed-tracing/lightstep/istio-tracing-list-lightstep.png" caption="Explorer" >}}
|
||||
|
||||
1. 单击延迟直方图下方的示例跟踪表中的第一行，以查看与刷新 `/productpage` 时相对应的详细信息。页面看起来像这样：
|
||||
1. 单击延迟直方图下方的示例追踪表中的第一行，以查看与刷新 `/productpage` 时相对应的详细信息。页面看起来像这样：
|
||||
|
||||
{{< image link="/docs/tasks/telemetry/distributed-tracing/lightstep/istio-tracing-details-lightstep.png" caption="Detailed Trace View" >}}
|
||||
|
||||
屏幕截图显示跟踪由一组 span 组成。 每个 span 对应于执行 `/productpage` 时调用的 Bookinfo 服务。
|
||||
屏幕截图显示追踪由一组 span 组成。 每个 span 对应于执行 `/productpage` 时调用的 Bookinfo 服务。
|
||||
|
||||
追踪中的两个 span 代表了每个 RPC。例如，从 `productpage` 到 `reviews` 的请求带有的 span 使用 `reviews.default.svc.cluster.local:9080/*` operation 和 `productpage.default: proxy client` 进行标记。这个
|
||||
service 代表了客户端请求的 span。屏幕截图显示请求耗时 15.30 毫秒。第二个 span 使用 `reviews.default.svc.cluster.local:9080/*` operation 和 `reviews.default: proxy server` service 进行标记。第二个 span 是第一个的子级，代表了服务端请求的 span。屏幕截图显示请求耗时 14.60 毫秒。
|
||||
|
|
|
|||
|
|
@ -9,6 +9,6 @@ Istio 是一个开放的、与平台无关的服务网格，它提供了流量
|
|||
|
||||
*平台无关*: Istio 不针对任何特定的部署环境。在开发的初始阶段，Istio 将支持基于 Kubernetes 的部署。但是，Istio 正在被构建为能快速便捷适配其他环境。
|
||||
|
||||
*服务网格*: Istio 旨在管理微服务和应用程序之间的通信。无需更改底层服务，Istio 为所有服务到服务通信提供自动基线流量弹性、服务指标收集、分布式跟踪、流量加密、协议升级和高级路由功能。
|
||||
*服务网格*: Istio 旨在管理微服务和应用程序之间的通信。无需更改底层服务，Istio 为所有服务到服务通信提供自动基线流量弹性、服务指标收集、分布式追踪、流量加密、协议升级和高级路由功能。
|
||||
|
||||
更多详细信息，请参阅 [Istio 是什么?](/zh/docs/concepts/what-is-istio/)
|
||||
|
|
|
|||
|
|
@ -23,4 +23,4 @@ $ kubectl -n istio-system logs -lapp=policy -c mixer
|
|||
$ kubectl -n istio-system logs -lapp=telemetry -c mixer
|
||||
{{< /text >}}
|
||||
|
||||
Mixer 跟踪功能由以下命令行参数控制：`trace_zipkin_url`、`trace_jaeger_url` 和 `trace_log_spans`。如果设置了以上参数中的任何一个，则跟踪数据将上报至配置的相关服务地址。如果未提供跟踪相关设置参数，则 Mixer 将不会产生应用程序级别的跟踪信息。
|
||||
Mixer 追踪功能由以下命令行参数控制：`trace_zipkin_url`、`trace_jaeger_url` 和 `trace_log_spans`。如果设置了以上参数中的任何一个，则追踪数据将上报至配置的相关服务地址。如果未提供追踪相关设置参数，则 Mixer 将不会产生应用程序级别的追踪信息。
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: 如何禁用 Istio 发送追踪 span 至 Zipkin？
|
|||
weight: 100
|
||||
---
|
||||
|
||||
如果已启用跟踪，则可以按如下方式禁用：
|
||||
如果已启用追踪，则可以按如下方式禁用：
|
||||
|
||||
{{< text plain >}}
|
||||
# 使用 Istio 所在命名空间名称来替换 <istio namespace>，例如：istio-system。
|
||||
|
|
@ -17,4 +17,4 @@ $ kubectl -n istio-system edit deployment istio-telemetry
|
|||
|
||||
然后按照[分布式追踪任务的清理部分](/zh/docs/tasks/telemetry/distributed-tracing/zipkin/#清理)的步骤进行操作。
|
||||
|
||||
如果完全不想使用追踪功能，可在 `istio-demo.yaml` 或 `istio-demo-auth.yaml` 中[禁用追踪功能](/zh/docs/tasks/telemetry/distributed-tracing/zipkin/#开始之前)，或者在安装 Istio 时不启用它。
|
||||
如果完全不想使用追踪功能，可在 `istio-demo.yaml` 或 `istio-demo-auth.yaml` 中[禁用追踪功能](/zh/docs/tasks/telemetry/distributed-tracing/zipkin/#开始之前)，或者在安装 Istio 时不启用它。
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: 如何获知 Istio 中一个请求的生命周期？
|
|||
weight: 80
|
||||
---
|
||||
|
||||
用户可以通过打开[跟踪](/zh/docs/tasks/telemetry/distributed-tracing/)功能来获知 Istio 中一个请求的流程。
|
||||
用户可以通过打开[追踪](/zh/docs/tasks/telemetry/distributed-tracing/)功能来获知 Istio 中一个请求的流程。
|
||||
|
||||
另外，用户可以使用如下的一些指令来获取网格状态的更多信息：
|
||||
|
||||
|
|
|
|||
|
|
@ -53,4 +53,4 @@ Istio 组件可以自动管理日志轮换，这使得将大型日志分解为
|
|||
|
||||
## 组件调试
|
||||
|
||||
使用 `--log_caller` 和 `--log_stacktrace_level` 选项可以控制日志信息是否包含程序级别的信息。这在尝试跟踪组件中的错误时很有用，但通常不会在日常操作中使用。
|
||||
使用 `--log_caller` 和 `--log_stacktrace_level` 选项可以控制日志信息是否包含程序级别的信息。这在尝试追踪组件中的错误时很有用，但通常不会在日常操作中使用。
|
||||
|
|
|
|||
|
|
@ -5,10 +5,10 @@ weight: 5
|
|||
keywords: [debug,security,authorization,RBAC]
|
||||
---
|
||||
|
||||
这篇文章展示了如何调试 Istio 的授权。如果在本文的指导下你还是没有找到解决方案。
|
||||
这篇文章展示了如何调试 Istio 的授权。
|
||||
|
||||
> {{< idea_icon >}}
|
||||
按照[报告错误](/about/bugs)的说明，在您的电子邮件中包含群集状态存档会非常有用。
|
||||
按照[报告错误](/zh/about/bugs)的说明，在您的电子邮件中包含集群状态存档会非常有用。
|
||||
|
||||
## 确保授权正常启用
|
||||
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ istio-egressgateway.istio-system.svc.cluster.local
|
|||
...
|
||||
{{< /text >}}
|
||||
|
||||
要对 Envoy 进行除错，首先要了解一下 Envoy 的集群、监听器、路由、端点的概念，以及这些对象之间的交互过程。我们会使用 `proxy-config` 命令的 `-o json` 参数，并对结果进行过滤，来跟踪 Envoy 对请求（从 `productpage` Pod 发向 `reviews` Pod 上的 `reviews:9080`）的决策过程：
|
||||
要对 Envoy 进行除错，首先要了解一下 Envoy 的集群、监听器、路由、端点的概念，以及这些对象之间的交互过程。我们会使用 `proxy-config` 命令的 `-o json` 参数，并对结果进行过滤，来追踪 Envoy 对请求（从 `productpage` Pod 发向 `reviews` Pod 上的 `reviews:9080`）的决策过程：
|
||||
|
||||
1. 如果查询一个 Pod 的监听器概要信息，会看到 Istio 生成了如下的监听器：
|
||||
|
||||
|
|
@ -284,4 +284,4 @@ $ istioctl proxy-config bootstrap -n istio-system istio-ingressgateway-7d6874b48
|
|||
"buildVersion": "0/1.8.0-dev//RELEASE"
|
||||
},
|
||||
...
|
||||
{{< /text >}}
|
||||
{{< /text >}}
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ istio-egressgateway.istio-system.svc.cluster.local
|
|||
...
|
||||
{{< /text >}}
|
||||
|
||||
为了调试 Envoy，您需要了解 Envoy 集群/监听器/路由/端点以及它们之间如何进行交互。我们将使用带有 `-o json` 和过滤标志的 `proxy-config` 命令来跟踪 Envoy 以确定将请求从 `productpage` pod 发送到了 `reviews:9080` 的 reviews pod 上。
|
||||
为了调试 Envoy，您需要了解 Envoy 集群/监听器/路由/端点以及它们之间如何进行交互。我们将使用带有 `-o json` 和过滤标志的 `proxy-config` 命令来追踪 Envoy 以确定将请求从 `productpage` pod 发送到了 `reviews:9080` 的 reviews pod 上。
|
||||
|
||||
1. 如果您在 pod 上查询监听器摘要，您会注意到 Istio 会生成以下监听器：
|
||||
* `0.0.0.0:15001` 上的监听器接收进出 pod 的所有流量，然后将请求移交给虚拟监听器。
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[discuss_istio_io_desc]
|
||||
other = "Join the Istio discussion board to participate in discussions and get help troubleshooting problems"
|
||||
other = "加入 Istio discussion board 参与讨论获取帮助"
|
||||
|
||||
[twitter_desc]
|
||||
other = "关注我们的 Twitter 来获取最新信息"
|
||||
|
|
|
|||
Loading…
Reference in New Issue