如何用istio实现监控和日志采集

本文介绍了如何使用Istio实现监控和日志采集,通过Bookinfo应用程序作为示例,详细阐述了配置遥测数据、验证数据采集以及配置metrics和logentries的过程,展示了Istio在服务网格中的监控能力。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

大家都知道istio可以帮助我们实现灰度发布、流量监控、流量治理等一些功能。每一个功能都帮助我们在不同场景中实现不同的业务。那我们Istio是如何帮助我们实现监控和日志采集的呢?

这里我们依然以Bookinfo应用程序作为贯穿此任务的示例程序。首先在集群中安装并部署Istio。

收集遥测数据

  1. 创建一个新的YAML文件,用来保存Istio将自动生成和收集的新度量标准和日志流的配置。如下图所示

通过命令$ kubectl apply -f new_telemetry.yaml推送刚刚配置的YAML文件。

然后去请求应用程序来生成流量,例如在本用例中就可以访问Bookinfo

完成访问,接下来我们就可以验证是否采集到了刚刚的请求数据。在Kubernetes环境中,通过执行以下命令为Prometheus设置端口转发:

$ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 &

通过Prometheus UI查看新指标的值。执行对istio_double_request_count度量值的查询。Console选项卡中显示的表 包含类似于以下内容的条目:

验证是否已创建日志流并正在为请求填充日志流。在Kubernetes环境中,搜索istio-telemetry pod的日志,如下所示:

从打印的信息中,我们可以清楚的看到日志级别、生成时间、实例名称、访问组件名称等等信息。

遥测配置

    在上面的实践中,我们已经完成了Istio收集数据并打印日志的一个过程。那么Istio是如何做到的呢?其实我们已经给Istio做了配置,指示Mixer自动生成并上报服务网格中采集的metric信息和日志流。在这个配置中我们主要设置了mixer的三个功能:

从Istio的属性中生成实例信息,比如在我们上面的实践中打印的metric和日志信息。

创建出adapter适配器,可以帮助我们处理生成的实例。

根据定义的规则向adapter发送实例信息。

metrics配置

   配置metrics是为了指示Mixer将metric发送到Prometheus。它使用三个模块来进行配置:实例配置、处理程序配置和规则配置。

metric配置的模块定义了用于生成metric。此实例配置根据Envoy报告的属性(由Mixer自身生成)告诉Mixer 如何为任何给定请求生成metric。

dimensions为每个实例指定一组维度。提供了根据查询的不同需求和方向对metric据进行分片,聚合和分析的方法。例如,可能需要在对应用程序行为进行故障排除时仅考虑对特定目标服务的请求。

日志配置

   日志配置指示Mixer将日志条目发送到stdout。它同样使用三个模块来进行配置:实例配置,处理程序 配置和规则配置。

   logentry配置的部分定义了用于生成日志条目实例。此实例配置告诉Mixer 如何 根据Envoy报告的属性为请求生成日志条目。

   severity参数用于指示任何生成的日志级别 logentry。在此示例中,使用了参数值"warning"。此值将由logentry 处理程序映射到支持的日志记录级别。

   Timestamp参数提供所有日志条目的时间信息。在此示例中,时间request.time由Envoy 提供的属性值提供。

   variables参数允许操作员配置每个值中应包含的值logentry。一组表达式控制从Istio属性和文字值到构成a的值的映射logentry。在此示例中,每个logentry实例都有一个名为latency使用属性值填充的字段response.duration。如果没有已知值response.duration,则该latency字段将设置为持续时间 0ms。

    stdio配置定义了处理程序命名newhandler。处理程序spec配置stdio适配器代码处理接收 logentry实例的方式。该severity_levels参数控制字段的logentry 值如何severity映射到支持的日志记录级别。这里,值"warning"被映射到WARNING日志级别。该 outputAsJson参数指示适配器生成JSON格式的日志行。

    rule配置定义一个新的规则命名newlogstdio。该规则指示Mixer将所有newlog.logentry实例发送到 newhandler.stdio处理程序。由于match参数设置为true,因此将对网格中的所有请求执行规则。

目前华为云容器引擎CCE全面支持Istio~12月12日——12月31日,华为云12.12会员日活动还有钜惠活动,云容器产品钜惠促销等你来~

点此参与~ http://t.cn/Ebc4Lwo

