Logtide：发布后两个月（真实数据）

I’m happy to translate the article for you, but I’ll need the full text of the post (the paragraphs, headings, lists, etc.) in order to do the translation. Could you please paste the article’s content here? I’ll keep the source line and all formatting exactly as you requested.

两个月前，我推出了 Logtide（当时叫 LogWard）——一个开源、隐私优先的 Datadog 和 Splunk 替代方案。

📊 数据（完全诚实）

GitHub

使用情况

✅ 实际有效的做法

1. 正确的营销渠道

Winner: virtualizationhowto.com – 一位科技博主发现了 Logtide 并撰写了相关文章。

• Result
  • 120+ GitHub stars from that single post → 单篇文章获得 120+ 个 GitHub 星标
  • Traffic spike: 2,500 visitors in 24 h → 流量激增：24 小时内 2,500 名访客
  • 80+ new self‑hosted deployments → 80+ 个新的自托管部署

Lesson: One good write‑up from a respected voice > 10 posts on social media. → 经验教训：一次来自受尊敬声音的优秀稿件 > 10 篇社交媒体帖子。

Runner‑up: Reddit + Dev.to – posts on r/selfhosted and Dev.to brought consistent traffic. → 亚军：Reddit + Dev.to – 在 r/selfhosted 和 Dev.to 的帖子带来了持续流量。

• Why it worked
  • Self‑hosters care about privacy (GDPR angle) → 自托管者关注隐私（GDPR 角度）
  • Docker‑Compose deployment (5 min from clone to running) → Docker‑Compose 部署（从克隆到运行仅需 5 分钟）
  • “No vendor lock‑in” message resonated → “无供应商锁定”信息引起共鸣

2. 人们实际使用的功能

Surprise: SIEM usage is way higher than expected. → 惊讶：SIEM 的使用率远高于预期。

Why? Users want to detect threats, not just see logs. → 原因：用户想要 检测 威胁，而不仅仅是 查看 日志。

Most popular Sigma rules aren’t even security‑focused: → 最受欢迎的 Sigma 规则甚至并非安全导向：

• “Payment failed” alerts → “支付失败”警报
• “API 500 error” spikes → “API 500 错误”峰值
• “Database timeout” patterns → “数据库超时”模式

Lesson: Security features sell, but business monitoring is what people actually use. → 经验教训：安全功能能促销，但业务监控才是人们实际使用的。

3. 带来收益的技术决策

TimescaleDB was the right choice. → TimescaleDB 是正确的选择。

Largest deployment stats → 最大部署统计

• 500 k logs/day → 每日 500 k 条日志
• 30‑day retention → 30 天保留
• DB size: 15 GB (compressed) → 数据库大小：15 GB（压缩后）
• Query performance: sub‑100 ms → 查询性能：小于 100 ms

Lesson: “Good enough” performance + operational simplicity > maximum speed. → 经验教训：“足够好”的性能 + 运维简易性 > 极致速度。

4. 有意义的社区需求

Issue #68 – Substring Search → Issue #68 – 子串搜索

• Request: “I can’t find bluez in spa.bluez5.native using full‑text search.” → 请求：“使用全文搜索找不到 bluez 在 spa.bluez5.native 中。”
• Initial thought: “Full‑text search is fine, use wildcards.” → 最初想法：“全文搜索没问题，使用通配符即可。”
• Reality: 40 % of searches now use substring mode. → 实际情况：现在 40 % 的搜索使用 子串 模式。

Why?

• UUIDs in logs (partial search) → 日志中的 UUID（部分搜索）
• File paths (e.g., /app/services/auth) → 文件路径（例如 /app/services/auth）
• Service names with dots → 带点的服务名称

Lesson: Users know their workflows better than you do. Listen to GitHub issues. → 经验教训：用户比你更了解自己的工作流。倾听 GitHub issue。

❌ 什么没有奏效

1. 品牌重塑（被迫，而非自选）

影响

• 丢失所有 SEO 动能（Google 已收录 “LogWard”）
• 旧链接/书签失效
• 早期用户困惑（“等等，Logtide 是什么？”）

成本： 大约 40 小时 用于重命名文档、SDK、Docker 镜像等。

经验教训： 在命名前务必先检查商标。 就这么简单。

小确幸： “Logtide” 听起来比 “LogWard” 更酷。

2. 没人要的功能

OpenTelemetry 指标（尚未实现）

• 计划： 支持 OTLP 指标（CPU、内存、…）
• 现实： 只有 2 位用户提出需求。

为什么？ 大多数用户已经在使用 Prometheus 进行指标采集。

决定： 无限期推迟。专注日志 + 追踪。

经验教训： 构建用户 请求 的功能，而不是你认为他们需要的功能。

3. 架构上的遗憾

Redis 可能是多余的。

• 当前技术栈

  • PostgreSQL + TimescaleDB（日志存储）
  • Redis（使用 BullMQ 的后台任务队列）

• 问题： 对自托管用户来说，Redis 增加了运维复杂度。

• 正在探索的替代方案

  • 使用 PostgreSQL SKIP LOCKED 实现任务队列（已在 “I Replaced Redis with PostgreSQL” 文章中验证）

• 下个版本（0.5.0）： 可能会彻底移除 Redis。

经验教训： 每一个依赖都是潜在的负担。对所有东西都要保持质疑。

😮 意外收获

1. 自托管占主导

• 预期： 50/50 云端 vs. 自托管
• 实际： 90 % 自托管

原因？

• 隐私顾虑（GDPR）
• 数据驻留要求
• 对基础设施的控制权
• 对 SaaS 日志平台的不信任

对路线图的影响

• 优先改进 Docker‑Compose，而非云功能
• 提升自托管文档质量
• 添加 Kubernetes Helm Chart

经验教训： 了解真实的用户，而不是想象中的用户。

2. Sigma 规则是差异化因素

• 预期： “可有可无的安全特性”
• 实际： “选择 Logtide 的主要原因”

用户反馈

• “终于可以在不花 Splunk 费用的情况下进行安全检测。”
• “Sigma 规则开箱即用。”
• “MITRE ATT&CK 映射太棒了。”

最受需求

• 更多预构建的 Sigma 规则
• SigmaHQ 集成（自动导入规则）
• 自定义规则编辑器 UI

经验教训： 找到你的独特切入点。对 Logtide 来说，它是 **