VPS上的AIOps：使用开源工具实现AI驱动的服务器管理

Datadog和New Relic按主机、按GB或两者结合收费。对于管理一到五台VPS的独立开发者或小团队来说，这些费用累积得很快，回报却有限。查看Datadog定价页面和New Relic定价页面了解当前费率。

替代方案：在一台VPS上运行整个监控、日志分析和事件响应技术栈。SigNoz、Grafana+Loki和Ollama等开源工具为你提供可观测性、AI驱动的异常检测和自动化修复。总成本就是VPS的价格。在Virtua Cloud上，基础可观测性的起步价为每月24欧元（2 vCPU、4 GB内存），完整技术栈为每月48欧元（4 vCPU、8 GB内存）。

本文描绘了自托管AIOps技术栈的五个层次。这不是一个分步教程。每个章节解释该层的功能、推荐工具，并链接到专门的深入指南，你可以在那里完成安装和配置。

什么是AIOps，为什么它对VPS运维人员很重要？

AIOps指的是使用AI和机器学习来自动化监控、日志分析、异常检测和事件响应。对于VPS运维人员来说，它取代了检查仪表板、读取日志和重启服务的手动循环。不需要为企业级SaaS平台付费，你可以在已有的基础设施上运行开源工具。数据留在你的服务器上，成本保持固定。

企业级AIOps的定义侧重于在数百个微服务中关联数千个告警，这不是本指南的内容。对于管理一到五台服务器的VPS运维人员，AIOps意味着：

• 在一个地方收集指标、日志和链路追踪，而不是SSH连接到每台服务器。
• 运行本地LLM来发现grep和正则表达式遗漏的日志模式。
• 自动响应常见故障，如磁盘满、进程崩溃或内存泄漏。
• 在代码进入生产环境之前获取AI反馈。

技术栈有五个层次。你不需要全部使用。从可观测性开始，当日志量让手动审查变得痛苦时添加AI分析，随着信心的增长逐步构建自愈能力。

自托管监控与Datadog相比成本如何？

Virtua Cloud VPS上的自托管AIOps技术栈每月花费24到96欧元，取决于你部署多少层。这是总成本：服务器、存储、带宽和所有软件。Datadog等商业替代方案使用按主机和按GB的定价模式，随基础设施扩展。当你增加主机、摄入更多日志或启用APM追踪时，成本会增长。

功能	商业SaaS（Datadog、New Relic）	自托管（Virtua Cloud VPS）
基础设施监控	按主机定价，分级收费	包含（Prometheus + Grafana）
日志管理	按GB摄入 + 按事件索引收费	包含（Loki或OpenObserve）
APM / 链路追踪	额外按主机收费	包含（SigNoz或Tempo）
AI日志分析	不可用或单独附加组件	包含（Ollama + 本地LLM）
告警	包含	包含（Alertmanager）
数据保留	供应商定义的限制（天到月）	你来决定。磁盘是唯一限制。
数据位置	美国/欧盟（可选区域）	你的VPS。你的管辖区。
定价模式	按主机+按GB，随使用量增长	固定月度VPS费用

如需了解当前商业定价，请查看Datadog定价和New Relic定价。自托管成本仅取决于你选择的VPS计划。

自托管列假设使用单个vCS-8计划（4 vCPU、8 GB内存、160 GB SSD），通过Docker Compose运行完整的可观测性技术栈。如果只需要基本的指标和日志，vCS-4（2 vCPU、4 GB内存）每月24欧元即可运行Grafana + Loki + Prometheus处理小型工作负载。

对于还想要AI分析层（Ollama配合3-7B参数模型）的团队，8 GB VPS是最低要求。Ollama运行Gemma 2（2B）大约占用2 GB内存，为SigNoz或Grafana留出了足够的空间。

哪些开源可观测性工具在VPS上表现最好？

可观测性层从你的应用和基础设施中收集指标、日志和链路追踪。三个开源技术栈主导这个领域：SigNoz、OpenObserve和Grafana + Loki。它们在功能、资源使用和复杂度之间做出不同的权衡。

