可观测性平台调研与实践

整理云原生可观测性平台的指标、日志、链路追踪、Langfuse、InfluxDB 优化和告警 API 相关实践。

本文由内部 DOCX 技术文档整理而来，已移除目录前的模板页与前置信息；正文内容、截图与操作步骤按博客阅读方式重新排版。

在开发和运维的过程总不可避免的对服务的运行状态，错误处理，异常恢复等都有着明确的需求，传统的单一数据源无法有效的整体分析异常状态。因此提出一个all in one的可观测性解决方案，实现开箱即用、灵活扩展的集成解决方案。

本文适用于了解可观测集成方案中的一些实现过程和细节内容。

引用文件

https://sustainable-computing.io/zh/archive/design/metrics/

可观测性

可观测性（Observability）是指通过对系统外部输出（如指标、日志、追踪数据）的收集和分析，来推断和理解系统内部运行状态的一种能力。它与传统监控（Monitoring）的区别在于：监控通常是基于预先设定的告警条件，关注“已知的问题”；而可观测性则更强调对“未知的问题”进行探索和定位，帮助工程师在复杂环境下理解系统行为和根因。

在现代云原生架构中，系统规模庞大、组件分布广泛，传统监控往往难以应对快速变化和复杂依赖关系。可观测性的重要性在于，它不仅能帮助运维人员确认系统是否健康，还能为开发人员、架构师提供更深入的洞察，从而更快地发现问题、优化性能，并提升整体可靠性。

可观测性的核心由三大支柱构成：

指标（Metrics）：量化的数值型数据，如 CPU 使用率、请求延迟、错误率，适合做趋势分析和健康检查。

日志（Logging）：详细的离散事件记录，可以追踪请求处理过程中的具体细节，常用于问题诊断和审计。

追踪（Tracing）：分布式系统中请求在不同服务之间的调用链路信息，用于定位性能瓶颈和依赖关系。

三者结合，能够让团队更全面地理解系统运行状态，从而支撑快速排错和持续优化

可观测性解决方案的核心价值

统一可观测性平台的核心价值在于提供了一体化的企业级 Kubernetes 可观测性解决方案，将指标监控、日志管理、分布式追踪与客户化数据服务深度融合，帮助企业在复杂的云原生环境中实现对系统运行状态的全方位洞察。通过集成 Prometheus、Grafana、Elasticsearch、DeepFlow 等业界领先的工具，并加入 Kepler 进行能效与资源监控，平台不仅具备开箱即用的特性，还支持灵活扩展和企业级特性，如高可用性、安全认证、多租户和外部数据库对接。

在能力层面，该方案覆盖了可观测性的三大支柱：指标监控方面，能够从集群、节点、Pod 到应用的全链路收集和可视化性能数据，并支持告警与能效分析；日志管理方面，提供高性能的日志收集、存储与搜索能力，并借助 Kibana 进行可视化和问题定位；分布式追踪方面，通过 DeepFlow 等组件实现跨服务调用链的分析，帮助快速定位性能瓶颈与依赖问题；此外，平台还内置 客户化数据服务，为企业提供 API 接口与数据处理能力，支持个性化扩展与集成。

整体而言，该平台不仅提升了问题排查和性能优化的效率，也为企业建立了可持续演进的可观测性能力，支撑更高水平的运维自动化和业务可靠性。

下文将从以下的结构来进行整体可观测性的介绍。

可观测性的集成方案，通过集成3部分指标的helmchart部署方案来实现对，logging，metrics，tracing这三大模块的数据获取。

大模型可观测组件langfuse的集成与使用。介绍langfuse的使用方式以及核心的监控表盘

Influxdb数据库优化与使用。使用influxdb作为集群的监控指标存储模块，优化查询效率。

监控告警api研发使用。通过配置开发api的形式方便的操作后台资源来创建出符合需求的监控告警转发通道。

可观测平台使用下的多个关键指标的观测。通过梳理多个层面的如宿主机级别，容器级别，服务指标，功耗指标等。我们的可观测性平台可以将多个关键指标进行有效观测。

可观测性项目的实施，不仅是技术的集成，更是对企业运维和开发模式的一次全面升级。我们成功地将指标、日志、追踪三大支柱与前沿的 AI 应用观测能力、高性能数据存储和自动化告警机制深度融合，为复杂云原生环境下的系统健康和业务连续性提供了坚实的保障。我们从监控的被动相应进步为了主动洞察，主要体现在一下三维度。

数据融合与全面覆盖：通过helm chart部署方案实现了metric，loging，tracing数据的标准化自动化采集。平台具备了对宿主机、容器、服务、应用直至功耗指标的端到端观测能力，消除了数据孤岛，使问题排查的根因定位时间减少。

对influxdb进行了深度优化，通过优化存储方案构建task等方式减少存储数据的基数并且提高了查询效率。为后续的数据处理奠定基础。

支持业务创新，通过集成langfuse对热门的大模型调用进行有效的观测，可以看到每次问答的token消耗，prompt管理，以及查询延迟等分析大模型业务的使用瓶颈。

可观测性平台构建详细过程

可观测性集成方案

该统一可观测性平台采用了先进的模块化、分层架构，以解决现代云原生环境下的复杂性挑战。平台设计完全基于 Kubernetes 集群构建，这确保了所有组件具备高可用性、弹性和横向扩展能力。其核心优势在于将**指标（Metrics）、日志（Logging）和追踪（Tracing）这三大可观测性支柱进行了深度且无缝的整合，并非简单工具堆砌。通过将所有核心组件及其配置封装为 Helm Chart，平台实现了开箱即用（Out-of-the-Box）**的一键式部署和统一管理，极大地简化了运维复杂度，同时为未来根据业务需求进行灵活的组件升级和替换打下了坚实基础。

这种架构不仅在技术层面保证了全栈数据的采集和关联分析能力，而且通过统一的云原生部署范式，确保了可观测性平台本身与被监控的业务系统保持技术栈的一致性，从而建立了可持续演进的企业级可观测性数据中枢。

• 数据流向：

• 采集层：通过 Prometheus 相关 Exporter（如 kube-state-metrics, prometheus-node-exporter）、Filebeat 和 DeepFlow Agent，从 Kubernetes 集群的各个组件、节点和应用中无侵入地采集原始数据。

• 处理与存储层：采集到的数据被分别送往不同的后端：

• 指标数据由 Prometheus 存储在时序数据库中，或者通过 Thanos Ruler 进行统一管理。

• 日志数据由 Filebeat 传输到 Elasticsearch 进行索引和存储。

• 追踪数据则由 DeepFlow Server 进行处理，并写入高性能的 ClickHouse 或 Byconity 数据库。

• 展示与告警层：最终，数据通过 Grafana、Kibana 和 DeepFlow App 等可视化工具进行统一展示。Alertmanager 则负责处理 Prometheus 的告警规则并发送通知。

指标监控

通过部署kube-statck-metric组件来实现的，包含如下的主要组件，grafana，node-xeporter,alertmanager等，并且通过改造values.yaml文件内容，将部分核心参数配置开关与适配templates模板实现values文件-template渲染-部署资源控制的链路。

通过集成 Prometheus Operator、Grafana、Alertmanager 等核心组件，实现了从数据采集、存储到可视化、告警的全链路监控能力。

• Prometheus Operator：自动化部署与管理 Prometheus 实例，简化监控规则与配置。

• kube-state-metrics 与 Node Exporter：分别提供 Kubernetes 对象状态指标与主机系统指标。

• Kepler：用于容器能效与资源使用的细粒度监控，补齐能耗维度的观测能力。

• Grafana：可视化指标数据，预置集群、节点、Pod、应用等多维度仪表盘。

• Alertmanager：提供告警聚合、抑制和通知，支持邮件、Webhook 等方式。

从上面的部署结果可以看到与监控有关的metric系统都运行正常，采集到数据用来监控集群中时间信息。并且将其集成到helm部署中方便管理与快速部署。监控的项目除了固有的cpu，memory等还添加了功率相关的kepler metric，拥有了获取更多维度信息的能力。