<think>嗯,用户的问题是关于使用Prometheus Operator的ServiceMonitorPodMonitor来监控Istioistio-system命名空间下的组件,同时他们使用的是外部的Prometheus,而不是Istio自带的。这导致Kiali没有数据显示。我需要一步步理清思路,确保回答准确。 首先,用户的情况是Kiali连接的是外部Prometheus,而Istio可能默认配置了自己的Prometheus,但用户没有使用那个。所以需要让外部Prometheus能够采集Istio的相关指标。这时候,ServiceMonitorPodMonitor就是关键,因为Prometheus Operator通过这两种资源来定义监控目标。 接下来,我需要确认Istio组件的监控指标是否已经暴露。例如,istiod、istio-proxy等是否提供了/metrics端点。通常,Istio默认会暴露这些指标,但可能需要检查ServicePod的标签是否正确,以便ServiceMonitor/PodMonitor能够匹配到。 然后是编写ServiceMonitorPodMonitor的配置。ServiceMonitor用于监控Service对应的Pod,而PodMonitor直接监控Pod,不需要经过Service。例如,istiod作为一个Deployment,可能有自己的Service,这时候用ServiceMonitor比较合适。而像Envoy这样的sidecar可能更适合用PodMonitor,因为它们可能没有对应的Service。 需要确保这些Monitor资源被部署到正确的命名空间,并且Prometheus Operator能够发现它们。如果Prometheus是外部的,可能需要调整其服务账户的RBAC权限,确保有权限访问istio-system命名空间下的资源。 另外,Prometheus自身的配置需要确保监视到了这些ServiceMonitorPodMonitor。可能需要检查Prometheus的配置中是否有匹配的selector,比如通过标签选择器来识别这些监控配置。 用户应用配置后,需要验证指标是否被正确采集。可以通过Prometheus的UI查询特定的Istio指标,如istio_requests_total,确认是否有数据返回。如果没有,可能需要检查Prometheus的日志,查看是否有权限问题或网络问题导致无法抓取指标。 最后,确保Kiali正确配置了Prometheus的地址。如果KialiPrometheus不在同一集群,可能需要处理网络策略或使用Ingress来暴露Prometheus的API。 总结步骤应该是:检查指标暴露情况 → 创建ServiceMonitorPodMonitor → 配置RBAC → 验证Prometheus抓取 → 配置Kiali连接。同时需要提醒用户注意标签匹配、网络可达性以及版本兼容性问题。</think>以下是为您梳理的解决方案步骤: 一、前置检查 1. 确认外置Prometheus已安装Prometheus Operator 2. 验证Istio组件是否暴露指标: ```shell kubectl -n istio-system get pods -l app=istiod -o jsonpath='{.items[*].spec.containers[*].ports}' | grep 15014 # 应看到metrics端口配置 ``` 二、创建监控资源配置 1. ServiceMonitor示例(监控istiod): ```yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: istiod-monitor namespace: istio-system # 必须与Prometheus所在namespace相同或配置跨ns发现 spec: endpoints: - port: http-monitoring # 对应service的端口名称 interval: 15s namespaceSelector: matchNames: - istio-system selector: matchLabels: istio: pilot # 匹配istiod service的标签 ``` 2. PodMonitor示例(监控Envoy sidecar): ```yaml apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: envoy-stats-monitor namespace: istio-system spec: podMetricsEndpoints: - path: /stats/prometheus # Envoy特有指标路径 port: http-envoy-prom namespaceSelector: matchNames: - istio-system selector: matchLabels: app: istio-proxy # 匹配Envoy容器 ``` 三、关键配置点 1. Prometheus资源配置需包含: ```yaml serviceMonitorNamespaceSelector: {} serviceMonitorSelector: {} podMonitorNamespaceSelector: {} podMonitorSelector: {} ``` 2. RBAC配置(若Prometheus在单独ns): ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus-istio rules: - apiGroups: [""] resources: ["services","endpoints","pods"] verbs: ["get","list","watch"] ``` 四、验证步骤 1. 检查Targets状态: ```shell kubectl port-forward -n monitoring svc/prometheus-k8s 9090 # 浏览器访问localhost:9090/targets 查看UP状态 ``` 2. 查询指标验证: ```promql istio_requests_total{namespace="istio-system"} ``` 五、Kiali对接配置 1. 修改Kiali CRD配置: ```yaml spec: external_services: prometheus: url: "http://prometheus-operated.monitoring.svc:9090" # 若跨命名空间需使用完整FQDN ``` 六、常见问题排查 1. 指标抓取失败检查方向: - 检查Service/Pod的标签是否与Monitor选择器匹配 - 验证网络连通性(Prometheus到istio-system Pod的网络策略) - 查看Prometheus日志过滤`error="server returned HTTP status"` - 确认指标端口未被Istio mTLS拦截(可添加annotation:`prometheus.io/scheme: http`) 建议优先从PodMonitor开始调试,因为Istio组件的指标暴露方式存在版本差异(1.10+版本指标端点有变化)。如果使用最新版Istio,需注意控制平面指标路径已改为`/metrics`标准路径。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值