工具	最适合	日志	指标	链路追踪	后端	最低内存	复杂度
SigNoz	完整替代Datadog APM	是	是	是	ClickHouse	4 GB	中等
OpenObserve	轻量级日志聚合	是	是	是	内置（Rust）	约1 GB	低
Grafana + Loki + Prometheus	成熟生态系统，可扩展性	是（Loki）	是（Prometheus）	通过Tempo	多种	2-4 GB	较高

三者都支持OpenTelemetry进行应用插桩。这意味着你可以一次插桩应用，之后更换后端而无需修改应用代码。

何时应该选择SigNoz而不是OpenObserve？

当你需要完整的应用性能监控时选择SigNoz：分布式链路追踪、服务拓扑图、错误跟踪和关联日志。SigNoz使用ClickHouse作为存储引擎，能很好地处理高基数数据，但需要更多内存。Docker Compose部署至少需要4 GB内存专门用于SigNoz，生产负载（包含ClickHouse）建议8 GB。

当你的主要需求是日志聚合和搜索时选择OpenObserve。OpenObserve是一个用Rust编写的单一二进制文件。在基本Docker Compose配置中启动时占用不到1 GB内存。它声称借助列式压缩，存储成本比Elasticsearch低140倍。如果你是一个运行单个应用的独立开发者，想要快速的日志搜索而不需要ClickHouse的开销，OpenObserve是更轻量的选择。

两种工具都有用于查询和仪表板的Web界面。SigNoz提供更完整的类似Datadog的体验。OpenObserve更轻量，部署更快。

Grafana + Loki在2026年还是最佳选择吗？

Grafana + Loki仍然是最灵活的选择。它不是最简单的设置方案，但在生态系统广度上胜出。几乎所有你能想到的服务都有社区仪表板。Prometheus导出器覆盖数据库、Web服务器、硬件指标和自定义应用指标。Loki使用与PromQL类似的LogQL查询语言处理日志聚合。

权衡：组件更多。最小化的Grafana技术栈意味着分别运行Grafana（界面）、Prometheus（指标）和Loki（日志）作为独立容器，再加上Promtail或Alloy作为日志收集器。这就是四个容器，还没算你自己的应用。在4 GB的VPS上，这个技术栈能装下但余量有限。

当你已经熟悉这个生态系统、需要深度自定义或想集成只支持Prometheus指标导出的工具时，选择Grafana + Loki。

如何为监控技术栈添加AI日志分析？

通过Ollama运行本地LLM来分析日志，无需向任何外部API发送数据。Ollama通过本地HTTP API提供Gemma 2（2B）、Llama 3.2（3B）或Qwen 2.5（7B）等模型。脚本或cron任务将日志片段送入模型，要求它识别异常、总结错误模式或建议根本原因。没有API费用，数据不会离开你的服务器。

这是自托管AIOps与传统监控的分歧点。Grafana和Prometheus告诉你发生了什么。本地LLM帮助你理解为什么。

AI分析层的功能：

• **异常检测：**将最近1000行日志发送给模型，提示词类似"识别这些日志中的异常模式或错误"。模型标记偏离正常模式的条目。
• **错误摘要：**当一个事件产生数百行日志时，LLM将其压缩为可读的摘要，附带可能的根本原因。
• **模式识别：**随着时间推移，重复的错误模式会浮现。LLM可以将相关错误分组，识别不会触发基于阈值告警的反复出现的问题。

VPS模型选型：

模型	参数量	内存占用	速度（tokens/秒，CPU）	最适合
Gemma 2（2B）	26亿	约2 GB	约15-20	低内存VPS上的快速日志分诊
Llama 3.2（3B）	32亿	约2.5 GB	约10-15	分析与速度的平衡
Qwen 2.5（7B）	70亿	约5 GB	约5-8	深度分析，需要8 GB+的VPS

在没有GPU的4 vCPU VPS上，推理仅使用CPU。2-3B模型每次查询在5-15秒内产生有用的日志分析。这对于每隔几分钟的批量分析足够快，但不适合实时流处理。

**这不是魔法。**小模型会产生幻觉，会遗漏上下文，有时会把正常的日志条目标记为可疑。将LLM日志分析视为分诊助手，而不是万能的预言机。始终将其建议与实际日志和指标进行对照验证。

什么是自愈VPS，它是如何工作的？