日志管理

在可观测性体系中，**日志（Logging）**是核心三大支柱之一。日志不同于指标监控，它记录了系统运行过程中的详细事件与上下文信息，可以帮助我们回答“系统为什么出现问题”。在云原生架构中，容器与 Pod 生命周期非常短暂，节点和实例会频繁变化，因此需要通过集中化的日志收集、存储和查询平台来保障日志的完整性与可用性。

• 架构与组件

在本平台的日志监控中，主要由以下组件构成：

• Filebeat：轻量级日志收集器，以 DaemonSet 方式运行在集群的每个节点上，自动采集容器和系统日志，并将其转发到 Elasticsearch。

• Elasticsearch：分布式搜索与存储引擎，用于高效存储日志数据并提供索引功能，支持快速的检索与聚合分析。

• Kibana：可视化与交互查询界面，允许用户以直观的方式浏览、过滤和分析日志数据。

整体数据流为：

应用容器输出日志 → Filebeat 采集 → Elasticsearch 存储与索引 → Kibana 展示和查询。

在日志监控模块的实现过程中，我们通过 Helm Chart 集成部署了 Elasticsearch、Filebeat、Kibana 等组件。具体过程如下：

• Filebeat 部署

• 以 DaemonSet 模式运行，确保每个节点上的容器日志和系统日志都能被采集。

• Filebeat 通过自动发现机制识别 Kubernetes Pod 日志，并以统一格式推送至 Elasticsearch。

• Elasticsearch 部署

• 作为日志数据的核心存储，Elasticsearch 集群提供了高可用的存储与索引能力。

• 所有来自 Filebeat 的日志经过解析后写入 Elasticsearch，并基于索引结构进行存储，便于后续查询与分析。

• Kibana 部署与访问

• Kibana 提供了 Web UI 界面，用户可以通过浏览器直接登录进行日志检索与可视化分析。

• 在首次访问 Kibana 时，通过 Secret 中获取了默认的 elastic 用户和密码完成登录。

• 成功进入 Kibana 后，可以在 Discover 页面实时查看并过滤日志数据。

日志管理模块的ELK架构如下，每个组件有特定的功能和作用，通过集成helm chart改造原有的模板并且提供配置项，可以实现将ELK服务与之前监控，tracing等其他项目结合起来实现统一管理和部署。

运行起来后进入kibana可以可视化的看到采集到的日志信息。效果如下所示。

分布式追踪

在云原生微服务架构中，一个请求往往需要经过多个服务协作才能完成。传统的指标与日志虽然能提供部分信息，但难以完整呈现一个请求在整个系统中的生命周期。**分布式追踪（Tracing）**正是为了解决这一问题而设计，它能够将请求在不同服务间的调用链路可视化，帮助快速定位性能瓶颈与故障点。

• 架构与组件

在本平台中，分布式追踪部分由以下组件构成：

• DeepFlow Agent：基于 eBPF 技术的全栈、无侵入式数据采集器，自动从内核、应用和网络层收集追踪数据，无需改造业务代码。

• DeepFlow Server & App：负责对采集到的数据进行处理和聚合，并提供追踪查询与分析能力。

• ClickHouse：高性能列式存储数据库，用于存储大规模追踪数据，支持高效的检索与统计分析。

数据流为：

应用请求 → DeepFlow Agent（采集调用/网络数据） → DeepFlow Server（解析、聚合） → ClickHouse（存储） → DeepFlow App（链路追踪可视化）。

• 部署与实现

Tracing 部分通过 Helm Chart 集成了 DeepFlow + ClickHouse，具体实现如下：

• DeepFlow Agent 部署

• 以 DaemonSet 模式运行在每个 Kubernetes 节点，自动采集所有 Pod 的调用链路和网络交互数据。

• 利用 eBPF 技术实现无侵入式采集，避免了传统 SDK 插桩带来的性能损耗与开发改造工作。

• DeepFlow Server 与 App 部署

• DeepFlow Server 负责接收 Agent 上报的数据，并进行解析、聚合和归类。

• DeepFlow App 提供可视化界面，支持调用链路展示、性能瓶颈分析和请求全生命周期追踪。

• ClickHouse 部署

• 作为后端存储，ClickHouse 提供高性能的日志与追踪数据存储能力。

• 结合 DeepFlow，可对高并发场景下的大规模链路数据进行秒级查询与分析

其架构图如下所示：

在我们集成的grafana中可以看到deepflow的相关信息

至此将监控，日志，追踪三大模块的功能都集成在一个helmchart中，可以方便的进行部署和使用管理等。实现数据源采集的融合为以后的数据使用与构建解决方案提供原始数据的基础。

AI可观测性langfuse

在现在的方案针对AI使用我们想用可观测性的内容对其进行监控与管理，经过了解后选择langfuse作为监控AI生命周期的可观测工具来进行管理。

Langfuse是一个专为大型语言模型（LLM）应用程序设计的可观测性（Observability）和可调试性（Debugging）平台。随着越来越多的应用集成LLM，开发者们面临着新的挑战，例如追踪输入和输出、评估模型表现、优化成本以及理解用户交互流程。Langfuse就是为了解决这些问题而诞生的，它提供了一个中心化的系统，帮助你全面了解你的LLM应用在生产环境中的运行情况。

Langfuse的定位与作用

在传统的软件开发中，我们有成熟的工具来监控应用的性能、错误和日志。但对于LLM应用，情况变得更加复杂。一个简单的API调用可能包含多个步骤，比如检索、调用多个模型、链式反应等。这些过程的不透明性使得调试变得异常困难。

• 调试和问题排查：当LLM返回了不准确、偏离预期或者格式错误的结果时，你很难直接找到问题所在。是提示词写得不好？是上下文信息不准确？还是模型本身出了错？Langfuse通过记录每一个步骤，将整个调用过程可视化，让你可以轻松地追溯问题根源。

• 性能和成本优化：LLM的调用成本不容忽视。不同的模型、不同的API调用都会产生不同的费用。同时，响应速度也是用户体验的关键。Langfuse能帮你监控每次调用的延迟和Token使用量，让你能够识别出性能瓶颈和高成本的操作，从而进行优化。

• 质量评估和迭代：你如何判断一个新版本的提示词或模型是否比旧版本更好？人工评估（Human in the Loop）是至关重要的一环。Langfuse提供了一个界面，让你可以对模型的输出进行评分、添加评论，甚至直接进行A/B测试，将评估结果与特定的调用数据关联起来，为你的模型迭代提供数据支持。

Langfuse 的核心意义和作用

Langfuse的作用可以概括为以下几点，它们共同构成了一个完整的LLM应用开发闭环。

• 全面的可观测性：Langfuse将LLM应用的运行数据进行结构化和可视化。你可以清晰地看到每一次调用、每一个“Trace”（追踪），包括输入、输出、中间步骤、延迟、Tokens使用、成本估算等。它就像一个“黑匣子”，将LLM内部复杂的工作流展现在你面前。

• 简化调试流程：它记录了从用户请求到最终响应的每一个细节，包括链式调用中的每一次API请求。如果某个环节出错，你可以直接点击进入这个特定的“Trace”，查看所有相关的上下文信息，例如完整的提示词、模型响应、以及任何自定义的元数据。这大大减少了手动翻阅日志和猜测问题的时间。

• 促进团队协作和持续改进：Langfuse提供了一个共享平台，团队成员可以在上面共同审查和评估模型的表现。通过对特定的模型输出进行评分和标记，团队可以收集宝贵的反馈数据，这些数据可以用于微调模型或优化提示词。这种反馈循环机制是持续改进LLM应用质量的关键。

• 数据驱动的决策：借助Langfuse的分析功能，你可以生成关于模型表现、成本和延迟的报告。这些数据可以帮助你做出更明智的决策，比如选择最经济高效的模型，或者优化那些响应时间过长的步骤，从而提升用户满意度和业务效率。

