13、全面解析Grafana监控与Istio日志追踪技术

最新推荐文章于 2025-11-12 17:09:04 发布

fire9

最新推荐文章于 2025-11-12 17:09:04 发布

阅读量40

点赞数

CC 4.0 BY-SA版权

分类专栏： Istio服务网格实战指南文章标签： Grafana Istio 分布式追踪

本文链接：https://blog.youkuaiyun.com/fire9/article/details/152531130

Istio服务网格实战指南专栏收录该内容

15 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

全面解析Grafana监控与Istio日志追踪技术

1. Grafana Dashboard

Grafana 提供了一组预配置的仪表板，可直接开箱即用。我们可以直接访问 Istio 预配置的仪表板来查看 Istio 网格的性能。此 Grafana 配置已预先设置为从预配置的 Prometheus 数据源读取指标，同时也可以在 Grafana 中添加其他数据源以创建新的仪表板。

下面我们创建一个新的仪表板来监控最近配置的 RequestDouble 指标，具体操作步骤如下：
1. 创建一个可视化图表，展示对 webapp-deployment-8 的请求速率。
2. 保存该仪表板后，即可查看特定目标的请求速率视图。

2. Grafana Alert

假设当对 webapp-deployment-v8 的请求速率超过 2.5 时，该服务可能会受到影响。为了提前做好准备，我们可以在 Grafana 中设置警报。具体操作如下：
1. 设置警报通知渠道 ：Grafana 支持多种通知渠道，如下所示：
- HipChat
- OpsGenie
- Sensu
- Threema Gateway
- Prometheus Alertmanager
- Discord, Email
- VictorOps
- Google Hangouts Chat
- Kafka REST Proxy
- LINE
- Pushover
- Webhook
- DingDing
- PagerDuty
- Slack
- Microsoft Teams
- Telegram

以设置 Webhook 为例，我们将警报推送到以下链接：

https://jsonblob.com/api/jsonBlob/0d0ef717-d0a0-11e9-8538-43dbd386b327

设置 Webhook 的流程如下：

graph LR
    A[登录Grafana] --> B[进入设置页面]
    B --> C[选择通知渠道]
    C --> D[添加Webhook]
    D --> E[输入Webhook链接]
    E --> F[保存设置]

设置警报规则 ：
- 编辑之前创建的面板。
- 访问 “Alert” 选项卡，设置当请求阈值超过 2.5 时触发警报。
触发警报测试 ：使用 siege 工具向前端服务发送多个请求：

siege -c40 -r10 "http://192.168.99.160:31380"

几秒钟后，Grafana 将开始显示警报。Webhook 接收到的详细数据如下：

{
    "evalMatches": [{
        "value": 107.19741952834556,
        "metric": "{destination=\"webapp-deployment-8\", instance=\"172.17.0.6:42422\", job=\"istio-mesh\", source=\"frontend-deployment\"}",
        "tags": {
            "destination": "webapp-deployment-8",
            "instance": "172.17.0.6:42422",
            "job": "istio-mesh",
            "source": "frontend-deployment"
        }
    }],
    "message": "Requests threshold of web-deployment-8 reaching threshold, action required",
    "ruleId": 1,
    "ruleName": "RequestDouble Rate alert",
    "ruleUrl": "http://localhost:3000/d/hpc70ncWk/requestdouble-dashboard?fullscreen\u0026edit\u0026tab=alert\u0026panelId=2\u0026orgId=1",
    "state": "alerting",
    "title": "[Alerting] RequestDouble Rate alert"
}

3. 分布式追踪（Distributed Tracing）

在微服务应用中，一个请求通常由集群中部署的多个应用共同处理。分布式追踪是指跟踪请求在不同应用之间的流动过程，它可以通过显示请求、响应和延迟等信息来描述应用的行为。运维团队可以利用追踪信息来确定哪些服务导致了应用的性能问题。