自愈VPS自动检测和修复常见故障，无需人工干预。基本架构：Prometheus监控指标，Alertmanager在超过阈值时触发告警，webhook接收器执行修复脚本。在这个循环中加入LLM可以处理不匹配预定义规则的故障。

自愈流水线：

1. Prometheus每15秒采集指标（CPU、内存、磁盘、进程状态、HTTP错误率）。
2. 告警规则定义条件：磁盘使用率超过90%、服务60秒无响应、内存使用率持续超过95%。
3. Alertmanager接收告警并路由到webhook端点。
4. 修复处理器接收webhook。对于已知情况（磁盘满、服务崩溃），执行预定义脚本。对于未知情况，通过Ollama调用本地LLM，传入告警上下文和最近日志，请求诊断和修复建议。
5. 执行（可选）：对于高置信度的已知修复（重启服务、清理临时文件、轮转日志），处理器自动执行。对于LLM建议的操作，将建议发送到通知渠道等待人工批准。

常见自动修复：

• **磁盘满：**清理/tmp，轮转旧日志，用docker system prune清理Docker镜像。
• 服务崩溃：systemctl restart <service>，然后验证健康状态。如果5分钟内再次崩溃，升级给人工处理。
• **内存压力：**识别最大的内存消耗者，如果超出预期基线则重启。
• **证书过期：**当证书剩余不到7天时触发Certbot续签。

保守起步。只自动化你已经手动执行过几十次并完全理解的修复操作。让LLM为陌生情况建议操作，但在执行环节保持人工参与。

对于告警路由和修复工作流的无代码方案，n8n可以作为Alertmanager和修复脚本之间的编排层。

AI如何融入你的CI/CD流水线？

AI代码审查在代码到达服务器之前捕获bug、安全问题和性能问题。GitHub Actions工作流可以将pull request的diff发送给Claude或Gemini进行分析，发布审查评论，并在发现严重问题时阻止合并。这在你的CI/CD流水线中运行，无需对VPS做任何改动。

AI代码审查能发现而linter不能的问题：

• 静态分析无法检测的逻辑错误和边界情况。
• 上下文中的安全漏洞（linter会标记eval()，但LLM理解为什么周围的代码使其危险）。
• 性能退化："循环中的这个查询将命中数据库N次。"
• 文档缺口：缺少错误处理、不清晰的变量名、未记录的副作用。

这一层与其他层不同，因为它通常在CI平台（GitHub Actions、GitLab CI）中运行，而不是在你的VPS上。不过，如果你想让一切都自托管，可以在VPS上运行CI runner并将代码审查请求路由到本地Ollama实例。权衡：使用较小模型审查更慢，而使用云API审查更快更准确。

什么是LLM可观测性，为什么你需要它？

LLM可观测性追踪你的AI工具的表现：token使用量、延迟、错误率、成本和输出质量。如果你运行任何LLM驱动的功能（聊天机器人、代码助手、日志分析器、内容生成器），Langfuse让你了解每次调用的详情。它是你AIOps技术栈中"监控监控工具"的层。

Langfuse是一个开源LLM工程平台。自托管运行时使用两个容器（web + worker），配合PostgreSQL，可选ClickHouse用于分析。它提供：

• **链路追踪：**查看每次LLM调用的输入、输出、延迟和token数量。深入多步骤agent工作流，找出时间和token的消耗点。
• **评估：**使用LLM-as-a-judge、人工反馈或自定义指标对输出评分。追踪质量随时间的变化。
• **成本追踪：**计算每次LLM调用、每个用户、每个功能的实际支出。在不同价格点比较模型性能。
• **提示词管理：**版本管理和A/B测试提示词。当新提示词降低输出质量时回滚。

如果你运行Ollama进行日志分析（本技术栈的第2层），Langfuse会追踪每个分析请求。你可以看到哪些日志查询产生了有用的结果，哪些让模型表现不佳，以及切换模型时延迟如何变化。

Langfuse与OpenTelemetry、LangChain、LlamaIndex和OpenAI SDK（Ollama与其兼容）集成。插桩通常只需要几行代码。

当你的LLM使用超越实验阶段时就需要这一层。一旦你依赖AI输出进行告警或修复，你就需要知道模型何时开始产生垃圾结果。

