这次我们来看一个很有意思的工具ProbeDeck一款跑在 iPhone/iPad 上的 ClickHouse incident triage事件排查应用。从 Show HN 的项目定位看它的目标很直接把 ClickHouse 集群状态查看、SQL 查询、故障初步定位这些原本要在电脑上完成的操作搬到 iOS 设备上。核心卖点可以概括为三点。第一移动端直连 ClickHouse不依赖 SSH 和桌面客户端第二面向 incident triage也就是收到告警之后先快速判断“严重不严重、根因大概在哪、要不要马上处理”而不是做复杂的数据分析第三适合值班场景手机拿出来就能看集群状态。ProbeDeck 不是一个替代品它不替代 ClickHouse也不替代 Prometheus、Grafana 这类监控系统它更像是值班场景里的“第一响应工具”。这篇文章会围绕 ClickHouse 服务端准备、iOS 客户端接入、连接配置、常用排查 SQL、权限与安全边界、性能体验、常见问题排查几个方面展开。为了不误导大家凡是“从项目定位推断”的内容我会明确标注凡是需要以官方文档和实际版本为准的地方也会写清楚。适合阅读的读者ClickHouse 运维和开发人员、需要值班盯集群的 SRE、想做“数据库管控上移动端”产品方向的技术人以及想了解 iOS 端工具如何对接 ClickHouse 的开发者。1. ProbeDeck 是什么为什么需要移动端 ClickHouse 工具ClickHouse 是一个列式分析型数据库很多团队的日志平台、用户行为分析、监控数据存储都跑在它上面。正因为用得多它一出问题业务影响往往非常大。以前我们排查 ClickHouse 故障流程通常是收到告警 - 打开电脑 - SSH 到跳板机 - 执行clickhouse-client或者打开桌面的 DBeaver/Datagrip - 查system.processes- 查query_log- 定位问题。这一套流程在办公桌前没问题但如果人在通勤路上、在客户现场、或者半夜被电话叫起来体验就很差。ProbeDeck 要解决的就是这个场景。它的核心定位是 incident triage意思是“事件分级和初步排查”不是把一整套 ClickHouse 管理后台搬到手机上而是把故障发生后最先要做的几个动作简化成移动端操作。结合 ClickHouse 的生态特点这类工具通常会优先支持以下几类查询查看当前正在执行的查询、查看最近慢查询、查看表的健康状态和分区情况、查看复制表副本是否同步。移动端做这件事的好处在于响应速度。一个 SRE 收到告警后与其等电脑开机、等终端连上跳板机不如直接用手机跑一条SELECT version(), uptime()确认实例还活着再用一条SELECT ... FROM system.processes看看有没有正在拖慢集群的长查询。这个“先看一眼”的动作很多时候就能决定要不要立即拉人处理还是可以等到上班再说。不过也要说清楚移动端工具天然有局限。手机屏幕小长 SQL 和多列结果集的阅读体验远不如桌面端移动网络延迟不稳定复杂聚合查询大概率会超时。所以 ProbeDeck 这类应用更适合做“快速判断”不适合做“深度分析”。它和一整套桌面客户端是可以共存的工具不是替代关系。2. 核心能力速览从项目标题和现有材料看ProbeDeck 的核心能力可以整理成下表。需要提前说明因为当前公开材料有限部分能力需要以项目主页或 App 版本说明为准。能力项说明项目类型iOS 工具应用定位 ClickHouse incident triage主要功能移动端连接 ClickHouse、查看集群状态、执行查询、辅助故障分级运行平台iPhone / iPadiOS 系统服务端要求ClickHouse 服务端需要开放网络访问连接方式网络直连 ClickHouse通常基于 ClickHouse HTTP 接口或原生协议具体以 App 文档为准硬件要求不需要高配电脑或 GPU手机本身即可运行是否支持 API这是客户端工具重点是连接服务端App 本身是否对外暴露 API 需看项目文档是否支持批量任务目前没有材料明确说明从 incident triage 场景看更大概率是面向交互式查询主要适用场景值班、告警响应、快速 SQL 查询、集群状态查看开源状态标题为 Show HN 项目具体开源协议和仓库地址需要看项目主页这里特别强调一句所有表格里的推断项都不能当成官方参数。早期项目变动很快App 界面、按钮名称、支持的 ClickHouse 版本都有可能在你看到文章的时候已经更新。判断一个工具能不能用最靠谱的方式是跑通 demo。3. incident triage 场景拆解在手机上排查 ClickHouse 故障要理解 ProbeDeck 这类工具的价值得先拆解一下 ClickHouse 场景下 incident triage 到底包含哪些动作。我平时处理 ClickHouse 相关告警第一步是确认实例是否存活。如果uptime很短说明刚重启过那要看是不是 OOM 或异常崩溃如果uptime很长但查询很慢那问题大概率在查询本身或者资源争抢。第二步是查看当前正在执行的查询。system.processes表是 ClickHouse 排查故障时最先要看的地方它能告诉你当前有哪些 query 在跑、跑了多久、是哪个用户发起的、读了多少行。如果发现某条查询的elapsed已经很大还持续占用 CPU那它很可能就是拖慢整个集群的元凶。在 ClickHouse 里一条写得不合理的聚合查询可以把 CPU 打满影响所有业务。第三步是看慢查询历史。system.query_log记录了最近执行过的查询包括执行时间、扫描行数、返回结果大小。如果服务端配置了query_log落盘这里的数据很有参考价值。移动端查询这条表时通常会按query_duration_ms降序排列取前十几条快速判断是不是有规律性的慢查询。第四步是检查存储健康状态。system.parts可以看到每个 MergeTree 表的分区数量、行数、磁盘占用如果发现大量非 active 分区堆积通常说明后台 merge 能力跟不上需要看磁盘 IO 是不是瓶颈。第五步是看副本状态system.replicas表会告诉你每个复制表的 leader 状态、只读状态、活跃副本数。如果某个副本is_readonly 1说明该副本可能因为磁盘问题或 ZooKeeper 会话异常进入了只读模式这是需要立即处理的。ProbeDeck 这种移动端工具最理想的状态是把这五类查询做成可保存的模板用户点一下就能执行。因为故障现场每一分钟都很宝贵与其在手机上敲长 SQL不如提前把模板配好。虽然目前材料没有明确说 App 是否内置模板功能但从 incident triage 的产品定位看这一定是值得优先确认的能力。4. 适用场景与使用边界先说适合谁。第一类是 ClickHouse DBA 和 SRE。他们在值班的时候最需要快速确认集群当前有没有问题移动端工具恰好能补上“离开工位也能响应”的空档。第二类是后端和数据工程师。他们关心的是业务数据是否正常写入、分区表是否健康、某张查询很慢的表是不是要优化。第三类是团队技术负责人收到告警后先用手机看一眼关键指标再决定要不要开会拉群。ProbeDeck 能解决的问题本质上是“把故障初判的响应链路缩短”。以前可能要等电脑启动、等 SSH 连接、等客户端加载现在如果网络通、权限对几秒钟就能返回状态信息。这个价值在告警高峰期和移动办公场景下非常明显。接下来要明确边界。首先不要期待它在手机上完成复杂数据建模、大结果集导出和长时间运行的查询。分析型数据库一条全表聚合可能扫描几十亿行这种任务不该在手机端跑。其次ProbeDeck 不适合在没有网络隔离和传输加密的公网环境下直连生产 ClickHouse那是安全问题不是功能问题。另外如果 ClickHouse 集群本身就很不稳定App 的查询也会跟着失败这并不能说明 App 有问题需要先确认服务端状态。合规和授权方面也要重视。ClickHouse 数据库里往往存着业务核心数据包括用户信息、订单数据、访问日志等。手机上查询这些数据等于把一部分敏感信息的访问入口从固定终端扩展到了移动设备。使用前必须确认账号权限是否最小化、连接是否加密、是否有审计日志记录查询行为、手机丢失或越狱后有没有应对方案。这些边界在任何移动端数据库客户端上都适用ProbeDeck 也不例外。5. 环境准备ClickHouse 服务端配置在手机上连接 ClickHouse 之前服务端需要先做好三件事确认版本兼容、创建最小权限账号、开放网络访问。先看版本兼容。ClickHouse 本身迭代很快不同版本的system表字段、SQL 语法、HTTP 接口行为都有差异。ProbeDeck 必然会针对某个 ClickHouse 版本区间做适配所以接入前要先确认服务端版本是否在 App 支持范围内。这个信息要看项目主页或 App 内的兼容性说明不能拍脑袋。如果 App 支持旧版本协议但服务端已经升到很新的版本查询接口可能报语法错误或者字段缺失。然后是权限账号。强烈建议给移动端连接单独创建一个只读账号不要用默认的default账号更不要用拥有管理权限的高权限账号。给 ProbeDeck 使用的账号建议只授SELECT权限。下面是一个参考建号脚本-- 参考创建一个专用于移动端排查的只读账号 CREATE USER IF NOT EXISTS mobile_triage IDENTIFIED WITH sha256_password BY ChangeMe_StrongPassword; -- 允许读取 system 库用于排查进程、日志、分区和副本状态 GRANT SELECT ON system.* TO mobile_triage; -- 允许读取业务库按实际需要替换 GRANT SELECT ON default.* TO mobile_triage; -- 明确不授予任何写权限 REVOKE ALTER ON *.* FROM mobile_triage; REVOKE CREATE ON *.* FROM mobile_triage; REVOKE DROP ON *.* FROM mobile_triage; REVOKE INSERT ON *.* FROM mobile_triage;注意REVOKE在这里是“保险”性质。如果账号一创建就只授了SELECT默认就不会有写权限。但生产环境多一层显式约束能避免后续误操作扩大权限。网络访问是很多人踩坑的地方。ClickHouse HTTP 接口默认监听 8123 端口原生 TCP 协议监听 9000 端口。如果 ClickHouse 部署在云服务器安全组必须放行对应端口如果部署在内网要保证 iOS 设备能访问到内网地址。实际运维中建议直接用 HTTPS 反向代理把 ClickHouse 的 HTTP 接口暴露给 App或者在 ClickHouse 端启用 TLS不要让查询流量明文传输。连接信息准备好之后应该整理成一份清单方便在手机上填写服务器地址IP 或域名、端口、用户名、密码、默认数据库、是否启用 TLS。如果连接的是公网暴露的实例一定要确认 IP 白名单和访问控制策略。到这里服务端的准备就完成了。6. iOS 客户端接入与连接配置获取 ProbeDeck 的渠道需要看项目主页。如果提供 TestFlight 公测链接直接加入即可如果项目是开源的也可以通过 Xcode 自行构建。自行构建的流程一般是下载源码、打开.xcodeproj、配置开发者签名、选择目标设备、点击 Run。对于只想验证功能的用户TestFlight 或 App Store 版本显然更方便。打开 App 之后第一步通常是创建连接配置。整个字段和电脑端 DBeaver 设置 JDBC/HTTP 连接差不多核心是地址、端口、账号和协议。这里给一个通用配置示例配置名称生产 ClickHouse 只读 服务器地址clickhouse.example.com 端口8443 用户名mobile_triage 密码****** 默认数据库default 启用 TLS是这里端口 8443 是假设用了 HTTPS 反代或 ClickHouse 的 HTTPS 端口实际端口要按自己的服务配置来填。保存配置之后第一件事是测试连接。能够成功测试连接的标志是App 能拿到服务端的响应比如返回 ClickHouse 版本号。测试通过后再执行一条最简单的查询SELECT version(), uptime()如果这两步都通了说明监听端口、账号权限、TLS 配置、网络路由都没有问题。接下来就可以进入真实排查场景了。有一个排查经验可以分享如果 App 一直报连接失败优先把同一个地址、同一组账号放到电脑端的clickhouse-client或 DBeaver 里测试。如果电脑端能连上问题大概率在 iOS 端的网络出口、TLS 配置或防火墙如果电脑端也连不上那就先处理服务端App 本身没有问题。7. 核心功能测试移动端 incident triage 实战下面是一套可以在 ProbeDeck 里反复使用的排查流程。这些 SQL 本身不是 ProbeDeck 独有的在任何 ClickHouse 客户端都能跑但放到移动端场景下特别实用。第一步探活。确认实例版本和运行时间SELECT version(), uptime()期望结果是返回一行数据。如果uptime很小说明实例刚重启过需要结合系统日志判断重启原因。这一步通常能把问题范围缩小一半。第二步查看当前正在执行的查询。这是 incident triage 最常用的操作SELECT query_id, user, elapsed, query FROM system.processes ORDER BY elapsed DESC LIMIT 10如果某条查询的elapsed已经很大而且query里能看到扫描量很大的聚合基本可以判断集群变慢的原因是长时间运行的查询占用了资源。query_id是排查时的重要参数后续可以在system.query_log里继续追查。第三步查看最近的慢查询历史SELECT query_start_time, query_duration_ms, query, read_rows, read_bytes FROM system.query_log WHERE type QueryFinish ORDER BY query_duration_ms DESC LIMIT 20这条查询能告诉你在最近一段时间内哪些 SQL 最耗时间、扫描了多少数据。如果发现某张业务表的查询频繁出现在慢查询列表里说明优化方向应该聚焦在那张表的索引或分区裁剪上。第四步检查表分区健康状态。比如排查某张业务大表SELECT table, partition, rows, bytes_on_disk, is_active FROM system.parts WHERE table your_table ORDER BY partition如果非 active 分区的数量持续增长说明后台 merge 有积压可能和磁盘 IO 瓶颈或 CPU 资源不足有关。在移动端看到这个信号可以快速判断需要关注服务端合并任务。第五步检查副本同步状态SELECT database, table, is_leader, is_readonly, total_replicas, active_replicas FROM system.replicas如果active_replicas小于total_replicas说明副本集群健康度下降。如果is_readonly 1说明该副本很可能因为 ZooKeeper 会话问题或本地磁盘异常进入了只读模式需要介入处理。每一类查询执行完后都应该有一个明确的判断标准返回结果是否完整、是否在可接受的超时时间内、App 是否稳定没有崩溃。如果在手机上执行这些 SQL 时出现语法错误大概率是 ClickHouse 版本差异或者 App 对查询文本做了转义处理需要和服务端版本对照确认。8. 权限设计与数据安全边界移动端接入数据库第一原则永远是权限最小化。给 ProbeDeck 单独创建账号而不是复用管理员账号是所有安全实践的基础。上面提到的mobile_triage账号就是一套最小化参考实际生产环境中可以继续细化为“只读某个库的某几张表”甚至用 ClickHouse 视图来过滤敏感字段。生产环境建议这样限定账号可访问的表CREATE USER IF NOT EXISTS mobile_triage_ro IDENTIFIED WITH sha256_password BY AnotherStrongPassword; GRANT SELECT ON system.processes TO mobile_triage_ro; GRANT SELECT ON system.query_log TO mobile_triage_ro; GRANT SELECT ON system.parts TO mobile_triage_ro; GRANT SELECT ON system.replicas TO mobile_triage_ro; GRANT SELECT ON system.metrics TO mobile_triage_ro;如果运维人员只需要在手机上排查系统状态不查业务明细数据那么连业务库的SELECT都可以不给只给system库的只读权限就够了。这套配置能最大程度降低手机端账号被滥用或泄露后的影响范围。网络传输安全也不能放松。ClickHouse 默认 HTTP 接口是明文传输如果 App 直连这个端口账号密码和查询内容都会在网络里裸奔。合理的做法是把 ClickHouse HTTP 接口放在内网或者通过 HTTPS 反向代理暴露。具体到 ClickHouse 配置可以启用 TLS 端口并把 HTTP 明文端口只绑定在内网接口上。审计方面ClickHouse 的query_log本身就有记录功能它会把每次查询的用户、SQL、耗时都写下来。既然移动端工具连到了 ClickHouse那所有在手机上执行的 SQL 也会被记录下来。对安全要求高的团队应该定期检查query_log里user mobile_triage的查询记录确认没有异常的大范围数据读取。另外要提醒一点不要在 App 里开启“记住密码”功能后就完全放松手机本身的安全防护。配置锁屏密码、开启生物识别、保持 iOS 系统更新这些基础操作同样重要。移动端最大的风险不是 ClickHouse 服务端而是设备本身丢失或失控。9. 性能与使用体验优化移动端查询 ClickHouse 和桌面端有一个很大的不同网络状态不稳定用户耐心也有限。一条查询如果在手机端转圈很久体验会非常差。所以使用 ProbeDeck 这类工具时要有意识地控制查询复杂度。先看超时问题。ClickHouse 服务端本身可能有max_execution_time设置但 App 到服务端之间的网络链路也会有超时。移动网络下如果一条查询超过 30 秒还没返回客户端往往会主动断开。这种情况下与其在手机上优化复杂 SQL不如先在查询里加LIMIT或者用WHERE限定分区范围把返回的数据量降下来。再看结果集。手机屏幕能显示的行数有限一次性返回几千行结果没有意义。建议所有查询都加LIMIT比如SELECT * FROM system.query_log ORDER BY event_time DESC LIMIT 50从使用体验来说把一套固定排查 SQL 保存成模板是最值得做的优化。如果你是一名 SRE可以把“进程查看”“慢查询查看”“副本状态查看”这三条 SQL 存成模板收到告警后先跑模板再根据结果决定是否手动执行更多 SQL。这样可以最大限度减少在手机上敲 SQL 的次数。关于 iPadOS 适配从产品逻辑看iPad 的大屏和多任务能力更适合展示多列结果集体验会比 iPhone 更好。但具体支持程度包括是否支持分屏、是否优化了宽屏布局都需要以 App 实际版本为准。如果项目还在早期iPhone 能跑通已经足够验证价值。10. 常见问题与排查方法移动端连接 ClickHouse 的故障模式相对集中下面这张表梳理了最常遇到的一批问题。问题现象可能原因排查方式解决方案App 连接不上端口不通、地址填错、TLS 配置错误先用电脑端客户端测试同一地址和账号核对地址端口确认 TLS 开关连接成功但查询返回 401用户名密码错误或账号无权限使用 clickhouse-client 用同一账号登录重置密码补充授权查询一直转圈超时查询太慢、移动网络延迟高、App 超时设置过短在服务端用同样 SQL 测试耗时优化 SQL、加 LIMIT、降低扫描范围提示DB::Exception: ...ClickHouse 服务端返回错误App 只是在透传把完整报错拿回桌面端对照根据服务端错误信息处理查询system.query_log没数据账号没有 system 表权限或 query_log 未开启检查服务端查询日志配置授权SELECT ON system.*确认query_log开启能查 default 库但查不到其他库账号授权范围只覆盖 default检查 GRANT按需授权业务库但要控制权限返回结果出现乱码编码设置不一致检查 App 和服务端字符集设置统一使用 UTF-8App 闪退早期版本 bug、iOS 版本过低查看崩溃日志联系项目作者升级 App 或系统版本生产库查询速度慢实例负载高或查询命中大量数据查看system.processes定位长查询先处理慢查询再评估是否限制移动端查询并行度排错时有一个通用思路把所有“App 侧的问题”先转成“服务端可复现的问题”。如果同一条 SQL 在电脑端 1 秒返回在手机上却超时那要检查网络链路和 App 超时设置如果电脑端同样很慢那问题就在服务端查询性能和 App 无关。11. 最佳实践与使用建议把 ProbeDeck 接入工作流时有几条实打实的建议。第一先跑通最小验证。第一天只用只读账号、只跑SELECT version()和SELECT ... FROM system.processes两条查询。确认网络、权限、TLS 都正常之后再逐步扩展到system.query_log和system.parts。不要把高风险账号从一开始就配进 App。第二保存一套标准 triage 模板。手机上临时敲 SQL 效率太低可以在能保存查询模板的位置维护一组常用 SQL探活、看进程、看慢查询、看分区、看副本。这套 SQL 在任何 ClickHouse 客户端都通用不绑定某个 App。第三严格控制查询范围。所有移动端查询都加LIMIT能条件过滤就加过滤。不要指望在手机上跑全表聚合也不要在移动网络下扫描几十亿行数据。这不只是性能问题也是安全习惯。第四管理好账号和密码。移动端账号使用独立强密码定期轮换。如果团队规模大可以考虑为每个值班人员创建单独的只读账号便于审计追踪。把账号密码配置发放给多个人的时候要同步做好记录。第五记录使用反馈。很多 Show HN 项目还处于早期作者非常需要真实使用反馈。如果你真的把 ProbeDeck 用进了值班流程可以记录下你的 iOS 版本、ClickHouse 版本、连接方式、遇到的报错反馈给作者。这种信息对早期项目迭代价值很高。第六安全配置要形成清单。每次接入新环境逐项确认是否使用独立账号、是否只读、是否启用 TLS、是否限定 IP 来源、是否有审计日志。这套清单同时适用于 ProbeDeck 和其他移动端数据工具。12. 总结与下一步ProbeDeck 的价值不在功能数量而在“缩短故障初判链路”这件事上。它把 ClickHouse incident triage 场景搬到了 iOS 设备让 DBA 和 SRE 在没有电脑的情况下也能快速确认集群状态、查看慢查询、判断副本健康度。最值得尝试的是先在测试环境用一个只读账号跑通连接再把这套 triage SQL 模板跑一遍看看整个响应链路是否顺畅。最容易踩的坑集中在权限和网络用了高权限账号、明文连接生产库、公网直接暴露 ClickHouse。这些问题和 App 本身无关但如果不注意会把一个好工具变成一个安全入口。从当前材料看ProbeDeck 还处于早期阶段功能边界和兼容性都需要结合实际环境验证。下一步可以关注项目是否开源、是否支持 iPadOS 布局优化、是否支持通知联动和告警推送。如果你本身在用 ClickHouse又经常需要移动端响应建议把项目主页和安装方式收藏起来找时间跑通一次 demo。移动端数据库排查这个方向往后一定会越来越常见。