常见的分布式追踪解决方案有 Zipkin、Jagger、Skywalking 等，Istio 服务网格可以与这些解决方案集成。追踪信息通常由 Envoy 代理生成，并发送到追踪后端。

分布式追踪依赖于一组额外的 HTTP 头，即 b3 请求头。这些头信息构建了请求上下文，用于识别父请求并在不同系统之间传播。具体需要传播的头信息如下：
- x-request-id
- x-b3-traceid
- x-b3-spanid
- x-b3-parentspanid
- x-b3-sampled
- x-b3-flags

为了实现分布式追踪，我们需要在 Kubernetes 集群中部署一个追踪应用。这里我们选择 Jagger，它是 Uber 开发的开源分布式追踪应用。部署 Jagger 的步骤如下：
1. 安装 Jagger 操作符 ：

git clone https://github.com/jaegertracing/jaeger-operator.git
kubectl create namespace observability
kubectl create -f jaeger-operator/deploy/crds/jaegertracing_v1_jaeger_crd.yaml
kubectl create -f jaeger-operator/deploy/service_account.yaml
kubectl create -f jaeger-operator/deploy/role.yaml
kubectl create -f jaeger-operator/deploy/role_binding.yaml
kubectl create -f jaeger-operator/deploy/operator.yaml

验证操作符 ：

kubectl get all -n observability

部署 Jagger 实例 ：使用以下配置部署最简单的 AllInOne Jagger 包，采用内存存储：

---
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simplest

应用该配置：

kubectl apply -f jagger.yaml

检查 Jagger 安装情况 ：

kubectl get all

打开 Jagger UI ：查找 simplest-query 服务的 NodePort 地址，然后打开 UI。

配置 Istio 服务网格引用 Jagger 的方法如下：
- 安装服务网格时 ：在 global.tracer.zipkin.address 变量中提供 Jagger 地址，例如 jagger-FQDN:16686 。
- 现有安装 ：编辑配置并指定 trace_zipkin_url 变量，使用以下命令进行编辑：

kubectl -n istio-system edit deployment istio-telemetry

配置 Envoy 代理开始生成追踪信息的方法如下：
- 安装 Istio 时 ：设置 pilot.traceSampling 变量。
- 现有安装 ：使用以下命令设置 PILOT_TRACE_SAMPLING 变量：

kubectl -n istio-system edit deploy istio-pilot

完成上述配置后，Envoy 将生成请求跨度并发送到 Jagger 服务器。我们可以通过执行以下命令对前端 Java 应用发送请求来验证：

for i in {1..500}; do  curl http://10.152.183.230/;echo ; done

然后在 Jagger UI 中搜索之前执行的请求，所有请求都将显示前端和 Web 应用的跨度信息。

4. 应用日志（Application Logs）

Istio 本身不支持管理 Kubernetes 集群中应用生成的日志。在大型部署中，每个应用生成的日志都存储在运行该应用的容器中，这给日志管理带来了很大挑战。

除了应用日志，应用还可以生成访问日志。在 Istio 服务网格中，所有请求都通过 Envoy 边车代理，边车会记录请求和响应信息。但由于容器重启会导致日志丢失，我们需要更好的解决方案。

Kubernetes 提供了一种集群级别的日志记录方法，它利用像 ELK、Splunk、Stackdriver 等日志后端应用，并结合服务网格的边车模式。完整的应用日志解决方案如下：
1. 应用写入日志文件 ：应用将日志写入通过卷挂载创建的文件中。
2. 运行日志解析容器 ：运行一个挂载了导出卷的容器，该容器运行 fluentd 进程进行日志解析。
3. 发送日志到后端 ：边车容器读取日志并将其发送到相应的后端。