Langfuse部署与使用

使用helm命令可以直接部署langfuse

helm install langfuse langfuse/langfuse -n langfuse -f values.yaml

部署完成后有访问页面创建项目注意会有token配置。

通过生成项目的apikeys，在dify中有对应的配置项可以将ai的相关数据发送到langfuse中被其监控起来

Langfuse的核心功能

Langfuse的功能主要体现在以下几个方面，可观测性，提示词管理，模型评估，

可观测性上的能力有

日志追踪

最底层的过程透明度

了解全部的花费和延迟

提示词管理

版本控制和部署

团队合作管理提示词

针对提示词和模型的A/B测试

模型，提示词评估

评估输出内容的质量

监控产品的健康状态

开发测试改动

可观测性

可观测性（Observability）对于理解和调试 LLM 应用至关重要。与传统软件不同，LLM 应用涉及复杂且非确定性的交互，这使得监控与调试变得更加具有挑战性。Langfuse 提供了完善的追踪能力，帮助开发者准确理解应用中发生的每一步。

首先，Langfuse 的 追踪（Tracing） 能够记录所有与 LLM 相关和非 LLM 的调用。这包括检索（retrieval）、向量嵌入（embedding）、API 请求等操作，确保应用中的关键过程都能被完整捕捉。

其次，Langfuse 支持对 多轮对话 进行跟踪，将其表示为会话（session），并提供用户级别的追踪。这对于理解复杂的用户交互场景和模型响应模式非常有帮助。

此外，Langfuse 可以将 智能体（agents） 表示为图结构，清晰展现不同组件之间的调用关系和数据流动，方便调试和优化整体应用逻辑。

打开langfuse的首页可以看到有很多表盘，里面涉及到的主要是大模型交互过程中可以量化的内容被收集到这里。

在 首页（Home） 中，Langfuse 会展示全局概览，包括调用量、延迟、错误率以及成本等核心指标。开发者可以快速掌握应用在某一时间段内的整体健康状况，并通过趋势图识别潜在问题。

在 Dashboard 中，Langfuse 提供了更细粒度的表盘，用于监控与 AI 应用密切相关的关键数据。这些主要表盘包括：

• 请求量（Request Volume）

• 记录一段时间内 LLM 调用的次数。

• 体现应用的使用活跃度和用户请求规模。

• 延迟（Latency, 包含平均值和 P95 延迟）

• 衡量模型响应所需时间。

• P95 延迟表示 95% 的请求都在某个时间内完成，是衡量用户体验的重要指标。

• 能帮助开发者判断应用在高负载下是否仍然能保持稳定的交互体验。

• 错误率（Error Rate）

• 统计调用失败的比例，例如 API 错误、超时或无效响应。

• 用于快速发现系统问题或模型在某些场景下的稳定性不足。

• Token 使用情况（Token Usage）

• 记录输入和输出的 token 消耗量。

• 与 AI 成本直接相关，也是优化 Prompt 和调用逻辑的重要参考。

• 成本（Cost Tracking）

• 根据模型调用量和 token 消耗自动估算成本。

• 体现应用的经济性，帮助团队在功能和预算之间做权衡。

• 用户反馈（User Feedback / Ratings）

• 如果集成了人工反馈，会展示用户对模型输出的评价。

• 这反映了模型在真实场景下的有效性和用户满意度。

• 会话追踪（Session Tracking）

• 记录多轮对话中的调用链路。

• 能帮助分析复杂的用户交互，并发现在哪些步骤模型表现不佳。

Tracing 模块

Tracing 模块用于对每一次 AI 调用进行全链路追踪。它会记录调用的上下文信息，包括 Prompt 输入、模型返回结果、调用耗时以及可能的错误。通过 Tracing，团队可以对单次调用进行详细分析，定位问题根源，并优化 Prompt 设计或调用方式。这类似于传统系统中的分布式追踪，但专注于 AI 模型的调用链。

Sessions 模块

Sessions 模块聚焦于用户与 AI 应用的一次完整交互会话。例如，一个用户可能在一次对话中多次与模型交互，Sessions 会将这些请求统一归档，形成一个连续的上下文记录。这样，团队能够了解 AI 在对话或任务中的连贯性表现，评估模型是否在长对话、多轮交互中保持准确和一致。

Users 模块

Users 模块关注使用系统的用户维度信息。通过该模块，团队可以看到哪些用户调用最频繁，用户交互中是否存在高错误率，或者不同用户群体的使用习惯。结合用户数据，团队能够更好地理解 AI 应用的受众特征，并针对性地优化模型表现，从而提升用户满意度和留存率。

Prompt管理

在 LLM 应用中，Prompt 是控制模型输出的核心要素。Langfuse 提供了完善的 Prompt 管理功能，使 Prompt 不再只是散落在代码中的文本，而成为可以科学管理和优化的资产。

首先，Langfuse 支持 Prompt 管理。开发者可以在平台上创建、编辑和组织所有 Prompt，并通过变量化方式实现动态内容插入。例如，可以在同一个 Prompt 模板中使用 {{user_input}} 占位符，灵活适应不同用户请求。这种集中管理方式确保了 Prompt 的可复用性和一致性。

其次，Langfuse 提供 版本控制和部署 功能。每一次 Prompt 的修改都会生成新版本，同时保留历史版本，方便回滚或审查。开发者可以选择将稳定版本部署到生产环境，而在开发环境测试最新版本，从而实现类似软件的 CI/CD 流程。这种机制避免了 Prompt 修改后直接影响线上表现的风险。

此外，Langfuse 支持 团队协作。平台提供 Web 界面和评论功能，团队成员可以查看 Prompt 历史、发表评论或进行评审。这使得 Prompt 管理不仅是个人行为，而是团队协作的成果，保证多人的修改不会互相覆盖，并提升整体 Prompt 质量。

最后，Langfuse 提供 Prompt 测试和评估 功能。开发者可以在平台上对 Prompt 的不同版本进行 A/B 测试，观察输出质量、延迟、错误率和用户反馈等指标。通过自动化评估（规则校验或 judge 模型）和人工标注，团队能够科学地优化 Prompt，使模型输出更准确、更符合业务需求。

总体来说，Langfuse 的 Prompt 功能把 Prompt 管理从分散的文本变成 可版本化、可协作、可评估的工程资产，帮助团队在保证质量的前提下高效迭代 LLM 应用。

提示词模型评估

Langfuse 的 Evaluation 模块负责将 LLM 应用的输出质量以可量化、可追踪的方式进行衡量与管理。与传统系统不同，LLM 应用输出具有非确定性、格式多样以及业务语义依赖强等特点，Evaluation 模块把自动化判定、人工标注与业务指标结合起来，形成“持续评估 → 监控 → 反馈优化”的闭环，帮助团队把主观感受转化为工程化的决策依据。

为了衡量输出质量，Langfuse 支持多种评估方法：自动化规则检查用于验证输出是否满足格式或约束（例如 JSON schema 校验、必含字段、禁止词检测）；基于 judge 模型的评分用于对语义质量进行打分，例如用一个强判定模型给生成结果打准确性/完整性/可读性等维度的分数；人工评估用于收集真实用户或内部标注者对结果的主观评价（如好/差、1–5 分），并将这些人工标注与自动化结果一起存储用于后续分析。

在衡量指标上，Langfuse 常用的衡量项包括正确率（accuracy）、精确度/召回（precision/recall，适用于抽取类任务）、格式合规率（schema pass rate）、用户满意度（thumbs up/down、NPS），以及延迟与资源消耗相关的成本度量（平均 token 消耗、每次调用成本）。这些指标既可以针对单条调用，也可以按 Prompt、按模型、按用例或按用户组进行分段聚合，从而支持横向对比和纵向追踪。

