EMQX 监控指标完整指南一、概述1. 简介A. 是什么EMQX 监控指标是一套用于监控 EMQX 消息服务器运行状态的数据采集系统。通过调用 EMQX Dashboard API，可以获取节点状态、客户端连接、消息流量、订阅关系等关键指标，并以 Prometheus 格式输出，便于接入监控平台如 Grafana、Prometheus 等。B. 为什么需要EMQX 作为物联网消息中间件，承载着设备连接和数据转发的重要任务。通过监控指标可以：实时掌握集群健康状态及时发现性能瓶颈快速定位故障原因评估系统容量规划C. 学完能做什么部署 EMQX 监控采集脚本理解各项监控指标的含义配置 Grafana 监控面板建立告警规则保障系统稳定2. 前置知识A. 必备技能基本 Linux 命令操作了解 MQTT 协议基础概念熟悉 Prometheus 监控体系B. 推荐知识Categraf 采集器使用Grafana 面板配置Shell 脚本基础二、环境准备1. 系统要求EMQX 5.x 版本Linux 操作系统（Ubuntu、CentOS 等）具备访问 EMQX Dashboard API 的权限已安装 Categraf 或其他 Prometheus 兼容的采集器2. 组件说明监控脚本通过调用 EMQX RESTful API 获取数据，主要涉及以下端点：/api/v5/nodes：获取节点基础信息/api/v5/metrics：获取详细指标数据/api/v5/clients：获取客户端统计/api/v5/subscriptions：获取订阅统计/api/v5/topics：获取 Topic 统计3. 认证配置EMQX API 使用 HTTP Basic Authentication，需要提供 API Key 和 Secret：export EMQX_API_KEY="your_api_key" export EMQX_API_SECRET="your_api_secret" export EMQX_API_URL="http://emqx-server:18083/api/v5/nodes"三、监控架构1. 数据采集流程graph LR A[Categraf] -->|定时执行| B[监控脚本] B -->|HTTP请求| C[EMQX API] C -->|JSON响应| B B -->|Prometheus格式| D[采集器] D -->|推送| E[后端存储]2. 指标分类体系EMQX 监控指标按功能划分为 8 大类：mindmap root((EMQX监控指标)) 节点基础 连接数 内存使用 系统负载 进程状态 客户端 连接统计 认证状态 授权记录 消息 收发统计 QoS分布 丢弃率 数据包 包类型统计 传输状态 会话 创建终止 状态管理 订阅 订阅数量 创建统计 Topic 活跃数量 分布统计 字节 流量统计 带宽使用四、指标详解1. 节点基础指标节点基础指标反映 EMQX 集群中每个节点的运行状态，是监控系统最核心的部分。A. 连接类指标指标名称指标类型说明emqx_connectionsgauge当前连接数，反映当前客户端连接总数emqx_live_connectionsgauge活跃连接数，排除空闲连接emqx_cluster_sessionsgauge集群会话总数，跨节点的会话汇总B. 系统资源指标指标名称指标类型说明emqx_load1gauge系统 1 分钟平均负载emqx_load5gauge系统 5 分钟平均负载emqx_load15gauge系统 15 分钟平均负载emqx_memory_usedgauge已使用内存（字节）emqx_memory_totalgauge总内存（字节）emqx_process_usedgaugeErlang 进程已使用数emqx_process_availablegaugeErlang 进程可用数C. 运行状态指标指标名称指标类型说明emqx_uptimegauge节点运行时长（秒）emqx_max_fdsgauge最大文件描述符数emqx_node_statusgauge节点状态，1 表示运行，0 表示停止2. 客户端指标客户端指标用于监控连接到 EMQX 的设备状态和认证情况。A. 连接统计指标名称指标类型说明emqx_clients_countgauge当前连接的客户端总数emqx_clients_connected_totalcounter累计连接的客户端数，自节点启动以来emqx_clients_disconnected_totalcounter累计断开的客户端数B. 认证授权指标名称指标类型说明emqx_clients_authenticate_totalcounter认证请求总数emqx_clients_auth_success_totalcounter认证成功总数emqx_clients_auth_failure_totalcounter认证失败总数，可用于安全审计3. 订阅指标订阅指标反映客户端对 Topic 的订阅情况。指标名称指标类型说明emqx_subscriptions_countgauge当前订阅总数emqx_subscriptions_created_totalcounter累计创建订阅数4. Topic 指标Topic 指标用于监控消息主题的使用情况。指标名称指标类型说明emqx_topics_countgauge当前活跃 Topic 总数5. 消息指标消息指标是监控 EMQX 消息流转的核心指标，反映系统的消息处理能力。A. 消息总体统计指标名称指标类型说明emqx_messages_received_totalcounter接收消息总数emqx_messages_sent_totalcounter发送消息总数emqx_messages_publish_totalcounter发布消息总数emqx_messages_acked_totalcounter已确认消息总数emqx_messages_delivered_totalcounter已投递消息总数B. 消息丢弃统计指标名称指标类型说明emqx_messages_dropped_totalcounter丢弃消息总数，需重点关注emqx_messages_dropped_no_subscribers_totalcounter因无订阅者而丢弃的消息数C. QoS 级别消息统计指标名称指标类型说明emqx_messages_qos0_received_totalcounter接收的 QoS0 消息数，最多一次emqx_messages_qos0_sent_totalcounter发送的 QoS0 消息数emqx_messages_qos1_received_totalcounter接收的 QoS1 消息数，至少一次emqx_messages_qos1_sent_totalcounter发送的 QoS1 消息数D. 消息转发指标名称指标类型说明emqx_messages_forward_totalcounter转发消息总数，集群场景下重要6. 数据包指标数据包指标反映 MQTT 协议层的传输情况。指标名称指标类型说明emqx_packets_received_totalcounter接收数据包总数emqx_packets_sent_totalcounter发送数据包总数emqx_packets_publish_received_totalcounter接收的 PUBLISH 包数emqx_packets_publish_sent_totalcounter发送的 PUBLISH 包数7. 会话指标会话指标反映 MQTT 会话的生命周期管理。指标名称指标类型说明emqx_sessions_created_totalcounter创建会话总数emqx_sessions_terminated_totalcounter终止会话总数8. 字节传输指标字节指标反映网络带宽使用情况。指标名称指标类型说明emqx_bytes_received_totalcounter接收字节总数emqx_bytes_sent_totalcounter发送字节总数五、快速部署1. 部署监控脚本A. 创建脚本目录mkdir -p /opt/categraf/conf/input.exec cd /opt/categraf/conf/input.execB. 编写监控脚本将 emqx_monitor.sh 脚本放置到指定目录，并赋予执行权限：chmod +x /opt/categraf/conf/input.exec/emqx_monitor.shC. 配置环境变量编辑配置文件 /opt/categraf/conf/input.exec/emqx_monitor.conf：export EMQX_API_KEY="your_api_key" export EMQX_API_SECRET="your_api_secret" export EMQX_API_URL="http://10.10.74.101:18083/api/v5/nodes" export EMQX_MIDD_PROJECT="new-iot" export EMQX_MIDD_TYPE="emqx"2. 配置 Categraf编辑 Categraf 配置文件 /opt/categraf/conf/input.exec/exec.toml：instances commands = [ "/opt/categraf/conf/input.exec/emqx_monitor.sh" ] data_format = "prometheus" prometheus_ignore_timestamp = true3. 测试验证A. 手动执行脚本/opt/categraf/conf/input.exec/emqx_monitor.sh预期输出：Prometheus 格式的指标数据B. Categraf 测试/opt/categraf/categraf -inputs exec -test -debug预期输出：解析后的指标数据六、告警规则建议1. 核心告警指标告警名称指标触发条件严重级别节点宕机emqx_node_status值为 0严重连接数过高emqx_connections超过阈值警告消息丢弃率emqx_messages_dropped_total增长率异常警告认证失败emqx_clients_auth_failure_total短时间大量失败严重内存使用率emqx_memory_used超过 80%警告2. 告警规则示例groups: - name: emqx_alerts rules: - alert: EMQXNodeDown expr: emqx_node_status == 0 for: 1m labels: severity: critical annotations: summary: "EMQX 节点宕机" - alert: EMQXHighConnectionCount expr: emqx_connections > 10000 for: 5m labels: severity: warning annotations: summary: "连接数超过阈值"七、常见问题1. 脚本执行问题A. 权限不足现象：脚本无法执行解决：检查脚本执行权限 chmod +x emqx_monitor.shB. API 认证失败现象：返回 401 或 403 错误解决：检查 API Key 和 Secret 是否正确2. 指标采集问题A. 指标缺失现象：部分指标没有数据解决：确认 EMQX 版本是否支持对应指标B. 数据格式错误现象：Categraf 无法解析解决：检查 data_format 配置是否为 prometheus3. 性能问题A. 采集频率过高现象：频繁调用 API 影响性能解决：调整采集间隔，建议 15 秒以上B. 超时问题现象：脚本执行超时解决：增加 CURL_TIMEOUT 参数值八、最佳实践1. 监控体系设计graph TB A[EMQX 集群] --> B[监控采集] B --> C[Prometheus] C --> D[Grafana] D --> E[可视化面板] C --> F[告警规则] F --> G[告警通知]2. 面板设计建议概览面板：展示核心指标趋势节点面板：分节点展示详细信息业务面板：按业务维度统计消息量3. 告警分级严重告警：立即处理，如节点宕机警告告警：关注处理，如连接数偏高提示告警：记录分析，如偶发认证失败参考资料EMQX 官方文档 - APICategraf 使用指南Prometheus 监控最佳实践
FBI 购买位置数据追踪美国公民，局长证实
FBI 购买位置数据追踪美国公民，局长证实一、新闻概述1. 标题FBI 购买位置数据追踪美国公民，局长证实2. 发布时间2026 年 3 月 18 日3. 来源TechCrunch二、核心内容1. 事件摘要A. 主要内容美国联邦调查局（FBI）局长 Kash Patel 在周三的听证会上证实，该机构已恢复购买大量美国公民的数据和位置历史记录，以协助联邦调查工作。B. 核心亮点这是自 2023 年以来 FBI 首次确认购买数据经纪商的数据数据来自普通消费者手机应用和游戏FBI 声称购买行为符合宪法和电子通信隐私法2. 关键信息A. 涉及机构FBI：购买并使用位置数据的执行机构数据经纪商：收集并出售位置数据的中间商B. 数据来源数据经纪商从以下渠道收集信息：普通消费者手机应用移动游戏其他商业追踪技术C. 法律依据FBI 声称购买行为符合：美国宪法电子通信隐私法（ECPA）3. 背景介绍A. 前置立场2023 年，时任 FBI 局长 Christopher Wray 曾告诉参议员，该机构过去购买过位置数据，但当时并未积极购买。B. 相关上下文美国政府机构近年来通过购买商业可用数据来规避传统的搜查令程序。这种做法引发了对隐私权和第四修正案的担忧。三、详细报道1. 主要内容A. 局长证言在听证会上，俄勒冈州民主党参议员 Ron Wyden 询问 FBI 是否承诺不购买美国人的位置数据。Patel 回应称，该机构使用所有工具来完成任务。Patel 证言表示：FBI 购买的商业可用信息与宪法和法律保持一致，这些数据为 FBI 提供了有价值的情报。B. 参议员质疑Wyden 表示，在没有获得搜查令的情况下购买美国人的信息是对第四修正案的令人愤怒的规避。第四修正案是美国宪法中保护公民免受无理搜查和数据扣押的法律。2. 技术细节A. 数据流向graph TD A[消费者手机应用] -->|收集| B[数据经纪商] C[移动游戏] -->|收集| B B -->|出售| D[FBI] D -->|用于| E[联邦调查] B -->|RTB服务| F[广告生态系统]B. 传统 vs 购买数据方式对比传统方式：政府机构需要说服法官授权搜查令基于犯罪证据从科技公司或电话公司获取私人信息购买数据方式：购买商业可用数据无需搜查令从数据经纪商获取规避了法律审查步骤3. 类似案例A. 美国海关和边境保护局（CBP）根据 404 Media 获取的文件，CBP 购买了一部分来自实时竞价（RTB）服务的数据。这些技术是移动和网络广告行业的核心，收集诸如位置和其他可识别数据，用于向观看广告的人定向投放。B. 监控公司运作机制监控公司可以观察 RTB 过程并收集用户位置信息，然后将这些数据出售给数据经纪商或希望绕过搜查令程序的联邦机构。四、影响分析1. 法律影响A. 第四修正案第四修正案保护美国公民免受无理搜查和扣押。购买商业数据绕过了这一宪法保护。B. 法律理论争议FBI 声称不需要搜查令即可使用这些信息进行联邦调查，但这一法律理论尚未在法庭上接受测试。2. 隐私影响A. 公民隐私权普通用户的应用使用行为被数据经纪商收集，然后被政府机构获取，用户对此通常不知情。B. 透明度问题FBI 拒绝透露购买商业数据的详细信息，包括：购买位置数据的频率从哪些数据经纪商购买3. 行业影响A. 数据经纪商行业政府需求可能刺激数据经纪商业务增长，加剧隐私数据商业化趋势。B. 广告行业RTB 技术原本用于广告投放，现成为政府监控的数据来源，可能影响行业声誉。五、各方反应1. FBI 官方回应FBI 发言人拒绝就 Patel 的证言以外的问题发表评论，也未回答关于机构购买商业数据的问题。2. 国会议员反应A. Ron Wyden 参议员认为购买数据绕过搜查令程序是令人愤怒的行为，引用第四修正案作为法律依据。B. 立法行动Wyden 与其他几位议员最近提出了政府监控改革法案，该法案要求联邦机构在从数据经纪商购买美国人信息之前，必须获得法院授权的搜查令。该法案是两党、两院联合提案。3. 公民社会担忧隐私倡导者和公民自由组织一直对政府购买商业数据的做法表示担忧，认为这是对隐私权的侵犯。六、相关链接1. 相关报道Politico 报道：FBI 购买数据追踪人员Wired 报道：FBI 购买位置数据参议院证言404 Media 报道：CBP 利用在线广告生态系统追踪人员移动2. 法案信息政府监控改革法案：要求联邦机构购买数据前需获得搜查令参考资料FBI is buying location data to track US citizens, director confirms | TechCrunch
Catpaw 事件监控工具入门指南一、概述1. 简介A. 是什么catpaw 是一个轻量级事件监控工具，用于检测系统异常并生成标准化事件。它采用插件化架构，支持多种监控场景，适合与告警系统集成。B. 为什么学轻量级设计，零重依赖，资源占用极低插件化架构，按需启用，灵活性高适合监控系统自监控，避免循环依赖配置简洁，快速实现监控覆盖C. 学完能做什么部署 catpaw 到各类 Linux/Windows 环境配置常用插件进行系统监控集成 Flashduty 或自定义事件接收器开发自定义监控插件2. 前置知识A. 必备技能基本 Linux 命令操作了解监控和告警的基本概念B. 推荐知识Toml 配置文件语法系统监控指标含义（CPU、内存、磁盘等）二、环境准备1. 系统要求Linux：主流发行版（Ubuntu、CentOS、Debian 等）Windows：支持 Windows 服务运行跨平台：支持多架构二进制文件2. 安装步骤下载二进制文件：# 从 GitHub Releases 下载对应平台版本 wget https://github.com/cprobe/catpaw/releases/download/v0.9.0/catpaw-linux-amd64 chmod +x catpaw-linux-amd64 mv catpaw-linux-amd64 /usr/local/bin/catpaw3. 验证安装catpaw --version三、核心概念1. 基本术语事件：监控系统产生的告警或状态变化插件：实现特定监控功能的独立模块事件接收器：接收并处理监控事件的系统2. 工作原理graph LR A[catpaw 监控引擎] --> B{插件调度器} B --> C[插件1: cert] B --> D[插件2: disk] B --> E[插件3: http] C --> F[事件生成器] D --> F E --> F F --> G[Flashduty 告警路由] F --> H[自定义接收器]四、快速上手1. Hello World 示例# 测试模式运行，事件打印到终端 ./catpaw -test2. 核心功能演示配置 Flashduty 集成：编辑 conf.d/config.toml，设置 integration_key启用磁盘监控插件：编辑 conf.d/p.disk/test.toml，配置监控路径和阈值3. 正常运行./catpaw五、插件详解1. 系统资源类插件A. cpu 插件CPU 利用率和负载检查，支持按核心归一化计算。B. mem 插件内存和交换空间使用检查，支持阈值告警。C. disk 插件磁盘空间、inode 和可写性检查，支持多路径监控。2. 网络监控类插件A. http 插件HTTP 可用性、状态码、响应体和证书过期检查。B. ping 插件ICMP 可达性、丢包率和延迟检查。C. dns 插件DNS 解析检查，验证域名解析能力。D. net 插件TCP/UDP 连接性和响应时间检查。3. 容器和进程类插件A. docker 插件Docker 容器监控，检查运行状态、频繁重启、健康检查和资源使用。B. procfd 插件进程级文件描述符监控，防止打开文件数过多。C. procnum 插件进程数量检查，支持系统级和特定进程监控。D. systemd 插件systemd 服务状态检查，确保关键服务正常运行。4. 日志和文件类插件A. logfile 插件普通文本日志文件监控，支持 offset 追踪、日志轮转检测和多编码。B. journaltail 插件通过 journalctl 增量读取日志，支持关键字匹配。C. filecheck 插件文件存在性、修改时间和校验和检查。5. 安全和证书类插件A. cert 插件TLS 证书过期检查，支持远程连接、本地证书文件、STARTTLS 和 SNI。B. secmod 插件SELinux/AppArmor 安全模块基准检查。6. 内核和网络底层类插件A. conntrack 插件Linux conntrack 表使用监控，防止静默丢包。B. neigh 插件Linux ARP/邻居表使用监控，防止新 IP 通信失败。C. netif 插件网络接口健康检查，监控链路状态和错误/丢弃变化。D. tcpstate 插件TCP 连接状态监控，检测 CLOSE_WAIT/TIME_WAIT 积累。E. sockstat 插件TCP 监听队列溢出检测。F. sysctl 插件内核参数基准检查，检测重启/升级后的静默重置。7. 高级功能插件A. exec 插件运行脚本或命令，从输出生成事件，支持 JSON 和 Nagios 模式。B. scriptfilter 插件运行脚本并将输出行与过滤规则匹配以触发告警。C. uptime 插件意外重启检测，当运行时间低于阈值时触发告警，属于自愈事件。D. zombie 插件僵尸进程检测，统计系统中处于 Z 状态的进程数量。六、配置说明1. 全局配置配置文件：conf.d/config.toml主要配置项：Flashduty 集成密钥事件接收器 URL全局超时设置日志级别2. 插件配置配置文件：conf.d/p./*.toml特点：每个插件目录支持多个配置文件加载时自动合并多个配置文件支持 SIGHUP 信号热重载配置热重载配置：kill -HUP $(pidof catpaw)3. 配置示例磁盘监控配置示例：[targets] path = "/var/log" [thresholds] usage_percent = 80 [alert] enabled = true七、部署方式1. 二进制部署适合生产环境，直接下载二进制文件运行。2. systemd 服务配置 systemd service 文件，实现开机自启和守护运行。3. Docker 部署提供 Docker 镜像，支持容器化部署。八、集成 Flashduty1. 创建集成在 Flashduty 控制台创建"标准告警事件"集成，获取 webhook URL。2. 配置 catpaw在 conf.d/config.toml 中设置 flashduty.url 字段。3. 事件流转catpaw 生成标准化事件 -> Flashduty 接收 -> 告警路由 -> 通知发送九、常见问题1. 配置热重载不生效检查配置文件语法是否正确，使用 SIGHUP 信号重载。2. 插件未触发事件检查插件配置是否正确启用，确认阈值设置。3. 与 Flashduty 集成失败验证 integration_key 和 URL 配置，检查网络连通性。十、进阶开发1. 插件开发catpaw 提供插件开发指南，支持自定义监控插件。2. 事件数据模型了解事件结构、标签设计和 AlertKey 规则。3. 命令行参考完整查看 CLI 选项和参数说明。参考资料catpaw GitHub 仓库Flashduty 产品官网catpaw CLI 参考文档catpaw 部署指南
Scrutiny 硬盘 S.M.A.R.T 监控工具详解一、概述1. 简介A. 是什么Scrutiny 是一个硬盘健康仪表板和监控解决方案，将厂商提供的 S.M.A.R.T 指标与真实世界故障率相结合。它是一个基于 Web 的监控工具，用于跟踪硬盘的 S.M.A.R.T 属性历史趋势，并使用真实世界故障率来定制阈值，从而在硬盘故障前提前预警。B. 为什么需要传统 smartd 守护进程存在以下问题：S.M.A.R.T 属性超过百种，smartd 无法区分关键指标和信息性指标smartd 不记录 S.M.A.R.T 属性历史，难以判断属性是否随时间缓慢恶化厂商设定的阈值有时未设置或过高，只能确认已故障的硬盘，无法检测即将故障的硬盘smartd 仅提供命令行界面，对于无头服务器来说 Web UI 更有价值C. 核心价值历史趋势跟踪：记录 S.M.A.R.T 指标的变化历史智能阈值：基于真实世界故障率定制告警阈值可视化仪表板：Web 界面专注于关键指标多设备支持：自动检测所有连接的硬盘驱动器2. 项目背景A. 原始项目Scrutiny 最初由 AnalogJ 创建，是一个开源的硬盘监控解决方案。B. Fork 版本本文档介绍的是 Starosdev 维护的 Fork 版本。原始项目在 2024 年开发速度显著放缓，而社区贡献和功能请求持续增长。这个 Fork 版本接续原始项目的工作，合并了待处理的社区 PR 并添加了新功能。C. 版本对比特性原始版本本 Fork 版本最新版本v0.8.1 (2024年4月)v1.21.0 (2026年2月)前端框架Angular 13现代 Angular (Angular 21)维护状态最小更新积极维护社区 PR多个待处理已合并3. 前置知识A. 必备技能基本了解硬盘和 S.M.A.R.T 技术Docker 基础知识Linux 命令行操作B. 推荐知识InfluxDB 时序数据库Web 服务配置二、系统架构1. 整体架构Scrutiny 采用分层架构设计，包含数据采集层、Web 服务层和数据存储层。graph LR A[Collector] --> B[smartctl] B --> C[Physical Drives] C --> D[Device Devices] A --> E[ZFS Collector] E --> F[ZFS Pools] G[Web Container] --> H[Angular Frontend] G --> I[Go API Backend] J[InfluxDB] --> K[Time Series Data] L[SQLite] --> M[Device Metadata] A --> I I --> J I --> L H --> I2. 组件说明A. Collector（采集器）职责：定期采集硬盘 S.M.A.R.T 数据工具：集成 smartctl 二进制文件调度：默认每日执行一次类型：标准采集器、ZFS 采集器B. Web 服务前端：Angular 框架开发的 Web UI后端：Go 语言开发的 API 服务功能：提供仪表板、设备管理、配置接口C. 数据存储InfluxDB：存储 S.M.A.R.T 时序数据SQLite：存储设备元数据和配置信息3. 数据流转流程sequenceDiagram participant User as 用户 participant Web as Web UI participant API as API Backend participant Collector as Collector participant InfluxDB as InfluxDB participant SQLite as SQLite User->>Web: 访问仪表板 Web->>API: GET /api/devices API->>SQLite: 查询设备列表 SQLite-->>API: 返回设备数据 API-->>Web: JSON 响应 Web-->>User: 显示仪表板 Note over Collector: 定时执行 (默认每日) Collector->>Collector: smartctl --scan Collector->>Collector: smartctl --info Collector->>Collector: smartctl --xall Collector->>API: POST /api/collect API->>InfluxDB: 写入时序数据 API->>SQLite: 更新设备元数据 API-->>Collector: 确认成功三、部署模式1. Omnibus 部署A. 概述Omnibus 模式将所有组件打包在一个 Docker 镜像中，适合单机部署和小规模使用。B. 特点一个容器包含 Web 服务、API 和 Collector内置 InfluxDB配置简单，快速上手2. Hub/Spoke 部署A. 概述Hub/Spoke 模式将组件分离，适合多服务器环境和大规模部署。B. 架构对比graph TB subgraph Omnibus[Omnibus 部署模式] O1[scrutiny omnibus] O1 --> O2[Web UI] O1 --> O3[API Backend] O1 --> O4[Collector] end subgraph HubSpoke[Hub Spoke 部署模式] H1[scrutiny web] --> H2[Web UI] H1 --> H3[API Backend] C1[scrutiny collector] --> C4[smartctl] C2[scrutiny collector zfs] --> C5[ZFS] C1 --> H3 C2 --> H3 end O1 --> D1[InfluxDB] H1 --> D2[InfluxDB]C. 组件分离Web 容器：包含 Web UI 和 API，只需一个实例Collector 容器：包含数据采集器和 smartctl，每台服务器一个InfluxDB：独立容器，只需一个实例四、新功能特性1. ZFS 池监控监控 ZFS 池健康状态跟踪池容量和使用情况与单独硬盘监控并行展示2. Prometheus 指标暴露 /api/metrics 端点支持与 Grafana 集成便于纳入现有监控系统3. 设备归档隐藏已退役硬盘保留历史数据不删除简化仪表板显示4. 设备级别通知控制按设备静音通知适用于已知问题但暂未更换的硬盘5. 自定义设备标签为硬盘添加有意义的名称方便识别和管理6. 天级温度图表更细粒度的温度历史支持日级别数据展示7. SAS 硬盘温度支持正确读取 SAS 设备温度修复原有温度显示问题8. 心跳通知定期发送一切正常的通知默认每 24 小时一次用于集成 Uptime Kuma 等监控工具9. S.M.A.R.T 属性覆盖通过 UI 或配置文件覆盖厂商阈值按设备自定义阈值10. 改进的 UI 布局侧边栏导航移至顶部更好的 S.M.A.R.T 属性可见性移动端优化五、安装部署1. 系统要求A. 硬件要求支持的硬盘类型：ATA、IDE、SCSI-3、SATA、NVMe、SASRAID 控制器：支持 smartctl 的所有 RAID 控制器B. 支持的架构架构名称二进制文件Docker 镜像linux-amd64支持支持linux-arm64支持支持linux-arm-7支持仅 web/collectormacos-amd64支持支持macos-arm64支持支持freebsd-amd64支持不支持windows-amd64支持开发中2. Docker Omnibus 部署A. 快速启动docker run -p 8080:8080 -p 8086:8086 --restart unless-stopped \ -v /path/to/config:/opt/scrutiny/config \ -v /path/to/influxdb2:/opt/scrutiny/influxdb \ -v /run/udev:/run/udev:ro \ --cap-add SYS_RAWIO \ --device=/dev/sda \ --device=/dev/sdb \ --name scrutiny \ ghcr.io/starosdev/scrutiny:latest-omnibusB. 参数说明参数说明-p 8080:8080Web UI 端口映射-p 8086:8086InfluxDB 端口映射-v /run/udev提供设备元数据访问--cap-add SYS_RAWIO允许 smartctl 查询 S.M.A.R.T 数据--device将硬盘设备映射到容器内NVMe 硬盘需要额外添加 --cap-add SYS_ADMINC. 手动触发采集docker exec scrutiny /opt/scrutiny/bin/scrutiny-collector-metrics run3. Hub/Spoke 部署A. 启动 InfluxDBdocker run -p 8086:8086 --restart unless-stopped \ -v /path/to/influxdb2:/var/lib/influxdb2 \ --name scrutiny-influxdb \ influxdb:2.2B. 启动 Web 服务docker run -p 8080:8080 --restart unless-stopped \ -v /path/to/config:/opt/scrutiny/config \ --name scrutiny-web \ ghcr.io/starosdev/scrutiny:latest-webC. 启动 Collectordocker run --restart unless-stopped \ -v /run/udev:/run/udev:ro \ --cap-add SYS_RAWIO \ --device=/dev/sda \ --device=/dev/sdb \ -e COLLECTOR_API_ENDPOINT=http://SCRUTINY_WEB_IPADDRESS:8080 \ --name scrutiny-collector \ ghcr.io/starosdev/scrutiny:latest-collectorD. 启动 ZFS Collector（可选）docker run --restart unless-stopped \ -e COLLECTOR_API_ENDPOINT=http://SCRUTINY_WEB_IPADDRESS:8080 \ --name scrutiny-collector-zfs \ ghcr.io/starosdev/scrutiny:latest-collector-zfs六、配置说明1. 配置文件位置默认路径：/opt/scrutiny/config2. 配置文件类型A. scrutiny.yamlWebapp/API 配置文件B. collector.yamlCollector 配置文件C. collector-zfs.yamlZFS Collector 配置文件3. Cron 调度配置A. 环境变量配置使用 COLLECTOR_CRON_SCHEDULE 环境变量覆盖默认调度：docker run -e COLLECTOR_CRON_SCHEDULE="0 0 * * *" \ ghcr.io/starosdev/scrutiny:latest-collectorB. 默认调度每日午夜执行：0 0 *4. 日志配置A. 日志级别（从高到低）级别说明PANIC记录后调用 panicFATAL记录后调用 os.Exit(1)ERROR错误条件WARN警告条件（也接受 WARNING）INFO一般操作消息（默认）DEBUG详细诊断信息TRACE非常细粒度的诊断信息B. Web 服务器日志配置# 环境变量方式 DEBUG=true SCRUTINY_LOG_FILE=/tmp/web.log # 配置文件方式 log: file: '/tmp/web.log' level: DEBUG # CLI 参数方式 scrutiny start --debug --log-file /tmp/web.logC. Collector 日志配置# 环境变量方式 DEBUG=true COLLECTOR_LOG_FILE=/tmp/collector.log # CLI 参数方式 scrutiny-collector-metrics run --debug --log-file /tmp/collector.log5. 环境变量覆盖A. Web 服务器环境变量（部分）配置键环境变量默认值web.listen.portSCRUTINY_WEB_LISTEN_PORT8080web.listen.hostSCRUTINY_WEB_LISTEN_HOST0.0.0.0web.database.locationSCRUTINY_WEB_DATABASE_LOCATION/opt/scrutiny/config/scrutiny.dbweb.influxdb.hostSCRUTINY_WEB_INFLUXDB_HOSTlocalhostweb.influxdb.portSCRUTINY_WEB_INFLUXDB_PORT8086web.metrics.enabledSCRUTINY_WEB_METRICS_ENABLEDtrueB. Collector 环境变量（部分）配置键环境变量默认值host.idCOLLECTOR_HOST_ID-api.endpointCOLLECTOR_API_ENDPOINThttp://localhost:8080api.timeoutCOLLECTOR_API_TIMEOUT60commands.metrics_smartctl_binCOLLECTOR_COMMANDS_METRICS_SMARTCTL_BINsmartctlC. Docker 专用环境变量环境变量默认值说明COLLECTOR_CRON_SCHEDULE0 0 *Cron 调度表达式COLLECTOR_RUN_STARTUPfalse容器启动时立即运行COLLECTOR_RUN_STARTUP_SLEEP1启动采集前延迟秒数七、告警通知1. 支持的通知服务自定义脚本EmailWebhooksDiscordGotifyHangoutsIFTTTJoinMattermostntfyPushbulletPushoverSlackTeamsTelegramTulip2. 配置示例查看 example.scrutiny.yaml 中的 notify.urls 部分获取配置示例。3. 测试通知curl -X POST http://localhost:8080/api/health/notify4. 心跳通知默认禁用，通过 Web UI 的设置或 /api/settings API 启用可配置间隔，默认每 24 小时有硬盘故障时心跳通知被抑制（故障通知优先）5. 设备级别通知控制通过 Web UI 可以为特定设备静音通知，适用于已知问题但暂未更换的硬盘。八、Prometheus 集成1. 指标端点/api/metrics2. Prometheus 配置示例scrape_configs: - job_name: 'scrutiny' static_configs: - targets: ['scrutiny:8080'] metrics_path: '/api/metrics'九、迁移指南1. 从原始项目迁移如果当前使用 AnalogJ/scrutiny，迁移非常简单：A. 更新镜像引用从：ghcr.io/analogj/scrutiny改为：ghcr.io/starosdev/scrutinyB. 数据兼容性现有的 SQLite 数据库无需更改InfluxDB 数据完全兼容C. 配置文件兼容性scrutiny.yaml 无需修改collector.yaml 无需修改十、故障排除1. RAID/虚拟硬盘A. 设备检测Scrutiny 使用 smartctl --scan 检测设备。B. RAID 控制器支持所有 smartctl 支持的 RAID 控制器都自动支持。C. 设备类型覆盖如果 --scan 未正确检测设备类型，可在配置文件中覆盖。2. NVMe 硬盘NVMe 硬盘需要额外添加：--cap-add SYS_ADMIN3. 设备映射确保将所有硬盘设备映射到容器：--device=/dev/sda --device=/dev/sdb十一、技术栈1. 后端语言：Go版本：84.4% 代码占比2. 前端框架：Angular 21（从 Angular 13 升级）版本：14.1% 代码占比3. 数据库时序数据：InfluxDB 2.x元数据：SQLite4. 许可证MIT License参考资料Starosdev/scrutiny GitHub 仓库AnalogJ/scrutiny 原始项目
s-tui 终端 CPU 压力测试与监控工具技术分析
s-tui 终端 CPU 压力测试与监控工具技术分析一、概述1. 工具简介s-tui（Stress Terminal UI）是一个基于终端的 CPU 压力测试和监控工具，采用 TUI（Terminal User Interface）界面，提供图形化的 CPU 性能监控功能。2. 核心功能CPU 温度、频率、功耗和利用率监控可视化展示温控降频导致的性能下降无需 X 服务器即可运行内置多种 CPU 压力测试选项（stress、stress-ng、FIRESTARTER）3. 技术特点跨平台支持（Linux、各类发行版、树莓派）纯终端界面，资源占用低支持多种压力测试工具集成可配置阈值告警和自动化脚本二、技术架构1. 核心组件graph TB A[s-tui 主程序] --> B[urwid TUI 框架] A --> C[psutil 系统监控] A --> D[压力测试模块] D --> E[stress] D --> F[stress-ng] D --> G[FIRESTARTER] C --> H[CPU 温度] C --> I[CPU 频率] C --> J[CPU 功耗] C --> K[CPU 利用率] B --> L[图形界面] B --> M[侧边栏控制] B --> N[实时数据展示]2. 技术栈分析组件技术选型作用界面框架urwid提供终端 UI 绘图能力系统监控psutil跨平台系统信息获取压力测试stress/stress-ng/FIRESTARTERCPU 负载生成配置管理INI 文件用户配置持久化图表绘制ASCII/UTF-8 字符终端图形渲染A. urwid 框架urwid 是一个 Python 终端 UI 库，特点如下：支持 ASCII 和 UTF-8 字符集提供丰富的 UI 组件（按钮、列表、文本框）事件驱动架构仅支持 UNIX-like 系统B. psutil 库psutil 提供跨平台的系统和进程信息获取：CPU 信息：频率、利用率、温度内存信息：物理内存、交换内存传感器信息：温度、风扇转速硬件兼容性取决于底层系统支持3. 数据流程sequenceDiagram participant U as 用户 participant T as TUI 界面 participant M as 监控模块 participant S as 压力测试 participant H as 硬件 U->>T: 启动 s-tui T->>M: 获取 CPU 状态 M->>H: 读取传感器数据 H-->>M: 返回温度/频率/功耗 M-->>T: 更新显示数据 T-->>U: 绘制图形界面 U->>T: 选择压力测试模式 T->>S: 启动 stress 进程 S->>H: 生成 CPU 负载 H-->>M: 传感器数值上升 M-->>T: 实时更新图表 T-->>U: 显示温度变化曲线三、核心功能详解1. 监控功能A. CPU 温度监控数据来源：/sys/class/thermal 下的温度传感器显示方式：实时曲线图 + 数值显示阈值告警：默认 80°C，可自定义B. CPU 频率监控显示当前频率支持多核 CPU 频率分别监控可检测降频事件C. CPU 功耗监控支持硬件：Intel Core 二代及以上（Sandy Bridge）AMD Family 17h 系列（通过 amd_energy 驱动）数据单位：瓦特（W）D. CPU 利用率监控总体 CPU 使用率单核使用率更新频率：约 1 秒2. 压力测试功能A. stress 工具传统的 CPU 压力测试工具：# 安装 sudo apt-get install stress # 常用参数 --cpu N # 启动 N 个子进程对 CPU 施压 --timeout N # 超时时间（秒） --vm N # 启动 N 个进程进行内存压力测试B. stress-ng 工具stress 的增强版，提供更多测试场景：支持 300+ 种压力测试方法更精细的测试控制更详细的统计信息C. FIRESTARTER 工具极端 CPU 压力测试工具：通过子模块集成需要编译安装不支持所有系统3. 配置与扩展A. 配置文件保存位置：~/.config/s-tui/s-tui.conf保存内容：图表显示选项压力测试模式温度阈值设置B. 阈值脚本（Hooks）位置：~/.config/s-tui/hooks.d/tempsource.sh触发条件：CPU 温度超过阈值执行频率：每 30 秒一次（持续超温时）示例脚本：#!/bin/bash # 温度超限告警脚本 echo "CPU 温度告警: $(date)" >> /var/log/cpu_temp_alert.log # 可以添加邮件通知、系统广播等四、安装与部署1. 安装方法A. pip 安装（推荐）# 用户安装 pip install s-tui --user # 系统安装 sudo pip install s-tuiB. 发行版包管理器发行版安装命令Ubuntu 18.10+sudo apt install s-tuiDebian 10+sudo apt install s-tuiArch/Manjarosudo pacman -S s-tuiFedorasudo dnf install s-tuiOpenSUSEsudo zypper install s-tuiC. 从源码安装git clone https://github.com/amanusk/s-tui.git cd s-tui pip install urwid psutil python -m s_tui.s_tui2. 依赖关系A. 必需依赖Python 3.xurwid：终端 UI 框架psutil：系统信息获取B. 可选依赖stress：基础压力测试stress-ng：增强压力测试FIRESTARTER：极端压力测试五、使用指南1. 基本使用A. 启动程序s-tuiB. 界面操作方向键/hjkl：导航侧边栏Modes：切换压力测试模式Graphs：选择显示的图表Summaries：选择统计信息Reset：重置图表和统计UTF-8：切换 UTF-8 绘图模式Save Settings：保存当前配置q：退出程序2. 命令行参数# 调试模式 s-tui -d # 调试运行 5 秒后退出 s-tui -dr # 保存数据到 CSV s-tui -c # 自定义 CSV 文件 s-tui --csv-file custom.csv # 单行显示模式 s-tui -t # JSON 输出 s-tui -j # 禁用鼠标（TTY 环境） s-tui -nm # 设置温度阈值 s-tui --t_thresh 85 # 显示版本 s-tui -v3. 使用场景A. 散热性能测试启动 s-tui开启压力测试模式观察温度曲线和频率变化检查是否出现降频B. 稳定性测试长时间运行压力测试：# 配合 timeout 命令 timeout 3600 s-tui -cC. 性能监控对比不同散热方案对比不同 BIOS 设置对比超频前后对比六、技术优势与局限1. 技术优势A. 轻量级无需图形界面资源占用低可在服务器环境运行B. 跨平台支持多种 Linux 发行版支持 ARM 架构（树莓派）依赖库广泛可用C. 可扩展支持自定义阈值脚本模块化压力测试工具配置文件持久化2. 技术局限A. 硬件依赖传感器数据依赖硬件支持功耗监控仅支持特定 CPU部分功能需要特定驱动B. 系统兼容性仅支持 UNIX-like 系统TTY 环境需要禁用鼠标终端字体影响显示效果C. 功能局限不支持进程监控（与 htop 定位不同）压力测试模式相对简单无远程监控功能七、与同类工具对比1. 与 htop 对比特性s-tuihtop定位CPU 监控 + 压力测试进程监控图形化温度/频率曲线进程列表压力测试内置无温度监控是否（需补丁）降频检测是否2. 与 stress-tool 对比特性s-tuistress-tool可视化是否实时监控是否压力测试集成专注易用性友好命令行八、最佳实践1. 散热测试流程确认环境温度和通风条件启动 s-tui 并记录初始温度开启压力测试模式观察温度上升曲线记录稳定温度和是否降频测试持续 10-30 分钟保存数据用于分析2. 故障诊断通过 s-tui 可以诊断：散热系统性能不足温控策略过于激进硅脂老化导致散热不良风扇转速异常3. 性能调优根据监控数据调整：BIOS 电源管理设置CPU 频率限制策略散热风扇曲线系统电源配置九、发展趋势1. 当前状态GitHub 星标：4.9k最新版本：v1.3.0（2026-01-12）活跃维护：20 位贡献者使用项目：173 个2. 技术演进方向更多硬件传感器支持改进的图形渲染远程监控功能Web 界面支持3. 社区生态多个发行版官方收录丰富的第三方集成活跃的问题反馈和功能讨论十、总结s-tui 是一个设计精良的终端 CPU 监控和压力测试工具，通过 urwid 实现优雅的 TUI 界面，结合 psutil 实现跨平台的硬件监控。其核心价值在于将复杂的 CPU 监控数据以直观的图形方式呈现，并内置压力测试功能，为系统管理员和硬件爱好者提供了一站式的 CPU 性能测试解决方案。工具的轻量级特性使其特别适合服务器环境和无头系统，而丰富的配置选项和扩展能力则满足了不同场景的使用需求。尽管存在硬件兼容性和系统限制，但 s-tui 仍然是 Linux 平台上 CPU 监控和压力测试领域的优秀工具。参考资料s-tui GitHub 仓库s-tui 官方文档
爱尔兰拟赋予警方间谍软件和破解加密消息的权限
爱尔兰拟赋予警方间谍软件和破解加密消息的权限一、新闻概述1. 标题爱尔兰拟赋予警方间谍软件和破解加密消息的权限2. 发布时间2026 年 1 月 21 日3. 来源The Register二、核心内容1. 事件摘要A. 主要内容爱尔兰政府计划通过新的通信（拦截与合法访问）法案，增强警方拦截通信的能力，包括加密消息，并为间谍软件的使用提供法律基础。B. 核心亮点现行 1993 年法案将被取代，该法案早于过去 20 年的电信革命新法案将涵盖物联网设备、电子邮件服务和电子消息平台无论消息是否加密都将纳入监管范围为间谍软件使用建立法律框架2. 关键信息A. 版本号/发布内容通信（拦截与合法访问）法案B. 重要数据现行法案制定于 1993 年，距今超过 30 年距离上月生物识别技术扩展提案仅一个月C. 涉及产品/技术端到端加密消息平台物联网设备IMSI 捕获器（Stingray 设备）间谍软件3. 背景介绍A. 前置版本/历史现行邮政包和电信消息（监管）法案 1993 年制定于互联网普及之前，无法应对现代数字通信环境。B. 相关上下文2025 年 12 月，爱尔兰推出了记录设备法案，提议扩大警方对生物识别技术的使用，包括实时和回顾性面部识别。三、详细报道1. 主要内容A. 功能更新建立数字通信拦截的新法律框架将物联网设备、电子邮件服务和电子消息平台纳入监管范围为间谍软件使用提供法律依据赋予警方在特定位置扫描电子设备的权限B. 技术改进遵循欧盟委员会 2025 年发布的执法数据拦截路线图参考欧洲委员会 2024 年关于间谍软件合法性的文件建立强有力的法律保障机制C. 政策变化从 1993 年过时法案转向全面的现代监控法律框架。2. 技术细节A. 架构变化graph TB subgraph 现行框架 A1[1993年法案 邮政包和电信消息法] end subgraph 新法案框架 B1[通信拦截] B2[加密消息访问] B3[间谍软件使用] B4[设备扫描] end subgraph 监管范围 C1[电子邮件服务] C2[消息平台] C3[物联网设备] C4[网络通信] end A1 -->|被取代| B1 B1 --> B2 B2 --> B3 B3 --> B4 B1 --> C1 B1 --> C2 B1 --> C3 B1 --> C4B. 系统组成新法案主要组件包括：通信拦截授权法院批准机制比例原则审查严格监督框架加密访问机制政府未说明具体技术实现承诺实施隐私和安全保障建立执法机构与通信服务提供商的技术合作结构间谍软件使用仅在绝对必要情况下使用需要法官批准严格的监督机制设备扫描能力IMSI 捕获器（ Stingray 设备）特定位置的人员识别关联人员追踪C. 数据流向graph LR subgraph 服务提供商 SP1[电子邮件服务] SP2[消息平台] SP3[物联网提供商] end subgraph 通信内容 CT1[加密消息] CT2[未加密消息] CT3[设备数据] end subgraph 执法部门 LE[爱尔兰警方 An Garda Siochana] end subgraph 监督机制 O1[法院批准] O2[比例审查] O3[使用记录] end SP1 --> CT1 SP2 --> CT1 SP3 --> CT3 CT1 -->|合法拦截| LE CT2 -->|合法拦截| LE CT3 -->|设备扫描| LE LE -->|申请授权| O1 O1 -->|批准| LE LE -->|报告使用情况| O23. 数据与事实A. 加密争议端到端加密（E2EE）技术无法在不破坏安全性的前提下创建后门技术专家指出加密是绝对的，要么端到端加密，要么不是英国 2025 年曾要求苹果破坏 iCloud 高级数据保护，最终失败B. 国际对比国家/地区状态说明爱尔兰提案阶段通信拦截法案英国失败要求苹果建立加密后门未成功欧盟争议中聊天控制法规，取消强制扫描组件美国持续各州采用 IMSI 捕获器C. 服务提供商立场Signal 和 Tuta Mail 等主要服务提供商威胁将撤出实施破坏加密法律的国家。四、影响分析1. 行业影响A. 技术趋势全球范围内执法部门对破解加密的需求持续增长加密与执法需求之间的矛盾日益尖锐服务提供商可能面临合规与退出市场的选择B. 竞争格局爱尔兰作为欧盟成员国，其立法可能与欧盟整体监管框架产生冲突技术公司可能重新评估在爱尔兰的业务布局2. 用户影响A. 现有用户隐私保护可能被削弱加密通信的安全性可能受损数据可能被合法拦截B. 潜在用户对隐私敏感的用户可能避开爱尔兰服务可能推动用户转向更安全的通信方式C. 迁移成本服务提供商可能需要重构加密实现用户可能需要更换通信平台3. 技术趋势A. 技术方向执法部门持续寻求技术解决方案访问加密数据隐私保护技术与服务端扫描技术并行发展量子计算可能进一步加剧加密争议B. 生态影响加密立法可能成为欧盟数字单一市场的障碍可能促使开发更强的反监控技术五、各方反应1. 官方回应司法部长 Jim O'Callaghan 表示：迫切需要新的法律框架来应对严重犯罪和安全威胁新立法将包含强有力的法律保障确保此类权力的使用是必要且成比例的2. 业内评价A. 专家观点爱尔兰公民自由委员会（ICCL）监察和人权高级政策官员 Olga Cronin 表示：对这份监控权力清单有非常严重的担忧这些是具有非凡影响力的监控工具和权力对人们的权利和自由有广泛影响一旦此类权力被常态化，对权利和自由的损害可能极其难以逆转B. 技术社区端到端加密无法在不破坏安全性的前提下创建后门服务提供商威胁撤出市场3. 用户反馈A. 正面评价支持执法部门打击严重犯罪认为需要在安全和隐私之间取得平衡B. 负面评价担心权力滥用和隐私侵犯质疑加密访问的技术可行性担心监控范围从严重犯罪扩展到轻微犯罪C. 中立观察需要看具体立法细节监督机制的有效性有待验证技术实现方案仍不明确六、相关链接1. 官方公告爱尔兰司法部公告欧盟委员会执法数据拦截路线图2. 相关报道英国要求苹果建立加密后门事件欧盟聊天控制法规争议各国监控立法进展3. 技术文档欧洲委员会 2024 年间谍软件合法性文件端到端加密技术说明参考资料Ireland wants to give its cops spyware, ability to crack encrypted messages
中国智慧警务监控系统技术分析一、概述1. 事件背景根据澳大利亚战略政策研究所（ASPI）2025 年发布的研究报告，中国正在利用人工智能技术大幅强化其监控体系。本文基于清华大学 2018 年发布的《智慧警务——大数据环境下新时代公安信息化建设模式探索》官方手册，分析中国智慧警务系统的技术架构和实施现状。2. 核心定义智慧警务（Smart Policing）是指中国公安部利用大数据分析、人工智能和全国性数据整合平台，实现对社会治安的实时监控、犯罪预测和人员追踪的警务信息化系统。3. 系统目标支持犯罪侦查和公共秩序维护实现"社会和谐"与"稳定"提供全国范围的数据共享和实时查询能力二、历史发展1. 起源（2012 年）自 2012 年起，大数据分析成为中国公安部的重要工具，用于支持社会稳定维护工作。2. 关键转折（2017 年）2017 年标志着大数据分析直接引入中国警方实践的重要里程碑。目标包括：提供新鲜、可随时访问的信息支持实时监控数据查询构建预测性模式分析3. 系统命名随着"智慧警务"这一新概念的出现，各省公安机关开始：数字化和整合数据集建立持续的数据流入机制消除数据冗余实现全国信息共享三、系统架构1. 数据源整合智慧警务系统整合了多种数据来源：graph TD subgraph 数据源层 A[视频监控] B[移动轨迹] C[在线消息] D[社交媒体档案] E[电话监控] F[酒店登记] G[出行记录] H[银行记录] end subgraph 传输层 I[数据接口协议] J[数据库模式] end subgraph 存储处理层 K[大数据存储] L[数据清洗] M[机器学习结构化] N[哈希标识符] end subgraph 应用层 O[人员定位] P[轨迹追踪] Q[关系分析] R[风险预警] end A --> I B --> I C --> I D --> I E --> I F --> I G --> I H --> I I --> J J --> K K --> L L --> M M --> N N --> O N --> P N --> Q N --> R2. 雪亮工程雪亮工程（Sharp Eyes Project）是该系统发展的关键阶段，其目标是将所有形式的监控整合：视频监控流人员移动数据在线消息社交媒体档案电话通话监控3. 数据处理流程系统采用了标准化的数据存储和处理流程：graph LR A[原始数据采集] --> B[数据清洗] B --> C[机器学习结构化] C --> D[哈希标识符生成] D --> E[下游应用准备] E --> F[实时查询] E --> G[预测分析] E --> H[监控告警]4. 身份标识系统系统的一个关键技术细节是：每个实体（包括全部 13 亿中国公民）都可被缩减为单一哈希值该哈希值源自多个个人标识符即使没有国家身份证的个人也能获得唯一标识符实现更快的搜索和更快的身份验证四、应用功能1. 湖南省公安厅应用实例手册展示了湖南省公安厅使用的应用程序截图，揭示了系统的实际功能：A. 概览面板显示特定辖区内有多少"刑满释放人员"显示"吸毒人员"数量显示"少数民族"人数B. 通信关系分析分析不同用户之间基于电话通信的关系模型展示社交网络图谱C. 酒店登记追踪实时记录酒店入住信息包括停留时长、来源地、目的地等数据D. 出行追踪通过火车和飞机追踪个人移动跨区域轨迹监控E. 综合分析平台包含以下功能：目标轨迹追踪通话记录查询社交媒体查找银行记录访问"高风险"个人抵达预警2. 权限与访问所有数据可供有系统访问权限的单个警官使用数据提供时间为 24/7 全天候无需特定法院命令即可调查个人仅需登录和内部系统权限五、技术挑战与演进1. 早期挑战A. 数据处理能力不足传统上，中国执法和安全机构面临的问题：收集的数据远超处理能力收集信息是一回事，高效处理是另一回事B. 数据质量问题许多地区公安警官缺乏正确输入数据的培训自动化收集系统尚未完全建立或互连2. 技术改进A. 数据中心扩展现代计算技术进步数据中心快速扩张内外部安全设备现代化推进B. 数字化社会推动随着中国社会越来越多地拥抱在线和数字服务：依赖无数应用和移动平台监控系统变得更加密集和高效数据可能仍然延迟，但更多传感器和数据流被吸收六、政治背景与影响1. 定义范围在该系统中，"罪犯"的定义极其广泛，包括：刑满释放人员吸毒人员在逃人员扒手少数民族2. 忠诚原则加入中国警察时，学生必须学习公安工作"十六字方针"的第一个要素："对党忠诚"3. 企业数据获取私营企业被要求将其数据输入这些系统，几乎没有拒绝的余地：安全服务可获得异常新鲜和全面的数据可能远超大多数西方同行可依赖的数据（尽管差距正在缩小）4. 用途警方利用这些工具来：制衡异议人士确保信息审查追踪对官方叙事的威胁七、国际视角1. 全球背景将焦点完全放在中国是不公平的。大数据分析、数据挖掘和预测性警务是全球各地警察机构都在从事的做法。在某些情况下，这些工具确实可以帮助识别和逮捕真正的罪犯或危险个人和团体。2. 独特性除朝鲜外，没有其他地方的社会控制、政治目标、机构与一党战略之间的联系像中国这样紧密交织。3. 全球扩展系统的范围不断扩大：不再限于国内数据源过去几个月记录的多个案例表明这些大规模分析系统正在摄入全球信息4. 警示让中国的情况成为未能关注这些发展的社会的警示。西方国家安全服务也在与 Palantir 或 Dataminr 等公司建立合作关系，在可处理、存储或处理的数据方面的监督往往出奇有限。八、技术能力评估1. 实战效果根据作者在中国作为记者工作的经验：该系统通常运作良好在新疆或其他敏感地区报道时警方有时能快速定位和追踪他们能够追踪联系人或交谈过的人有时便衣警察会在当地火车站或机场"迎接"他们2. COVID-19 提升零 COVID 政策很可能也提升了该系统的能力。3. 系统局限性系统仍然不完美，许多漏洞仍然存在，可能永远无法完全消除。但它展示了连贯、整体和互联系统可以实时交付的令人印象深刻的能力。九、参考资料ASPI 报告：中国 AI 系统如何重塑人权清华大学《智慧警务——大数据环境下新时代公安信息化建设模式探索》NetAskari: Smart policing with Chinese characters
AMD Linux 下 Per Core 监控问题技术分析一、事件概述1. 事件背景2025 年 1 月，开发者 Manjusaka_Lee 在尝试实现 AMD CPU 在 Linux 下的 per core（每核心）温度和功率监控功能时，遇到技术挑战。2. 核心问题AMD CPU 在 Linux 环境下无法直接获取 per core 的温度、功率等监控信息，需要通过特定的 PM Table（Performance Monitoring Table）进行访问。二、技术背景1. AMD CPU 监控机制AMD CPU 的监控信息存储在 PM Table 中，需要通过特定的接口和驱动程序才能访问。2. Linux 下的监控工具传统 Linux 监控工具（如 lm-sensors）对 AMD CPU 的 per core 监控支持有限。三、技术分析1. PM Table 结构PM Table 包含每个 CPU 核心的性能和功耗数据。访问这些数据需要：正确的内存映射地址适当的权限和驱动支持符合 AMD 规范的数据解析方法2. 开发过程根据原始推文，开发者在尝试基于现有代码实现功能时发现了多个问题，涉及 PM Table 的正确解析和访问。四、解决方案方向1. 驱动层面需要 AMD 官方或社区提供完善的 Linux 驱动支持。2. 用户空间工具通过读取 sysfs 接口或使用专门的监控库获取数据。3. 参考实现基于开源项目 https://github.com/Manjusaka/ryzen_smu_utils 等工具进行开发。五、技术挑战1. 接口复杂性AMD PM Table 的访问接口相对复杂，需要深入了解硬件规范。2. 兼容性不同代号的 AMD CPU 可能有不同的 PM Table 结构。3. 权限要求访问硬件监控信息通常需要 root 权限。六、行业影响1. AMD Linux 生态此问题反映了 AMD 在 Linux 生态下的监控工具仍需完善。2. 开发者体验相较于 Intel CPU 的工具支持，AMD 开发者在 Linux 下进行性能调优面临更多挑战。参考资料原始推文ryzen_smu_utils
xyOps 开源运维自动化平台技术分析一、新闻概述1. 标题xyOps：一体化运维自动化平台的创新突破2. 发布时间2026 年 1 月（最新版本 v0.9.31）3. 来源GitHub 开源项目 pixlcore/xyops二、核心内容1. 事件摘要A. 主要内容xyOps 是一个下一代运维自动化系统，将作业调度、工作流自动化、服务器监控、告警和事件响应整合到单一平台中。该项目采用 BSD-3-Clause 开源协议，在 GitHub 上获得了超过 1200 个星标和 116 个 Fork。B. 核心亮点一体化平台：集成调度、监控、告警、工单于一体可视化工作流编辑器实时监控与智能告警完全开源，无功能付费墙支持从 5 台到 5000 台服务器的弹性扩展2. 关键信息A. 版本号v0.9.31（当前最新版本）B. 重要数据GitHub 星标：1.2k+Fork 数量：116代码提交：1,977 次主要语言：JavaScript（92.7%）、CSS（5.9%）C. 涉及产品xyOps 运维自动化平台3. 背景介绍A. 项目定位面向开发者和运维团队的开源自动化平台，强调数据主权、开放性和可扩展性。B. 相关上下文项目由 pixlcore 团队维护，采用完全开源的 BSD 协议，承诺长期维护，无商业功能限制。三、详细报道1. 主要内容A. 核心理念传统自动化平台通常专注于工作流编排——它们运行任务，但缺乏对背后运行状态的深度洞察。xyOps 超越了这一局限。它不仅调度作业，还将它们与实时监控、告警、服务器快照和工单系统连接起来，创建了一个完整的集成反馈循环。B. 功能特性作业调度：超越传统 cron 的强大调度能力可视化工作流：图形化编辑器连接事件、触发器、动作和监控全方位监控：自定义监控指标，实时异常通知智能告警：丰富可定制的告警规则和复杂触发条件工单集成：作业失败时自动创建包含完整上下文的工单C. 技术架构xyOps 采用 Node.js 构建，支持 Docker 部署，提供完整的 REST API 和 Web 界面。D. 部署方式提供一键 Docker 部署命令：docker run --detach --init --restart unless-stopped \ -v xy-data:/opt/xyops/data \ -v /var/run/docker.sock:/var/run/docker.sock \ -e TZ="America/Los_Angeles" \ -e XYOPS_xysat_local="true" \ -p 5522:5522 -p 5523:5523 \ --name xyops01 --hostname xyops01 \ ghcr.io/pixlcore/xyops:latest2. 技术细节A. 系统架构graph TB User[用户] --> Web[Web界面] Web --> Scheduler[作业调度器] Web --> Workflow[工作流引擎] Web --> Monitor[监控系统] Scheduler --> Agent[代理] Workflow --> Agent Monitor --> Agent Agent --> Servers[目标服务器] Monitor --> Alert[告警系统] Alert --> Ticket[工单系统] Monitor --> Snapshot[服务器快照]B. 集成反馈循环sequenceDiagram participant A as 告警系统 participant J as 作业调度 participant M as 监控系统 participant T as 工单系统 participant U as 用户 M->>A: 检测异常 A->>U: 发送告警（含作业状态） U->>M: 查看服务器快照 J->>J: 作业失败 J->>T: 自动创建工单 T->>U: 通知（含日志和指标） U->>T: 处理工单C. 工作流设计graph LR Event[事件] --> Trigger[触发器] Trigger --> Action[动作] Action --> Monitor[监控] Monitor --> Decision{条件判断} Decision -->|满足| Alert[告警] Decision -->|不满足| End[结束] Alert --> Ticket[工单]3. 数据与事实A. 代码统计JavaScript：92.7%CSS：5.9%其他：1.4%B. 社区活跃度Watchers：17Issues：29 个未关闭Pull Requests：活跃讨论发布版本：32 个版本四、影响分析1. 行业影响A. 技术趋势一体化运维平台成为趋势，打破传统工具孤岛开源替代方案挑战商业运维平台可观测性与自动化深度融合B. 竞争格局对比商业产品：完全开源，无功能付费墙对比传统工具：整合监控、调度、工单于一体对比云服务：支持私有化部署，数据完全可控2. 用户影响A. 现有用户降低运维工具学习成本统一平台管理所有运维操作提升故障响应效率B. 潜在用户中小企业：免费开源，降低运维成本开发者：友好的 API 和扩展机制安全敏感场景：私有化部署，数据不出域C. 迁移成本Docker 一键部署，快速上手支持导入现有作业配置提供完整的 API 集成能力3. 技术趋势A. 技术方向运维平台从工具化向平台化演进实时可观测性与自动化闭环低代码/无代码工作流编辑B. 生态影响推动 DevOps 工具链整合促进运维标准化实践为企业提供开源替代方案五、各方反应1. 官方立场项目强调开放性、可靠性和公平性，承诺永久开源，采用 OSI 认可的 BSD-3-Clause 协议。2. 业内评价A. 专家观点一体化设计符合运维发展趋势可视化工作流降低使用门槛开源模式有利于社区贡献B. 社区反馈GitHub 星标快速增长，显示社区认可度高活跃的 Issue 讨论和 Pull RequestFork 数量显示项目受到关注3. 用户反馈A. 正面评价功能全面，整合多个运维场景部署简单，Docker 一键启动完全开源，无商业限制B. 关注点项目仍处于活跃开发阶段（版本号 0.9.x）企业级功能仍在完善中文档和社区资源待丰富六、相关链接1. 官方资源GitHub 仓库：https://github.com/pixlcore/xyops官方网站：https://xyops.ioDocker 镜像：ghcr.io/pixlcore/xyops2. 文档资源自托管指南：https://github.com/pixlcore/xyops/blob/main/docs/hosting.md开发指南：https://github.com/pixlcore/xyops/blob/main/docs/dev.md贡献指南：https://github.com/pixlcore/xyops/blob/main/CONTRIBUTING.md3. 社区资源Issues 讨论：https://github.com/pixlcore/xyops/issuesPull Requests：https://github.com/pixlcore/xyops/pullsDiscussions：https://github.com/pixlcore/xyops/discussions参考资料pixlcore/xyOps GitHub 仓库xyOps 官方网站项目自托管文档
Situation Monitor 实时态势监控仪表板技术分析一、项目概述1. 项目简介Situation Monitor 是一个开源的实时全球态势监控仪表板项目，用于监测全球新闻动态、市场数据和地缘政治事件。该项目采用现代化的前端技术栈构建，提供可自定义的监控面板系统，帮助用户及时了解世界范围内的重大事件和市场变化。2. 核心特点实时数据聚合：集成多个新闻源和市场数据 API模块化面板设计：支持灵活配置和自定义监控面板预设模板系统：内置多种监控预设，快速上手自动刷新机制：支持自动和手动数据刷新响应式布局：适配不同屏幕尺寸3. 技术栈前端框架：SvelteKit + TypeScriptUI 框架：Tailwind CSS状态管理：Svelte Stores部署平台：支持 Vercel、GitHub Pages二、系统架构1. 总体架构项目采用经典的三层架构设计：graph TB subgraph DataSources N[News APIs] M[Market APIs] C[Crypto APIs] G[Gov Contracts] P[Polymarket] F[Federal Reserve] end subgraph Frontend UI[SvelteKit UI] ST[State Stores] CMP[Components] end subgraph Panels NP[News Panels] MP[Markets Panels] HP[Heatmap Panel] SP[Situation Panels] MP2[Monitors Panel] end N --> API[API Layer] M --> API C --> API G --> API P --> API F --> API API --> ST ST --> CMP CMP --> UI UI --> NP UI --> MP UI --> HP UI --> SP UI --> MP22. 核心组件A. 数据层API 模块：封装所有外部数据源调用类型定义：TypeScript 接口定义数据结构错误处理：统一的错误处理机制B. 状态层News Store：管理新闻数据状态Markets Store：管理市场数据状态Monitors Store：管理自定义监控器Settings Store：管理用户配置Refresh Store：管理刷新状态C. 组件层布局组件：Header、Dashboard面板组件：各类监控面板模态组件：设置、表单、入门向导三、数据流设计1. 数据获取流程graph LR subgraph DataFetch A[User Action] --> B[fetchAllNews] A --> C[fetchAllMarkets] A --> D[fetchPolymarket] A --> E[fetchWhaleTransactions] A --> F[fetchGovContracts] A --> G[fetchLayoffs] A --> H[fetchWorldLeaders] A --> I[fetchFedData] end B --> J[News Store] C --> K[Markets Store] D --> L[Predictions State] E --> M[Whales State] F --> N[Contracts State] G --> O[Layoffs State] H --> P[Leaders State] I --> Q[Fed Indicators State] J --> R[Panels Render] K --> R L --> R M --> R N --> R O --> R P --> R Q --> R2. 状态管理模式项目使用 Svelte Stores 进行状态管理，每个数据源都有对应的状态 store：加载状态：loading 布尔值数据状态：具体数据内容错误状态：error 信息自动刷新：refresh 机制四、核心功能模块1. 新闻监控面板支持的新闻分类Politics：政治新闻Tech：科技新闻Finance：财经新闻Government：政府动态AI：人工智能相关Intel：情报信息功能特点实时新闻抓取分类展示关键词高亮相关性分析2. 市场监控面板监控内容指数数据：主要市场指数板块数据：行业板块表现大宗商品：黄金、原油等加密货币：主流数字货币数据来源Finnhub API：提供实时市场数据其他金融数据源3. 分析面板A. 相关性分析面板分析不同事件之间的关联性，帮助发现潜在的模式和趋势。B. 叙事分析面板追踪新闻事件的发展脉络，构建事件叙事链。C. 热力图面板以可视化方式展示市场热度分布。4. 情况监控面板地缘政治监控Venezuela Watch：委内瑞拉人道主义危机监控Greenland Watch：北极地缘政治监控Iran Crisis：伊朗危机监控监控机制关键词匹配实时预警历史追踪5. 自定义监控器用户可以创建自定义监控器，设置关键词和监控规则，实现个性化监控需求。五、应用流程graph TD A[Application Start] --> B{Onboarding Complete?} B -->|No| C[Show Onboarding Modal] C --> D[User Select Preset] D --> E[Apply Preset Settings] E --> F[Initial Data Load] B -->|Yes| F F --> G[Load News] F --> H[Load Markets] F --> I[Load Misc Data] F --> J[Load World Leaders] F --> K[Load Fed Data] G --> L[Setup Auto Refresh] H --> L I --> L J --> L K --> L L --> M[Dashboard Ready] M --> N{User Interacts} N -->|Refresh| O[Manual Refresh] N -->|Settings| P[Open Settings] N -->|Monitor| Q[Create/Edit Monitor] O --> M P --> M Q --> M六、技术实现细节1. 组件架构布局组件Header：顶部导航栏，包含设置入口Dashboard：主仪表板容器，采用 CSS Grid 布局面板组件项目包含 20+ 个面板组件，每个面板负责特定数据类型的展示：NewsPanel：新闻面板MarketsPanel：市场面板HeatmapPanel：热力图面板CryptoPanel：加密货币面板WhalePanel：大额交易监控PolymarketPanel：预测市场ContractsPanel：政府合约LayoffsPanel：裁员追踪WorldLeadersPanel：世界领导人动态FedPanel：美联储数据PrinterPanel：货币供应监控2. 状态管理Svelte Stores使用 Svelte 的响应式 stores 管理应用状态：// 示例：新闻 store 结构 const news = { items: {}, loading: {}, error: {}, setLoading: (category, value) => {}, setItems: (category, items) => {}, setError: (category, error) => {} }自动刷新机制setupAutoRefresh：设置定时刷新stopAutoRefresh：停止刷新startRefresh：开始刷新流程endRefresh：结束刷新流程3. 预设系统预设配置内置多种监控预设，用户首次使用时选择：Minimalist：精简配置Analyst：分析师配置Comprehensive：全面配置面板可见性控制通过 settings.enabled 对象控制各面板的显示状态：isPanelVisible(id: PanelId): boolean { return $settings.enabled[id] !== false; }七、部署与配置1. 环境变量配置项目支持通过 .env 文件配置 API 密钥：# Finnhub API for market data FINNHUB_API_KEY=your_key_here # Other API keys as needed2. 部署选项Vercel 部署项目包含 vercel.json 配置文件，支持一键部署到 Vercel 平台。GitHub Pages支持静态部署到 GitHub Pages，已配置预渲染和 favicon。八、项目特色与创新1. 模块化设计每个监控面板都是独立组件，便于扩展和维护。2. 灵活的配置系统用户可以根据需求自定义显示的面板和监控内容。3. 多数据源整合整合新闻、市场、加密货币、政府合约等多种数据源。4. 实时更新机制支持自动和手动刷新，确保数据的及时性。九、技术挑战与解决方案1. API 限流处理通过合理的刷新频率控制和错误重试机制应对 API 限流。2. 数据缓存策略使用 Svelte Stores 进行客户端缓存，减少不必要的 API 调用。3. 性能优化按需加载：仅加载可见面板的数据并行请求：使用 Promise.all 并行获取数据条件渲染：根据用户配置选择性渲染面板十、项目生态1. 社区活跃度GitHub Stars：367Forks：95Contributors：3 人2. 持续更新项目活跃开发中，最近的更新包括：添加美联储监控面板修复 Vercel 重定向 URL 问题GitHub Pages 404 问题修复3. 开源贡献项目采用开源方式开发，欢迎社区贡献代码和功能建议。参考资料GitHub - hipcityreg/situation-monitor在线演示 - situation-monitor-rose.vercel.app