以我们的前端应用为例，其配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-deployment
  # 省略部分内容
  containers:
  - name: frontend
    image: frontend-app:1.0
    imagePullPolicy: Never
    env:
    - name: LOG_PATH
      value: /var/log
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  # 省略部分内容
  - name: log-agent
    image: k8s.gcr.io/fluentd-gcp:1.30
    env:
    - name: FLUENTD_ARGS
      value: -c /etc/fluentd-config/fluentd.conf
    volumeMounts:
    - name: varlog
      mountPath: /var/log
    - name: config-volume
      mountPath: /etc/fluentd-config
  # 省略部分内容

fluentd.conf 文件的配置如下：

<source>
  type tail
  format /^\[[^ ]* (?<time>[^\]]*)\] \[(?<level>[^\]]*)\] (?<message>.*)$/
  time_format %b %d %H:%M:%S %Y
  path /var/log/spring.log
  pos_file /var/log/agent/spring.log.pos
  tag hostname.system
</source>
<match *.**>
  type forward
<server>...</server>
<!--removed for Brevity -->
</match>

在应用上述配置之前，我们需要部署 fluentd 聚合器，并将其配置为将数据发送到 ELK 堆栈。 fluentd 聚合器的示例配置如下：

<match **>
       type elasticsearch
       log_level info
       host elasticsearch
       port 9200
       logstash_format true
       buffer_chunk_limit 2M
       buffer_queue_limit 8
       flush_interval 5s
       num_threads 2
 </match>

5. Mixer

Istio 使用可扩展的 Mixer 子系统来捕获所有遥测数据。Mixer 具有很高的灵活性，支持插拔式的监控和警报系统。它通过多个适配器将所需数据提交到不同的监控系统，如 Prometheus、StatsD 等。

将 Mixer 作为独立组件而不是嵌入到边车中的好处如下：
| 好处 | 说明 |
| ---- | ---- |
| 更符合设计原则 | Mixer 是 Istio 内置组件，更符合 Istio 的设计原则，而 Envoy 是 Lyft 的代理服务。 |
| 提高容错性 | Mixer 有很多外部依赖，容易出现网络故障，而 Envoy 必须在 Mixer 依赖不可用时继续运行。 |
| 增强安全性 | Mixer 集成了各种外部系统，可能存在安全漏洞，但这些问题可以在 Mixer 层面得到控制，每个 Envoy 实例的交互范围可以配置得很窄。 |
| 使边车更轻量级 | Istio 为每个实例部署边车，将第三方适配与边车分离可以使边车更敏捷。 |

Mixer 目前支持以下三种用例：
- 前置条件检查
- 配额管理（如 API 限制）
- 遥测报告（如日志和请求）

我们可以通过以下命令获取可用的适配器列表：

kubectl get crd -listio=mixer-adapter

输出结果如下：

NAME                              CREATED AT
adapters.config.istio.io          2019-07-14T07:46:10Z
bypasses.config.istio.io          2019-07-14T07:45:59Z
circonuses.config.istio.io        2019-07-14T07:45:59Z
deniers.config.istio.io           2019-07-14T07:46:00Z
fluentds.config.istio.io          2019-07-14T07:46:00Z
Kubernetes envs.config.istio.io   2019-07-14T07:46:00Z
listcheckers.config.istio.io      2019-07-14T07:46:00Z
memquotas.config.istio.io         2019-07-14T07:46:01Z
noops.config.istio.io             2019-07-14T07:46:01Z
opas.config.istio.io              2019-07-14T07:46:02Z
prometheuses.config.istio.io      2019-07-14T07:46:02Z
rbacs.config.istio.io             2019-07-14T07:46:03Z
redisquotas.config.istio.io       2019-07-14T07:46:03Z

通过以上步骤，我们可以实现对 Istio 服务网格的全面监控和日志追踪，从而更好地管理和维护微服务应用。

全面解析Grafana监控与Istio日志追踪技术（续）

6. 利用 Mixer 发送访问日志