监控生产健康是 Evaluation 的重要方向。Langfuse 将质量指标与运行时指标（如错误率、P95 延迟、失败原因分布）结合在仪表盘上，支持实时告警与趋势分析。当某个 Prompt 或模型的评估分数持续下降或幻觉率/错误率上升时，系统可以触发告警并将相关 trace、session、用户数据打包，方便工程师直接定位到问题调用链路并展开回滚或修复。

在开发与发布流程中，Langfuse 支持在开发环境对 Prompt/模型变更进行预先测试。常见做法包括回放历史真实请求（replay）、用固定的数据集做 A/B 测试、以及在小流量灰度中对比新旧版本的评估指标。平台会将 A/B 测试结果按指定的评价指标（如任务成功率、用户满意度、成本差异）做统计显著性分析，帮助团队决定是否将改动推广到生产环境。

为提升评估精度，Langfuse 鼓励将自动化评估与人工评审结合：先用自动化规则和 judge 模型做第一轮筛选，再把边界样本与失败样本交给人工标注，用人工结果去校准自动评分器或训练自定义评估模型。此外，Langfuse 支持将用户交互事件（如用户反馈、后续行为是否完成任务）作为长期信号，用于衡量模型在真实业务目标上的有效性。

在实践层面，Langfuse 提供了一套可配置的评估模板和规则库，常见模板包括“格式校验（JSON/CSV）模板”、“敏感词检测模板”、“问答准确率评估模板”以及“对话连贯性评估模板”。工程师可以基于模板快速定义新的评估任务，配置自动化判定逻辑、人工标注面板与告警阈值，并把评估结果与 Tracing / Session / Users 三个模块打通，实现从单条 trace 到会话再到用户行为的全链路回溯。

最后，Langfuse 的 Evaluation 不仅是静态打分系统，而是一个持续迭代的平台：评估结果驱动 Prompt 优化、模型选择与流量分配；新的业务需求或错误类型可以转化为新的评估规则；并且评估历史为后续的因果分析、模型退化检测与合规审计提供了完整审计链路，帮助团队在保证质量与成本可控的前提下持续演进 LLM 应用。

Langfuse指标总结

可观测性

Langfuse 在可观测性方面主要监控 系统调用与性能健康，帮助团队理解大模型应用的运行状态和问题所在。主要指标包括：

• Traces（调用链记录）

• 含义：一次用户请求到模型响应的完整流程。

• 作用：统计总调用数、观察活跃度、回溯问题来源。

• Traces by Time（按时间统计调用量）

• 含义：不同时段的调用量分布。

• 作用：发现流量高峰和低谷，支持容量规划和资源调度。

• Observations by Level（日志级别统计）

• 含义：按 info、warn、error 等级统计系统事件。

• 作用：反映系统健康状况，错误过多提示潜在问题。

• Trace / Span Latency Percentiles（延迟分位数）

• 含义：统计调用或子流程的响应时间，常用分位数包括 p50、p90、p95、p99。

• 说明：

• p50：中位数，代表典型用户体验。

• p90：90% 的请求在该延迟内完成，衡量大部分请求体验。

• p95：95% 请求在该延迟内完成，常用作性能 SLA 指标，反映“尾部延迟”。

• p99：最慢的 1% 请求延迟情况，发现极端慢请求。

• 作用：帮助定位性能瓶颈，优化大模型调用流程。

• Model Costs / User Consumption（模型成本与用户消耗）

• 含义：记录 Token 使用量、费用和调用次数。

• 作用：支持成本控制、用户行为分析和多模型对比。

Prompt管理

Prompt 模块关注 模型调用的效率与行为，主要用于分析不同 Prompt 在大模型中的表现：

• Model Usage（模型使用量）

• 含义：按模型或调用类型统计 Prompt 执行次数和 Token 消耗。

• 作用：了解哪些 Prompt 被频繁调用，哪些模型执行效率高。

• Generation Latency（生成延迟）

• 含义：针对 Prompt 的响应时间统计。

• 作用：分析 Prompt 的执行效率，识别可能需要优化的 Prompt 逻辑。

• Cost by Prompt / Model

• 含义：不同 Prompt 或模型的调用成本。

• 作用：用于成本分析和优化模型选择。

评价得分

Score 模块关注 模型输出质量和用户反馈，支持持续改进和风险控制：

• Total Scores（总评分数）

• 含义：已追踪到的模型输出评分数量，可来自人工或自动化评估。

• 作用：量化输出质量，是衡量模型效果的核心指标。

• Scores Analytics（评分趋势分析）

• 含义：按时间展示分数变化、移动平均值等。

• 作用：分析模型迭代是否带来质量提升，发现潜在退化或问题。

• Evaluation 指标

• 含义：结合评分、用户反馈、规则检查等评估输出质量。

• 作用：在生产中发现潜在错误或幻觉，支持风险缓解和质量保障。

Langfuse 是一款专为大型语言模型（LLM）应用设计的一站式可观测性工具，专注于提供对整个生成式 AI 应用堆栈的深度洞察。它的核心价值在于弥补了传统可观测性工具在处理 LLM 特有数据（如提示词、Token 使用、生成质量和成本）方面的不足。Langfuse 能够自动捕获并追踪分布式应用中所有与 LLM 交互的调用链，包括用户输入、中间工具（如检索增强生成, RAG）、以及最终的响应。通过提供详细的追踪数据、量化的指标（如延迟、Token 消耗）以及关键的业务指标（如准确率和用户反馈），Langfuse 使工程师能够有效地诊断 AI 应用程序中的性能瓶颈、高昂的 Token 成本、以及提示词工程中的质量问题。它将 LLM 的运行状态转化为可分析、可优化的数据，是现代可观测性体系中支持 AI 驱动型业务连续迭代和提升用户体验的关键补充。

Influxdb的优化与使用

InfluxDB 是一种专门为时间序列数据（Time Series Data, TSDB）设计和优化的开源数据库。它高效地处理高写入和高查询负载，使其成为存储和分析指标（Metrics）数据的理想选择。与传统关系型数据库不同，InfluxDB 采用独特的存储引擎，对数据进行了时间索引优化，并引入了 Tags（标签） 和 Fields（字段） 的数据结构。Tags 用于存储元数据和索引（是查询的关键），而 Fields 用于存储实际的数值型数据。InfluxDB 的核心优势在于其出色的压缩能力和对时间范围查询的高性能表现。它通常作为 TICK 堆栈（Telegraf, InfluxDB, Chronograf, Kapacitor）或现代可观测性平台中的核心存储组件，负责支撑来自 Prometheus、Node Exporter 等各种采集源的大规模指标数据，并提供快速的数据聚合和下采样能力。

但是在实际的使用过程中发现默认情况下采集到的数据全部存储在一张表中，同时由于采集到的数据标签分布分散，特异性标签数量较多，并且filed字段较多导致单次查询的耗时十分长处于不可忍受的状态。因此进行了大量的工作用于分析和处理influxdb查询慢的问题并且给出最终的解决方案。通过优化存储形式将多个集群的数据分表存储，同时构建task将目标业务数据在后台实时的聚合实现对数据的降低频率获取以及将数据分类存储按照集群存储进一步降低查询数据的数据量和基数，进而大幅度提升查询效率。

基础背景

我们的目的是需要将api的查询耗时降低在200ms以内，数据库的查询与他的数据量，存储方案，参数配置等都有很大的关系。接下来将详细介绍影响influxdb查询的主要因素，以及和inluxdb有关的一些配置。

目前使用的influxdb部署起来用的cpu和memory资源如下

目前telegraf的配置如下所示，

Telegraf通过采集prometheus的federate全量metric数据接口，并且不做任何处理转发吐到influxdb中。

Telegraf 的 [agent] 配置是整个采集系统的“心脏”，它决定了数据采集、缓冲和发送的策略。以下是对重要参数的分析：

• 1. 数据采集与频率控制 (interval & flush_interval)