完整AIOps技术栈需要什么VPS资源？

资源取决于你部署哪些层。以下是三种配置，对应Virtua Cloud VPS计划：

配置	层	VPS计划	CPU	内存	磁盘	欧元/月
入门	Grafana + Prometheus + Loki	vCS-4	2 vCPU	4 GB	80 GB	24
标准	SigNoz + Ollama（3B模型）	vCS-8	4 vCPU	8 GB	160 GB	48
完整技术栈	SigNoz + Ollama（7B）+ Langfuse + Alertmanager	vCS-16	8 vCPU	16 GB	320 GB	96

入门版处理一到三个小应用的指标和日志聚合。仪表板和告警，无需AI分析。

标准版增加了AI日志分析。SigNoz占用约4 GB，Ollama配合3B模型使用约2.5 GB。剩余内存留给操作系统和被监控的应用。这是独立开发者或小团队的最佳选择。

完整技术栈运行本指南描述的所有层。70亿参数模型比3B模型产生更好的分析，但需要更多内存。Langfuse增加约1 GB。这种配置适合在生产环境运行LLM功能、需要对基础设施和AI进行全面可观测性的团队。

所有配置都通过Docker Compose运行。配套文章涵盖了每个工具的完整docker-compose.yml文件。

**关于磁盘使用的说明：**可观测性数据增长很快。SigNoz配合ClickHouse压缩效果好（日志预计有5-10倍压缩率），但要规划每天1-5 GB的新数据，具体取决于日志的详细程度。从第一天起就设置保留策略。160 GB磁盘在中等摄入速率下大约可以存储一到三个月的数据。

数据主权：自托管监控的GDPR优势

当你在欧洲VPS上运行监控技术栈时，你的可观测性数据永远不会离开所在管辖区。指标、日志和链路追踪通常包含个人数据：IP地址、用户ID、请求路径、包含用户上下文的错误消息。将这些数据发送到美国的SaaS平台会引入GDPR数据传输风险，即使提供商提供了欧盟区域。

在法国或德国的Virtua Cloud VPS上使用自托管技术栈，你可以控制：

• **数据存储在哪里。**在磁盘上，在你的VPS中，在欧洲数据中心。
• **谁可以访问。**没有供应商员工，没有次级处理者，没有需要审计的第三方数据协议。
• **保留多长时间。**你设置保留策略。没有供应商强制的最低期限或数据删除计划。

这不是法律意见。请咨询你的数据保护官了解你的具体情况。但从技术角度看，自托管监控消除了整个类别的数据传输问题。

应该从哪里开始？

你的起点取决于你的经验和当前正在解决的问题。

如果你刚接触服务器监控（独立开发者，第一台VPS）：

1. 从SigNoz开始。它在一个工具中提供指标、日志和链路追踪，附带Web界面。一个Docker Compose文件，一个需要学习的工具。
2. 当你能熟练阅读仪表板后，添加Ollama进行AI日志分析。
3. 暂时不要自动化修复。先了解你服务器的正常行为。

如果你已经在使用Prometheus或Grafana（DevOps从业者）：

1. 如果还没有的话，添加Loki进行日志聚合。
2. 将Ollama集成到现有告警规则旁边，进行AI辅助日志分诊。
3. 使用Alertmanager webhook构建自愈工作流。
4. 当你开始依赖LLM输出做运营决策时添加Langfuse。

如果你想从第一天就部署完整技术栈（AI开发者）：

1. 在Virtua Cloud上部署vCS-8或vCS-16 VPS。
2. 设置SigNoz实现可观测性。
3. 运行Ollama配合7B模型进行日志分析和异常检测。
4. 将Alertmanager连接到你的修复脚本。
5. 部署Langfuse监控你的LLM层。
6. 在CI/CD流水线中添加AI代码审查。

本主题集群中的每篇配套文章都是独立的教程。你可以按任意顺序阅读。技术栈是模块化的：每一层独立运作，都能独立提供价值。

---

版权所有 2026 Virtua.Cloud。保留所有权利。 本内容为 Virtua.Cloud 团队原创作品。 未经书面许可，禁止复制、转载或再分发。