前面我们已经能够将应用日志发送到 ELK 实例，接下来我们尝试利用 Mixer 发送访问日志。操作步骤如下：
1. 确定可用适配器 ：在开始之前，我们需要知道有哪些可用的适配器，通过以下命令获取：

kubectl get crd -listio=mixer-adapter

执行该命令后，会列出一系列可用的适配器，如之前所示：

NAME                              CREATED AT
adapters.config.istio.io          2019-07-14T07:46:10Z
bypasses.config.istio.io          2019-07-14T07:45:59Z
circonuses.config.istio.io        2019-07-14T07:45:59Z
deniers.config.istio.io           2019-07-14T07:46:00Z
fluentds.config.istio.io          2019-07-14T07:46:00Z
Kubernetes envs.config.istio.io   2019-07-14T07:46:00Z
listcheckers.config.istio.io      2019-07-14T07:46:00Z
memquotas.config.istio.io         2019-07-14T07:46:01Z
noops.config.istio.io             2019-07-14T07:46:01Z
opas.config.istio.io              2019-07-14T07:46:02Z
prometheuses.config.istio.io      2019-07-14T07:46:02Z
rbacs.config.istio.io             2019-07-14T07:46:03Z
redisquotas.config.istio.io       2019-07-14T07:46:03Z

选择合适的适配器配置 ：根据我们的需求，选择合适的适配器来发送访问日志。例如，如果我们想将日志发送到 ELK 堆栈，可以选择 fluentds 适配器。
配置适配器 ：编写相应的配置文件，配置适配器将访问日志发送到指定的日志后端。具体的配置内容需要根据所选适配器和日志后端的要求进行编写。

7. 总结与最佳实践

通过前面的介绍，我们对 Grafana 监控、Istio 的分布式追踪、应用日志管理以及 Mixer 的使用有了全面的了解。以下是一些总结和最佳实践建议：

7.1 Grafana 监控

合理使用预配置仪表板 ：Grafana 提供的预配置仪表板可以快速帮助我们查看 Istio 网格的性能，节省时间和精力。
自定义仪表板 ：根据实际需求创建自定义仪表板，监控特定的指标，如请求速率、响应时间等。
设置有效警报 ：利用 Grafana 的警报功能，设置合理的阈值，及时发现潜在的问题。

7.2 分布式追踪

选择合适的追踪工具 ：根据项目的需求和规模，选择合适的分布式追踪工具，如 Zipkin、Jagger 等。
确保头信息传播 ：在应用中正确传播 b3 请求头，保证追踪信息的连贯性。
合理配置采样率 ：根据实际情况配置 Envoy 代理的采样率，避免产生过多的追踪数据。

7.3 应用日志管理

采用集群级日志方案 ：使用 Kubernetes 推荐的集群级日志方法，结合边车模式和日志后端应用，如 ELK、Splunk 等，确保日志的持久化和可查询性。
优化日志解析配置 ：合理配置 fluentd 等日志解析工具，提高日志解析的准确性和效率。

7.4 Mixer 使用

理解 Mixer 的优势 ：认识到 Mixer 作为独立组件的优势，如符合设计原则、提高容错性、增强安全性和使边车更轻量级等。
按需选择适配器 ：根据不同的监控和警报需求，选择合适的 Mixer 适配器。

以下是一个简单的 mermaid 流程图，展示了整个监控和日志追踪的流程：

graph LR
    A[应用请求] --> B[Envoy 代理]
    B --> C{Mixer 处理}
    C -->|遥测数据| D[监控系统（如 Prometheus）]
    C -->|日志数据| E[日志后端（如 ELK）]
    B -->|追踪数据| F[追踪后端（如 Jagger）]
    D --> G[Grafana 展示与警报]
    E --> H[日志查询与分析]
    F --> I[追踪查看与分析]

通过遵循这些最佳实践，我们可以更好地利用 Grafana 和 Istio 的功能，实现对微服务应用的高效监控和管理。