• interval = ”10s” (采集间隔)： 这个参数定义了 Telegraf 运行输入插件（Input Plugins）的频率。您的 Prometheus 插件配置了 interval = ”30s”，但其他插件（如 internal 和 statsd）将以 秒的间隔运行。这意味着 Telegraf 会以 秒的粒度不断从各个源头拉取数据。

• flush_interval = ”10s” (刷新/发送间隔)： 这个参数定义了 Telegraf 将缓冲区中的数据发送给输出插件（Output Plugins）的频率。

对性能的影响： 在您的配置中，采集和发送间隔都是 秒。这确保了数据能够 快速地 从 Telegraf 流向 InfluxDB。如果 flush_interval 设置得太短（如 秒），会增加对 InfluxDB 的写入压力（更多的 HTTP 请求）；如果设置得太长（如 秒），则可能导致数据延迟和缓冲区堆积。

• 2. 数据缓冲与安全 (metric_buffer_limit & metric_batch_size)

这是目前您面临 高负载写入 时 最关键 的两个参数，直接影响数据可靠性。

• metric_buffer_limit = 8000 (指标缓冲区上限)： 定义了 Telegraf 内存中 可以存储的最大指标点数量。这是 Telegraf 在 InfluxDB 写入失败、延迟或网络中断时用来 暂存数据 的安全区。

• 对存储和查询的影响： 如果缓冲区溢出（即超过 个指标点），超出的数据将被永久丢弃。由于您的 Prometheus 单次采集就有 万个点，这个 的限制是 远远不够的，会导致 大量的核心数据丢失。

• metric_batch_size = 5000 (指标批次大小)： 定义了 Telegraf 单次发送给 InfluxDB 的数据点最大数量。Telegraf 会将缓冲区的数据打包成不大于 个点的批次进行 HTTP 写入。

• 对写入存储的影响： 较大的批次大小可以 提高写入吞吐量，减少网络开销（因为 个点只需要 个 请求）。您目前 的批次对于 万的负载来说效率偏低（需要 次写入）。

• 3. 精度与主机名 (precision & omit_hostname)

• precision = "" (精度)： 如果留空，Telegraf 将使用 纳秒 (ns) 精度发送时间戳。

• 对存储的影响： 纳秒精度会占用更多的存储空间，并对 InfluxDB 的 引擎处理时间戳的效率略微产生影响。对于大多数监控场景，将精度降至 毫秒 (ms) 或 微秒 () 是一个常见的优化手段。

• omit_hostname = false (省略主机名)： false 表示 Telegraf 会自动将运行它的 主机名 作为 标签 添加到所有指标点中。

• 对查询和基数的影响： 如果主机名是高变动性（例如 K8s Pod 重建），它会增加基数。但通常在 K8s 环境中，我们会使用 host 标签来追踪数据来源，因此保留它是合理的，除非您有更严格的标签过滤策略。

Prometheus 数据在进入 InfluxDB 后，会被拆解并映射为以下核心概念：

Series 是如何计算和构成的？以一个数据点为例：

Mesaer

Xnet,node_memor,instance=masater,5.5 -time_s 2040.4444..444

InfluxDB 里有一个非常关键的概念：series cardinality（时间序列基数）。

它的定义是：

cardinality = measurement × 所有 tag key 的唯一组合数

也就是说，只要任意一个 tag value 不同，就算一个新的 series。 这个数量是 InfluxDB 内存占用和性能的关键因素。

假设有一个prometheus的metric kepler_container_bpf_net_rx_irq_total

他有以下这些tag

instance=master,worker1,worker2 (3种)
pod=observability-kepler-xxxx (100种，Pod可能频繁重建)
container_id=kernel_processes,... (50种)
namespace=xnet,kube-system,... (5种)

那么这一条prometheus的metric就会产生 3 * 100 * 50 * 5 = 75,000 series 个时间序列。举个实际的例子比如标签有2个，一个instance，一个pod。

Instance 有 master，node1

Pod有pod1，pod2

那么就会有

• 时间序列 = metric + tag 组合

• 基数 = 所有存在的唯一时间序列数量

• 实际情况中：

• 一些组合确实没有实际 Pod 或数据 → 没值的 series 不创建

• 但如果写入了 0 或默认值 → 也会被创建，占用基数

• 所以理论组合数 是基数上限，实际基数可能更少，但仍可能很大

查询耗时

在上述配置情况下现在执行一些查询命令来直观的观测到查询耗时效果。

在根据云管平台api的查询逻辑现在给出在当前情况下的查询耗时

Memory的大约在1.6s

Cpu的大约在1s

此时的数据量为220w数据点，4.6w的基数。

针对memory的查询命令在终端执行查询耗时性能分析的命令后可以看到

耗时1.6s多，主要用在执行查询阶段，而具体的分析则在ReadWindowAggregateByTime27 命令上也就是代码中的。

这一步的作用是将时间序列按指定时间窗口聚合，保留每个窗口的最后一个点，减少数据量并平滑高频数据。

随着数据量的增加针对memory的查询在不调整查询语句的前提下查询耗时会降低到6s以上

总得来说目前遇到的查询效率的问题主要体现在2个方面，一个是集群的时间序列过多导致的基数较大，现在的基数在4.7w随着时间的推移由于没有对高基数标签进行任何处理在未来会导致严重的存储和查询效率问题。而基数大相应的也会导致数据量变大，这两个数据是相辅相成的基数越大每个时间间隔采集到的唯一性数据点也越多。所以接下来的操作方向主要是为了减少基数和减少数据量的角度上来进行优化。

优化方案

从未来实际的使用角度上来说，优化存储方案，分表去存储与查询数据是解决高基数时序数据库的最有效办法，通过管理task来实现基数的有效控制，同时当未来集群数量上去后也可以有效的降低原始数据全量扫描的风险，通过构建task在后台持续的运行和集成数据到目的业务表中。

数据采集

由于时序数据库不可避免的会产生高基数问题，可以通过手动的管理高基数tag将其转化为fied来降低单张表的存储基数高增长问题，同时优化telegraf抓取prometheus的接口，实现根据类型分表存储进而进一步的降低多个表的存储数据量和基数实现基数可控增长的目标。然而这样的方案意味着我们需要维护高增长的基数tag，需要梳理filed标签。同时优化telegraf的抓取逻辑与自行分类问题。

如将通过对业务的梳理，将必要的tag和标签作为保留的tag其他的过滤掉进而几把少最终数据的存储结果并且减少基数进而提升查询效率。修改helmchart逻辑方便一次性部署。

同时指定要吐的表名称，实现最终的分表存储

调整最大查询内存使用为16G防止后续数据量增加导致oomkill。

设置时间序列缓存数量为1000，可以让多次查询中命中相同时间序列时提升效率。

通过上述方案可以有效的降低单表中的基数，并且控制其在未来不会告诉增长，同时由于分类存储进而降低了单表的数据量也会有更好的查询性能与效率。

分表数据存储

通过用task构建一个低频读取的效率方案，将全量存储数据通过降频采样将其存储在一个新的冷表中，实现数据的冷热读取。如将热数据定义为一天内的全部数据，而超过一天的数据我们将它存储在一个冷表中，这里只做数据的保存而尽量减少读取操作，可以实现读写分离提升纳管集群的数量与效率。

目前来说所有的数据按照1m的采样间隔存储在全量表中，将其的保存时间可以设置为1天，认为是我们的数据热表，通过后台构建task的方式将全量数据降采样存储在新的表中构建为冷数据。如将采样间隔控制为1h那么数据量会瞬间减少60倍。

如可以通过时间划分，prometheus_hot数据时间范围1天，主要作用为实时查询，高频查询，可能有写入更新。

Prometheus_cold数据存储时间为一周到一个月，主要用于数据存储和冷读取。主要适用于低频读取，基本只读。InfluxDB 本身也在存储引擎层实现了类似机制（TSM文件 + WAL + Compaction），但在业务层做“冷热分离表”会更灵活。

不同的存储桶中可以设置不同的保存时间，同时不同的shard也可以有效的压缩数据。提升查询性能，加速写入与压缩，支持自动过期与删除。

通过构建低频降采样的task将数据存储在新库中。实现数据量的降低，加快查询效率与性能。然而代价是存储的数据精度降低，并且整体延时较高。

即使使用分表存储控制基数和数据量的情况下，由于优化了存储形式所以我们的api查询变为并发查询。经过测试和验证发现并发查询任然效率很差。

结论为：即使在cpu没有占用满的情况下我们的查询耗时已经增高，其原因在于minflt/s的数据较大。多并发查询引发了“缓存抖动”的问题，每个并发的查询需要频繁的从内存和缓存页中间进行切换，导致cpu等待数据处理过程最后导致耗时增加。其原因在于

1 并发查询导致influxdb底层执行查询数据的读取频繁切换。

2 目前数据抓取不稳定，导致数据存储的TSM文件分块不均匀。

查询耗时的增长在分表分集群的情况下，即使数据量一定，由于并发查询中influxdb也会将任务切分为groutine执行小步骤任务如：group聚合

所以这个方案由于我们前端是并发将多个查询同时请求后端，又由于使用groutine启动查询遍历集群的任务，而每个任务在influxdb也会并发的执行，导致不同数据需要进行频繁的分页缓存交换进而造成的查询耗时较大。

通过对比使用原生的influxdb本身的并发查询发现耗时几乎一致，因此同时的并发任务会导致groutine的资源争夺查询效率依旧不是很快。

为解决上述问题引入新的task机制并且进一步优化存储方案。

方案如下，使用task从原有的表中聚合目标业务指标到新的存储bucket和结构中。通过task将瞬时的并发查询平缓的融入到一段时间的查询中。这样减少了并发查询的资源争抢，有效提升了单任务的运行持续性。同时由于新的业务数据储存在了新的表结构中，导致业务查询执行的查询命令所需要扫描的数据和基数降低到了十分低的程度，查询效率很高。然而这个方案的代价在于，由于后台task需要持续运行因此他有时间间隔---导致查询到的数据有延迟，不是实时数据，第二个问题---由于后台task在持续运行导致会有常驻资源占用，在未来任务较多以及快速增长的背景下可能会出现影响接口查询性能与原有的task运行产生互相影响。

通过将查询语句转化为task并且提升动态获取measurement测量表的能力实现自动扩展。新的表结构中只保留业务数据并且很小而且可控。

最终查询耗时：经过处理前端大屏的查询耗时在60ms以内，后台的查询耗时在10ms以内。

云管api修改

涉及到两处。一处是我们需要适配优化后的flux查询语句。

需要修改更新，另外的是由于未来可能会有新的指标和tag或者filed的需求。整理一个可行的扩展方案。

以memory查询为例，

优化后的查询用go_test测试文件可以验证正确运行，与现有的存储结构匹配

Api的修改适配了新的存储方案，保存了原有的适配性，优化了输出标签。

扩展方案

同时未来也许有新的查询指标需求，现在给出一个未来的扩展方案

未来随着业务的需求和实际的使用，需要对采集到的数据有了新的要求时按照以下3个步骤来实现动态扩展。

1构建一个脚本用于 插入telegraf采集数据源

使用脚本的方式为每个telegraf注入新的配置，采集全量数据到一个临时bucket 【target_bucket】中，该bucket可以设置1d的保留时间只用于数据的采集不做保存。

由于未来的需求一定是具体切确定的，所以采集的数据不需要全量抓取，只抓去期望的指标数据采集量小。

2 后台构建task

通过构建task将target的数据持续集成到我们的之前业务层bucket，他的数据保留时间与原有的一致。实现了在不侵入原有数据内容的情况下，使用一个额外的临时bucket来注入数据到业务表中。由于临时bucket采集指标有限并且可以设置较短的保留时间以达到控制数据量的目的。

告警监控api研发

在实际使用的过程中我们需要频繁的对监控告警转发的规则进行修改编辑，比如qq转发，邮件转发。告警指标的构建等。因此开发一个功能完整的 Alertmanager API 服务器，用于管理 Kubernetes 环境中的监控告警配置。该服务器提供了简化的 RESTful API 来管理 PrometheusRules、AlertmanagerConfigs 和 ServiceMonitors 资源，并具备自动的 Secret 管理功能。

他的主要特点有

- **简化的 API 接口**：使用查询参数而非复杂的 JSON 请求体

- **自动 Secret 管理**：自动创建和管理敏感信息的 Kubernetes Secrets

- **完整的 CRUD 操作**：支持创建、读取、更新、删除所有资源类型

- **多渠道通知支持**：支持 Email、WeChat、Webhook 等多种通知方式

- **Kubernetes 原生**：直接操作 Kubernetes CRDs，与 Prometheus 生态系统完美集成

按照功能分为以下三类的操作对象，Prometheus Rules，Alertmanager Config，数据采集器（Collectors）

Api开发的swagger文档如上所示。

Prometheus规则

• Prometheus Rules 管理

• 说明：根据实现，创建/更新均使用以下查询参数：

• alert_name（必填）：规则名称与告警名称；同时作为 K8s 资源名

• expr（必填）：PromQL 表达式（注意 URL 编码）

labels（可选）：标签，格式 key=value,key2=value2
for（可选）：持续时间，如 5m

# 获取特定规则
curl -s http://localhost:8080/api/v1/prometheus/rules/cpu-high-test | jq

# 列出所有规则
curl -s http://localhost:8080/api/v1/prometheus/rules | jq

# 创建 CPU 使用率告警规则（名称：cpu-high-test）
curl -s -X POST "http://localhost:8080/api/v1/prometheus/rules?alert_name=cpu-high-test&expr=cpu_usage%3E80&for=5m&labels=severity=critical,team=backend" | jq

Crd资源中也有我们新建的规则。

Collectors管理

说明：创建/更新 Collector 使用查询参数（而非 JSON）。可通过 selector 指定 Service 选择器，endpoints 通过字段 port、path、interval、scheme 提供基础配置。

创建 ServiceMonitor

curl -s -X POST "http://localhost:8080/api/v1/collectors?name=sm-test&selector=app=nginx&port=metrics&path=%2Fmetrics&interval=30s&scheme=http" | jq

通过使用api可以方便快速的创建collector资源配置对应的servicemonitor。

Alertmanager配置

进行邮件，webhook，qq等配置都在alertmanager中进行，通过修改更新receiver实现将告警的规则转发给那个receiver。而receiver具体的配置了应该怎么去将消息转发出去。

创建 Email 配置

curl -s -X POST "http://localhost:8080/api/v1/alertmanager/email?name=email-config-test&to=admin%40example.com&from=alerts%40example.com&smarthost=smtp.example.com%3A587&username=user&passwd=pass123&key=alertname&val=EmailAlert" | jq

创建 Webhook 配置

通过上面的例子可以方便的创建出基于邮件的告警转发和基于webhook的配置。同时在使用过程中需要对prometheus规则有一定了解。具体的工作流程为，首先配置prometheus告警规则，当告警触发时，消息会进入到alertmanager，alertmanager根据自身的router和receiver配置，根据适当的标签将不同等级的警告路由到不同的接收器中，接收器具体执行发送什么内容的警告。

可观测性核心指标梳理

云平台可观测技术，底层涉及到的组件较多，包含cpu，gpu等资源的使用。以及自身云平台的运行状态，部署的服务信息等。本章节将通过在四个角度的场景来梳理出多个核心关键指标用于指示云平台的可观测性能力具备针对重要指标的梳理能力。

在面对复杂、动态的云原生架构时，构建一个能够深入理解系统内部运行状态的可观测性能力至关重要。本章节将围绕以下四个关键层面来梳理核心指标，以此展现云平台可观测技术对重要性能和健康指标的全面覆盖与深入分析能力：

• 容器级别指标

• 宿主机级别指标

• 服务指标（包括运行的具体服务、业务指标及整体 Service 状态）

• Kepler 功耗指标

这种多层次的指标梳理模式，底层逻辑在于构建一个端到端的全栈可观测性视图。在云平台环境中，故障的根源往往隐藏在依赖链的深处：宿主机的问题会影响容器的资源分配，进而导致上层业务服务的延迟和错误。通过将指标划分为这四个紧密关联的层级，我们能够将问题锁定在特定的技术边界内，实现快速的故障隔离和根因分析。

基础设施层（宿主机与容器）

宿主机级别指标和容器级别指标构成了整个可观测体系的基础数据层。在云平台中，宿主机（Node）承载着计算资源（CPU、GPU、内存）的物理分配和虚拟化能力，其指标（如磁盘 IO、网络饱和度、内核负载）决定了容器运行的健康环境。容器指标则更专注于工作负载的微观表现，如容器 CPU 使用率、内存限制、OOMKills（内存溢出）事件等。这两个层面的指标结合，完美体现了可观测性中的“指标（Metrics）”支柱：它们提供量化的、细粒度的资源使用情况，用以确认基础设施的可靠性和资源供应的充足性。这种分层检查机制，是快速排除基础设施故障和资源争用问题的关键。

应用与业务层（服务指标）

服务指标关注的是用户体验和业务价值交付层面，它将底层基础设施的健康状况，最终映射到用户可感知的性能上。这类指标包括请求延迟、错误率（如 4xx/5xx）、吞吐量以及具体业务的 Key Performance Indicators（KPIs）。在现代云平台中，服务指标往往通过**分布式追踪（Tracing）**来实现，将请求在多个微服务之间的调用路径串联起来，从而定位到具体的性能瓶颈所在。因此，服务指标体系是将可观测性从“系统是否正常运行”提升到“业务是否健康且高效运行”的关键桥梁，是衡量服务级别目标（SLOs）和保障业务连续性的核心手段。

战略与效率层（Kepler 功耗指标）

将 Kepler 功耗指标纳入可观测体系，是平台具备战略性可观测能力的体现，尤其对于大规模、资源密集的云平台而言。在绿色计算和成本控制成为企业核心关注点的今天，功耗指标不再是次要数据。通过采集并分析容器和宿主机层面的能效数据，我们能够：

• 优化资源配置：识别能效比最低的 Pod 或服务，指导资源调度策略。

• 支撑成本透明化：将功耗数据与业务指标关联，实现更精准的单位业务成本核算。

这种数据结合展示了平台已超越传统的故障诊断，开始迈向资源效率优化和可持续运维的高级阶段，使得可观测性数据直接服务于企业的财务和环保目标。

综上所述，通过在容器、宿主机、服务和功耗这四个层面全面梳理和采集关键指标，我们的云平台可观测性方案不仅完整覆盖了三大支柱（Metrics, Logging, Tracing），更在逻辑上构建了一个从物理资源到业务价值的完整、可追踪的视图，充分具备了在复杂环境中快速决策、深度诊断和持续优化的能力。

基础设施层

基础设施是可观测性体系的数据基础，它指向的更多是底层的硬件，以及最基础的容器等运行的状态，也包括集群的宿主机情况如cpu，memory，disk等核心关键指标。这些硬件资源限制与容器运行的指标发生重大变化时，对上层承载的云平台和业务服务都会产生深远的影响。

容器级别指标梳理

指标1：container_cpu_usage_seconds_total

介绍：该指标为容器 CPU 使用情况的计数器。 它累积记录了容器自启动以来消耗的 CPU 总时间（秒）。通过计算其变化率，可以得到容器在一段时间内的平均 CPU 使用量（单位：核/vCPU）。

查询结果：

指标2：container_memory_working_set_bytes

介绍：该指标为容器的工作集内存使用量（字节）。 它排除了可回收的 Page Cache，更准确地反映了应用程序实际占用的内存大小。

查询结果：

指标3：container_network_receive_bytes_total

介绍：该指标为容器在所有网络接口上接收到的总字节数的计数器。 通过计算变化率，可以得到容器的 网络接收吞吐量（字节/秒）

查询结果：

指标4：container_network_transmit_bytes_total

介绍：该指标为容器在所有网络接口上发送出去的总字节数的计数器。 通过计算变化率，可以得到容器的 网络发送吞吐量（字节/秒）。

查询结果：

指标5：container_network_receive_errors_total

介绍：该指标为容器接收数据时发生的网络错误总数的计数器。 变化率反映了网络不稳定或配置错误的程度。

查询结果：

指标6：container_fs_reads_total

介绍：该指标为容器对文件系统执行的读取操作总次数的计数器。 变化率反映了容器的 磁盘读取 IOPS (每秒 I/O 操作次数)。

查询结果：

指标7：container_fs_writes_bytes_total

介绍：该指标为容器向文件系统写入的总字节数的计数器。 变化率反映了容器的 磁盘写入吞吐量（字节/秒）。

查询结果：

宿主机级别指标梳理

宿主机指标主要由 Node Exporter 提供，标签 instance 通常指代宿主机的 IP 或名称。

指标8：node_cpu_seconds_total

介绍：该指标为宿主机 CPU 各模式（如 idle, user, system, iowait 等）下消耗的总时间的计数器。 通过计算 idle 模式的变化率，可以得到 CPU 的空闲率，进而计算出 CPU 使用率。

查询结果：

指标9：node_memory_MemTotal_bytes ----，，

介绍：该指标反映了宿主机的物理内存总量（字节）。 基础指标，用于计算内存使用率。

查询结果：

指标10：node_memory_MemAvailable_bytes

介绍：该指标反映了宿主机的物理可用内存总量（字节）。 基础指标，用于计算内存使用率。

查询结果：

指标11：node_disk_read_bytes_total

介绍：该指标为宿主机所有磁盘读取的总字节数的计数器。 变化率反映了 磁盘读取吞吐量（字节/秒）。

查询结果：

指标12：node_disk_written_bytes_total

介绍：该指标为宿主机所有磁盘写入的总字节数的计数器。 变化率反映了 磁盘读取吞吐量（字节/秒）。

查询结果：

指标13：node_network_receive_bytes_total

介绍：该指标为宿主机网络接口接收到的总字节数的计数器。 变化率反映了宿主机的 网络接收速率（字节/秒）。通常排除回环接口 lo

查询结果：

指标14：node_network_transmit_bytes_total

介绍： 该指标为宿主机网络接口发送传输的总字节数的计数器。 变化率反映了宿主机的 网络接收速率（字节/秒）。

查询结果：

指标15：node_filesystem_size_bytes

介绍：文件系统的总大小（字节）。通常作为分母，配合 node_filesystem_avail_bytes (可用空间) 来计算磁盘的使用率百分比。

查询结果：

指标16：node_filesystem_avail_bytes

介绍：文件系统的总大小（字节）。通常作为分母，配合 node_filesystem_avail_bytes (可用空间) 来计算磁盘的使用率百分比。

查询结果：

服务类指标梳理

服务指标主要关注运行在容器内部的应用程序的性能和健康状况。通常这些指标是通过应用程序本身（如 Golang、Java Spring Boot 等）或 Istio/Envoy Sidecar 暴露的，

指标17：prometheus_tsdb_head_samples_appended_total

介绍：该指标为 Prometheus 采集到的时间序列样本总数计数器。 变化率反映了 Prometheus 的 摄入速率（样本数/秒），是衡量监控规模的关键指标。

查询结果：

指标18：alertmanager_alerts_received_total

介绍：该指标为 Alertmanager 接收到的警报总数计数器。 变化率反映了 警报接收速率，高突发可能表明配置错误或系统故障。

查询结果：

指标19：kube_node_status_condition

介绍： 核心指标。通过标签 condition (如 Ready, MemoryPressure) 和 status (true/false) 来判断节点是否健康。

查询结果：

指标20：kube_service_info

介绍：通过对该指标计数，可以非常简单地统计特定命名空间或特定类型 Service 的总数。

指标21：kube_pod_status_phase

介绍：该指标由 kube-state-metrics 提供，反映 Pod 当前的生命周期状态。 phase="Running" 数量用于监控 Pod 的健康运行情况。

查询结果：

指标22：apiserver_request_total

介绍： K8s 控制平面的“黄金指标”。记录所有发往 API Server 的请求量。

查询结果：

指标23：etcd_request_duration_seconds_sum

介绍： 记录 etcd 接收和处理所有请求的总耗时（秒）。它是计算平均延迟 (Average Latency) 的分子

查询结果：

指标24：kube_pod_container_resource_requests

介绍： 记录容器在 Pod 规格中声明的资源请求值（Requests）。这个值是 K8s 调度器的核心依据，用于保障容器的最小资源供给。下面的计算是有被请求和保证的 CPU 资源中，有 84.6% 的部分目前处于空闲状态，未被任何工作负载使用。

查询结果：(sum(kube_pod_container_resource_requests{resource="cpu"}) - sum(rate(container_cpu_usage_seconds_total[1m])))
/ sum(kube_pod_container_resource_requests{resource="cpu"})

指标25：coredns_dns_request_duration_seconds_bucket

介绍： 它统计了在特定时间阈值（由 le 标签定义）内完成的 DNS 请求数量。它是计算 CoreDNS 解析的 P99 延迟 的基础，高延迟是导致 Pod 启动缓慢或服务通信超时的主要原因。

查询结果：

指标26：coredns_cache_hits_total

介绍： DNS 缓存命中次数, 记录 CoreDNS 直接从缓存中 快速返回答案的 DNS 查询总数。命中次数越高，表示缓存越有效，解析延迟越低。

查询结果：

指标27：coredns_cache_misses_total

介绍： DNS 缓存未命中次数, 记录 CoreDNS 必须向上游 DNS 服务器转发请求的总数。未命中会导致额外的网络延迟，降低服务性能。

查询结果：

指标28：workqueue_queue_duration_seconds_bucket

介绍： 控制器工作队列等待时间, 在控制器的工作队列中等待被处理所花费的时间。高队列延迟（Queue Duration）表明控制器处理不过来，处理速度低于事件生成速度，是监控 K8s 控制平面瓶颈 的核心指标。

查询结果：

个性化服务指标：ham，主要的自研服务的service指标

• ham_http_requests_total: 业务处理了多少请求（QPS）。

• ham_http_request_duration_seconds: 业务处理请求要多久（延迟）。

• ham_business_total: 业务逻辑层面的计数（比如“库存不足”、“验证失败”等业务错误）。

Ham_business_xxxx :ham的业务重要指标暴露。

功耗指标梳理

Kepler 指标将功耗数据与 Kubernetes 结构（Node, Pod, Container）关联起来，帮助您从能耗角度分析工作负载。Kepler 采集的功耗单位通常是 瓦特 (Watts, W) 或 焦耳 (Joules, J)。DRAM 是 Dynamic Random-Access Memory 的缩写，中文全称是 动态随机存取存储器DRAM 指的就是主存储器，即我们通常所说的“内存条”或“系统内存” (System Memory)。

指标29：kepler_container_joules_total

介绍：此指标是给定容器的 CPU、dram、gpus 和其他主机组件的聚合封装/插槽总功耗，容器级别的用于获取某个容器的所有能耗比如cpu，gpu，dram等。

查询结果：获取某个容器的能耗

指标30：kepler_container_core_joules_total

介绍： 只包含cpu运算核心也就是core的能耗。不包含其他的如缓存，dram功耗。

查询结果：

指标31：kepler_node_core_joules_total

介绍：节点级别cpu总能耗累计 (Joule)，可观察单个宿主机承载服务的能耗。

查询结果：

指标32：kepler_container_dram_joules_total

介绍：此指标描述容器在 DRAM 中花费的总能量。

查询结果：

指标33：kepler_node_dram_joules_total

介绍：此指标描述节点级别在 DRAM 中花费的总能量。

查询结果：

指标34：kepler_node_platform_joules_total

介绍：此指标描述节点级别的全部能耗，包括cpu，dram，空闲资源，系统进程，k8s服务。等是一个总的能耗。

查询结果

总结

上述内容通过梳理4个方面的指标从基础服务层下的容器级别到宿主机级别再到后来的服务类型指标以及最后的功耗类型指标。这些角度全方位并且递进式的关系从底层数据源到上层服务以及到多维度的容器功耗级别来展示云平台可观测性的多维度以及全系列的信息观测能力，但是由于我们是在vm的环境中部署的kepler，针对功耗的采集有一定的出入。并且在vm情况下kepler得到的数据是估算值，他通过少量的feature值来根据内置的数学模型进行预测。

以下是指标总结：

预留3-4个 gpu，fpga核心功耗。Exporter 以 Prometheus 友好的格式公开在 Kubernetes 集群中运行的应用程序的统计信息，该格式可以被任何理解此格式的数据库抓取，例如prometheus。可以以容器的形式，比如具体某个应用占用了xxgpu，xxfpga，得到功耗信息，单位为焦耳或者瓦特。

DCGM_FI_DEV_POWER_USAGE

可观测性总结与展望

本项目构建的统一可观测性平台，是在云原生架构日益复杂化的背景下，对企业级 IT 运维体系的一次深度重构与升级。我们通过标准化的集成方案，成功打破了传统监控中的数据孤岛，将指标（Metrics）、日志（Logging）、分布式追踪（Tracing）三大支柱深度融合，实现从被动告警向主动洞察的质变。平台不仅解决了当前系统“看不清、查不准”的痛点，更通过引入 AI 观测与绿色计算理念，为系统的长期演进奠定了坚实的数字化基石。

在具体的技术实施与功能落地层面，本项目在以下几个关键维度取得了突破性进展：

• 全链路数据集成与标准化：我们通过 Helm Chart 实现了可观测性组件的自动化部署与生命周期管理，构建了覆盖宿主机、容器、应用服务直至代码层面的全栈监控体系。通过对基础设施层（Node/Pod）、服务层以及功耗层（Kepler）指标的精细化梳理，我们建立了统一的指标数据词典，确保了监控数据的准确性与可读性。

• 存储性能优化与降本增效：针对海量监控数据带来的存储压力，我们对 InfluxDB 进行了深度定制与优化。通过构建降采样 Task、优化分表存储策略以及重构查询 API，我们在大幅降低存储成本的同时，显著提升了时序数据的查询效率，确立了高性能的数据底座。

• 前沿技术融合与业务赋能：面对大模型应用的兴起，项目极具前瞻性地集成了 Langfuse 组件，实现了对 AI 业务中 Prompt 管理、Token 消耗及响应延迟的精准观测，填补了 AI 基础设施监控的空白。同时，结合 Kepler 的功耗监控能力，我们首次将“能效”纳入可观测性范畴，为绿色计算与成本优化提供了数据支撑。

• 运维自动化与告警闭环：通过自主研发监控告警 API，我们将复杂的 Prometheus 规则配置与 Alertmanager 管理进行了服务化封装，实现了告警策略的动态下发与灵活管理，打通了从“发现问题”到“通知响应”的自动化闭环。

• 能耗指标梳理：通过对kepler组件梳理出的能耗指标，从一个能源使用情况的角度上来梳理和观测整个系统的运行状态。更在逻辑上构建了一个从物理资源到业务价值的完整、可追踪的视图，充分具备了在复杂环境中快速决策、深度诊断和持续优化的能力。

综上所述，本可观测性平台的建成，标志着我们的运维能力从“黑盒运维”正式迈向“全景透明”的新阶段。它不仅仅是一套技术工具的堆栈，更是保障业务连续性、提升用户体验、辅助技术决策的核心资产。未来，随着系统的持续运行与数据的不断沉淀，我们将继续利用该平台深入挖掘数据价值，在 AIOps（智能运维）、容量规划及成本治理等领域持续探索，以极致的可观测性驱动业务的高质量发展。