通过 mTLS 的服务器群监控

服务器群里的每一台, 一个绿色控制台 一览无余。

轻量代理通过双向 TLS 上报指标与安全信号。Servers Sentinel 为每台主机打分,向你惯用的渠道告警,并在暴力破解开始的瞬间标记出来。

首台服务器免费。无需信用卡,一行命令安装。

为 Windows 与 Linux 混合服务器群而生

systemd + Windows 服务amd64 · arm64 · 386mTLS 接入自托管或托管
01为什么

两次上报之间,服务器群会失明

等仪表盘刷新时,事件已经过去一小时。Servers Sentinel 弥合这个缺口。

盲区

一台主机停止上报,直到用户发现才有人察觉。覆盖不该取决于谁在盯着屏幕。

告警疲劳

每个工具都有自己的收件箱。信号散落在邮件、聊天和 Webhook 里,最后全被忽略。

无声的暴力破解

RDP 和 SSH 的密码猜测会跑上数小时,才在日志审查里露头。它应当在数秒内浮现。

配置漂移

按服务器设置的阈值会随时间失同步。默认值应当级联下发,主机在其上按需覆盖。

一个代理、一个控制台、每台主机一个分数

Servers Sentinel 在本地采集指标,通过双向 TLS 上报,并凝练为一个健康分数和一条清晰告警。全局模板级联到每台服务器;任何主机都可覆盖某个键而不破坏默认值。

02工作原理

从安装到告警,四步搞定

无需编译,无需开放入站端口。一切都通过 TLS 出站运行。

  1. 01

    添加服务器

    在面板中注册主机,获得一行安装命令和一个短时效的注册令牌。

  2. 02

    运行安装脚本

    脚本检测操作系统与架构,将代理安装为服务,并通过 mTLS 注册。

  3. 03

    查看上报

    CPU、内存、磁盘与网络按节奏进来。每台主机获得实时健康分数。

  4. 04

    路由告警

    规则触发到邮件、Telegram、Slack 或 Webhook。暴力破解在代理上检测并即时标记。

03功能

控制台的全部能力

今日即有核心闭环,安全、磁盘与数据库以可插拔模块的方式设计其中。

01

实时指标

每台主机的 CPU、内存、磁盘与网络,作为时间序列存储,画成一眼可读的迷你曲线。

02

两级配置

全局模板设定默认值;每台服务器只覆盖需要的键。覆盖是级联,绝不分叉。

03

mTLS 接入

每个代理持有客户端证书。接入经双向认证,单凭泄露的令牌打不开任何东西。

04

暴力破解检测

代理在本地监视 RDP 与 SSH 认证,报告活跃攻击及其主要来源 IP。

05

健康评分

每台主机浓缩为一个 0-100 分数,数百台的服务器群会按需关注自动排序。

06

多渠道告警

邮件、Telegram、Slack 与 Webhook。添加渠道、发送测试,并把规则路由过去。

07

多租户团队

用户、团队与角色(查看者、操作员、管理员)把每位客户的服务器群隔离在同一登录之后。

08

跨平台代理

同一协议驱动 Linux 上的 systemd 单元与 Windows 服务,覆盖 amd64、arm64 与 386。

04价格

随服务器群扩展的价格

在一台服务器上免费开始。按主机数量付费,可选月付或年付。

Free

¥0/月
1 台服务器
适合单台主机或初尝控制台。
  • 1 台受监控服务器
  • 实时指标 + 健康分数
  • 邮件告警
  • 暴力破解检测
  • 团队角色

Solo

¥68/月
每服务器 / 月
适合少量生产主机。
  • 最多 5 台服务器
  • 全部指标序列
  • 邮件 + Telegram
  • 暴力破解检测
  • 团队角色

Team

最受欢迎
¥208/月
每月
适合有多名操作员的服务器群。
  • 最多 50 台服务器
  • 全部告警渠道
  • 暴力破解检测
  • 团队 + 角色
  • 配置模板

Business

¥688/月
每月
适合托管型与多租户运营方。
  • 无限服务器
  • 多租户隔离
  • 优先支持
  • 自托管选项
  • 审计日志

14 天 Pro 免费试用,无需绑卡

注册后即可监控全部服务器:指标历史、可用性与 API 检查、Telegram 通知和报告。到期不会扣费--账户回到 Free,单台服务器监控继续运行。

开始免费试用
05适用场景

一批服务器何时真正需要被监控

十五种情形:在这些情形下,不知道一台服务器正在做什么,不再是一个可以接受的风险。如果其中任何一种与您的机器群相符,那个缺口已经存在了--只是它还没让您付出代价。

fleetlast seen04:12nobody was told17 up1 unknown

何时需要对一批服务器做监控

第一组关乎那些没被看见的事。这些情形都不是失职:一旦机器的数量超过一个人能在脑子里记住的数量--对多数团队来说大约是四台--它们就会发生。

  1. 01

    一台主机安静了下来,直到用户打来电话才有人知道

    一台机器停止了上报。它可能被宿主机重启了,可能丢了路由,可能耗尽了内存,也可能只是被某个整理机柜的人关掉了电源。没有任何东西会宣布这件事:一台缺席的服务器不会产生错误,而沉默恰恰也是一台健康服务器所产生的东西。

    全部问题就在故障与那通电话之间的空档里。它通常以小时计,发现它的永远是最不该发现它的人,而到那时问题已经不是什么坏了,而是为什么没有人知道。

    • 一次宿主机迁移之后再也没回来的虚拟机
    • 在一次软件包升级之后悄无声息死掉的代理或服务
    • 夜里链路掉线的分支机构
    • 所有人都以为别人在盯着的那台机器
  2. 02

    凌晨三点磁盘写满,顺带把数据库一起带走

    磁盘写满是所有故障里最可预测的一种。日志在长,备份被写了两遍,临时表从来没被清理,而剩余空间的曲线已经指向同一个日期两个星期了。

    它同时也是恢复代价最高的一种故障,因为一个在写入途中耗尽空间的数据库,并不会礼貌地停下来。80% 告警和 100% 呼叫之间的差别,就是两分钟清理和从昨晚备份恢复之间的差别。

  3. 03

    某样东西劣化了几个星期,最后才真的坏掉

    内存泄漏、连接池耗尽、一天比一天排得更慢的队列、还有一个月到期的证书--这些都不是事件。它们是斜率,而斜率对一个只看当前数值的人来说是不可见的。

    没有历史就没有可比对的东西。“这台主机内存 70% 算正常吗”这个问题根本无法回答,除非有什么东西记录过正常是什么样子--而且那份记录必须在有人想到要问之前就已经在跑了。

  4. 04

    机器群里既有 Windows 又有 Linux,却没人有统一的视图

    多数真实环境都是混合的:几台 Windows 服务器跑着账务系统和文件共享,几台 Linux 机器跑着网站和数据库,远端站点或许还有一台 ARM 的什么东西。每个平台都有自己的原生工具,而它们彼此不说话。

    于是全局图景是手工拼出来的,拼在当班那个人的脑子里,材料是一个服务控制台、一个 SSH 会话和主机商的面板。而且只有当有人跑去看的时候才会拼--也就是在事情已经出问题之后。

    • 一边是事件查看器,一边是 journalctl,没有共同的时间轴
    • 同样的阈值在两个平台上意味着不同的事
    • 没人统一过的架构,因为它是长出来的,不是设计出来的
  5. 05

    机器同时分布在好几个地方

    办公室一台,主机商那儿两台,一朵云上三台,另一朵云上还有一台--因为一次没人做完的迁移,还有分支机构里一台在现任团队到岗之前就装好的机器。每一台都有自己的地址空间、自己的接入路径和自己的负责人。

    没有哪一个控制台能覆盖它们全部,因为它们从来不是作为一个整体买回来的。需要的是一个地方,无论每台机器物理上在哪儿,都把它们当成一个整体来对待。

db-01disk 96%email34chat61webhook88sms115four inboxes · one incidentalerts / week1 240read: few

当信号存在,却从未到达某个人

第二组关乎“它是可以被发现的”和“真的有人采取了行动”之间的距离。大多数造成损失的事件,其实自始至终都在日志里可见;失败发生在最后几米,在机器和活人之间。

  1. 06

    每个工具都有自己的收件箱,信号就此散开

    一个系统发邮件,另一个往聊天频道里发消息,第三个触发 Webhook,主机商发短信,而备份软件把报告放进一个自配置之后就再没人打开过的目录。

    什么都关联不起来。同一起事件在四个地方产生了四条名字各异的通知,而意识到它们其实是同一起事件的这份工作,落在了恰好正盯着正确窗口的那个人身上。

  2. 07

    告警疲劳:什么都在响,于是什么都不响

    一套没有调过的监控会持续不断地告警--夜间任务期间的 CPU 尖峰、一块每周都会越过同一条阈值线的磁盘、一个按设计重启的服务。人们很快就学会这些可以忽略,而且他们是对的--直到那一天他们不再是对的为止。

    一旦某个通道已经教会读它的人跳过它,再加告警只会更糟而不是更好。有用的度量不是发现了多少,而是有多少抵达了某个随后真的动手的人。

    • 被半个团队静音的聊天频道
    • 把告警归进没人看的目录的邮件规则
    • 后来才被发现的真实事件--就躺在那个它一直待着的频道里
  3. 08

    夜里、周末和长假期间没有人值班

    中小团队不排值班表。懂这些系统的人在睡觉、在飞机上或者在休假,而事件并不在乎这些。因此一切都必须让真正能联系上的人看得懂--包括一个什么都没参与建设的人。

    这就对告警必须写清什么提出了硬性要求。凌晨三点,“db-01 CPU 96%”对一个从没登录过 db-01 的人毫无意义;它和什么一起发生、正常又长什么样,才是能修好和打一圈电话之间的区别。

  4. 09

    逐台设置的阈值渐渐彼此对不上

    每台服务器都是手工配置的,在不同的时间、由不同的人、带着关于“什么才值得把人叫醒”的不同理解。两年之后没有任何两台机器是一致的,没人记得为什么这台是 85% 而那台是 95%,而要全改一遍就意味着要全跑一遍。

    一批机器需要的是另一种东西:一个能层层下发到各处的默认值,加上以“覆盖”形式清楚可见的按主机例外--这样偏差就是一个有人可以复核的有意决定,而不是历史的偶然。

  5. 10

    密码猜解要到几周后翻日志时才浮现

    一个暴露在外的 RDP 或 SSH 端口一直在被攻击,而一次猜中的密码,在日志里看起来几乎和一次正常登录一模一样。证据是有的--失败次数上升、陌生的来源、来自新国家的史上第一次成功登录--但它们只是某个没人每天读的文件里的几行。

    所以检测必须是机器在做的事,而不是人一个季度做一次的事。真正要紧的窗口是第一次尝试到第一次成功之间的那段时间,而它通常以小时计。

    • 没人画成曲线的登录失败尖峰
    • 发生在该账户从不使用的时间点上的成功登录
    • 同一个来源地址同时出现在好几台服务器上
30 days2 incidents · both reportedthis month99.7%availabilityexported · signed

当合同、审计或客户开口要记录

第三组关乎技术团队之外的某个人需要一个答案的时刻。可用率、事件历史和“确实有人在看着”的证据,要么以记录的形式存在,要么根本就不存在--事后是没法凭记忆重建的。

  1. 11

    SLA 或客户合同要求提供可用率证明

    一旦可用率被写进协议,它就不再是一种感觉,而成了一个必须按月拿出来、有争议时要能站得住、并且每次都要用同一种方法计算的数字。“据我们所知它一直在跑”不是测量。

    记录也在反方向保护您。多数可用率争议争的是一次故障该算谁的,而一条显示主机健康、同时客户自己的链路却断着的时间线,比任何辩解都更快地结束对话。

    • 欠客户的一份月度可用率数字
    • 由一条没人在测的阈值触发的违约条款
    • 需要精确到分钟的起止时间的一次事件
  2. 12

    审计人员或保险公司询问这些系统是如何被监管的

    网络安全保险的投保申请、供应商安全审查,以及关于支付数据和个人数据的监管框架,问的都是同一件事的不同版本:您凭什么知道系统正按预期运行,而当它们不再如此时,您又会怎么知道。

    对方要的不是一个工具的名字,而是证据:在受审期间监管是连续的,告警去到了有人会读的地方,事件被记录下来而不是被记在脑子里。

  3. 13

    一位管理员看着许多客户的服务器

    托管服务商、自由系统管理员和小型 IT 公司,手里握着分布在不同企业、不同服务商、不同网络结构中的数十台机器。每个客户都有自己的营业时间、自己对停机的容忍度,以及自己关于什么算紧急的理解。

    一台台手工配置扩展不了,等客户打电话来才发现问题同样扩展不了。这样一批机器需要的是一套到处适用的统一基线、在客户确实特殊之处按客户设置的例外,以及一面能一眼看全的墙。

  4. 14

    关于这批机器的一切,都只装在一个人的脑子里

    哪台机器要紧、它上面的正常负载长什么样、哪条告警可以放心忽略、那条阈值为什么在三月被调高--这些都没有写在任何地方。它们由把这一切搭起来的那个人携带着,并随着那个人一起离开。

    交接于是变成一场考古,新手接手后的头几个月都花在重新发现一年前本来清清楚楚的事情上。存在于人之外的历史与配置,是对此唯一的防御。

    • 一位同事离职,把每一项设置背后的理由一并带走
    • 一段假期,期间没人说得出某个数字是否反常
    • 在没有任何基线可比的情况下交给新服务商的一批机器
  5. 15

    看守这批机器的东西,会获得对它们全部的特权访问

    监管本身并非没有风险。任何能从您每一台机器上读取指标的东西,按定义就在您每一台机器上都有一个立足点--而且它可以从外部被访问,因为那正是它存在的意义。

    所以“这批机器是怎么被看守的”这个问题,同时也是关于那条通道的问题:谁可以和它对话、双方各自证明什么身份、传输中的数据会发生什么,以及一个被攻陷的控制台会不会把整批机器拱手让人。在任何东西被装到任何地方之前问清楚,是合情合理的。

06常见问题

问题解答

在生产服务器上运行安全吗?

在生产服务器上运行安全吗?

安全。代理只读取本地指标与自身的认证日志,并通过 TLS 出站连接。它不开放任何入站端口,也没有任何进攻能力。

同时支持 Windows 和 Linux 吗?

同时支持 Windows 和 Linux 吗?

支持。同一协议驱动 Linux 上的 systemd 单元与 Windows 服务,覆盖 amd64、arm64 与 386。安装脚本会为你检测平台。

接入如何保障安全?

接入如何保障安全?

每个代理以客户端证书注册,并通过双向 TLS 传输。被盗的注册令牌是短时效的,无法冒充已注册的主机。

两级配置如何运作?

两级配置如何运作?

全局模板只设一次。每台服务器覆盖单个键;覆盖是叠加在默认值之上而非替换,因此模板变更仍会触达每台主机。

可以自托管吗?

可以自托管吗?

可以。面板以 docker-compose 栈交付,置于 Traefik 之后,搭配 Postgres(TimescaleDB 可选)。参见仓库中的部署指南。

暴力破解检测覆盖哪些内容?

暴力破解检测覆盖哪些内容?

代理在本地监视 RDP 与 SSH 认证,因此能在数秒内标记出活跃攻击及其主要来源 IP,甚至早于面板刷新。

在用户调用之前检测不可用的服务器

我只知道当用户调用时某个虚拟机、服务或分支链接已停止。在迁移或升级后,主机可能会在一夜之间停止传输数据,而且我没有任何心跳和负责任的所有者。如何设置服务器可用性监控并在主机丢失后立即收到信号?

使用Servers Sentinel,我将代理安装为系统单元或 Windows 服务,将其与 mTLS 出站通道连接,并查看最新的遥测和主机运行状况评分。我为缺失数据设置规则,向邮件、Telegram、Slack 或 webhook 发送通知,并检查测试差距;我可以将一台服务器保留为带有电子邮件通知的免费套餐。

免费,无需Servers Sentinel 我运行 blackbox_exporter/Prometheus 或从另一个站点进行 ping/TCP cron 检查,存储 last_seen 并通过 Alertmanager 发送警报。我使用外部安全开关单独检查监控本身,设置正常重新启动的延迟并记录主机的所有者;否则,监控系统丢失显示为绿色状态。

在基座出现故障之前警告磁盘已满

在我的服务器上,日志、备份和临时表都在增长,晚上可用空间接近于零。尽管趋势已经持续数周,但底部可能会在历史记录中间停止;对于小批量和大批量来说,90% 的单一阈值是不够的。如何设置磁盘监控和容量预测?

使用Servers Sentinel,我将每个文件系统的已用空间和可用空间收集为时间序列,为特定卷设置一般阈值和单独的覆盖,并在临界值之前发送通知。我查看当前百分比旁边的增长率,检查 Linux 上的 inode,并为 WAL/log 和紧急操作留出足够的余量。

我使用 Prometheus 和 Alertmanager 免费安装 node_exporter/windows_exporter 或通过 cron/Task Scheduler 运行 df/Get-Volume。我同时按百分比和绝对千兆字节发出警告,添加 24-72 小时范围内的速率/预测线性,配置 logrotate/retention 并通过人为填充非关键卷来测试警报。

根据趋势识别缓慢的服务器降级

我看到 70% 的内存或不断增长的队列,但不知道这对于特定主机来说是否正常:内存泄漏、连接池和过期 TLS 证书恶化数周而没有一个明确的事件。当服务失败时,就没有基线。如何监控趋势并及早发现退化情况?

通过Servers Sentinel,我存储一系列 CPU、内存、磁盘和网络,将主机与其自身的历史记录进行比较,并将当前状态汇总为 0-100 分数。我设置了条件的持续时间,以免对一分钟的峰值做出反应,并在证书持续时间或应用程序响应很重要的情况下创建单独的正常运行时间/TLS/API 检查。

我免费部署 Prometheus、exporters 和 Grafana,设置基线记录规则和可持续增长警报,并使用 blackbox_exporter 检查证书。我存储至少几周的数据,在图表上标记部署/维护,并仅针对相关指标使用率/派生;我支持TSDB并自己规则。

Windows和Linux服务器统一监控

我的机群包括 Windows Server、各种发行版的 Linux 和 ARM 主机。现在我分别查看事件查看器、journalctl 和 hoster 面板,因此没有共同的时间尺度、相同的状态和单一的问题列表。如何在一个面板中组织跨平台服务器监控?

通过Servers Sentinel,我在 amd64、arm64 和 386 上使用 Windows 服务和 systemd 代理的一种协议,获得相同的基本指标和相同的运行状况评分。我在覆盖中保留平台差异,但按风险对整个队列进行排序,并将遥测数据传递给 mTLS,而无需打开代理的入站端口。

我免费将 windows_exporter 和 node_exporter 组合在一个 Prometheus 中,标准化主机/客户端/操作系统标签并构建一个通用的 Grafana 仪表板。我按 UTC 映射 Windows 事件转发和 syslog/Loki,将操作系统的不同阈值描述为代码,并检查更新导出器是否不会在不迁移规则的情况下更改指标名称。

办公室、云端和分支机构的服务器监控

我的服务器分布在办公室、两个云、一个主机和一个分支机构之间,位于 NAT 之后,并且没有公共寻址。我不想在每台主机上打开传入端口,但我确实希望获得可用性和资源的单一视图,无论站点如何。如何集中监控分布式服务器?

对于Servers Sentinel,我在每台主机上安装一个代理;它自行发起传出连接并由 mTLS 客户端证书进行身份验证。我分配站点和所有者标签,在一个控制台中查看所有主机,并通过逐点覆盖全局设置规则,而无需构建到每台计算机的传入路由。

我免费使用中央 Prometheus 连接 WireGuard 站点和轮询导出器,或使用从外部发送指标的 Remote_write/agents。我将 ACL 仅限制为收集器地址,使用 TLS 证书进行保护,在损坏时缓冲数据,并监控 VPN 本身;我自己负责网络设计和密钥轮换。

整合不同的通知渠道

我的情况是:一个系统发送电子邮件,另一个系统写入 Telegram,第三个系统调用 Webhook,托管服务商发送短信;同一事件以不同的名称出现,没有人明白哪一条信息才是主要信息。如何集中监控通知并将警报与特定服务器和规则关联?

借助Servers Sentinel,我可以在一个控制台中创建电子邮件、Telegram、Slack 或 Webhook 通道,发送测试并根据所需的主机向它们发送规则。我使用单个名称和主机上下文,以便操作员看到指标、阈值和时间,而不是从四个独立的字母收集事件。

我免费将 Prometheus Alertmanager 路由到一个通知网关,设置 group_by、group_wait、repeat_interval 和抑制,并为源留下指向一个 Runbook 的链接。我对标签严重性/服务/所有者进行标准化,并使用测试警报检查路线;即使使用免费软件,短信和外部提供商仍可能需要付费。

减少警觉疲劳

我的监控会提醒我每一次短暂的 CPU 峰值、计划的重新启动以及每晚超过相同阈值的驱动器。该团队已禁用该频道,因此实际事件也仍未被了解。如何减少警报疲劳并只留下可操作的警报?

使用Servers Sentinel,我为标准不同的主机设置全局阈值、条件持续时间和点例外,然后将严重性级别路由到不同的通道。我使用运行状况评分来确定优先级、测试规则并查看尚未采取行动的警报。

我免费维护一个由所有者和运行手册组成的警报目录,在 Prometheus 中使用,在 Alertmanager 中进行分组和抑制,并通过自动完成以静默方式关闭预定工作。我测量通知、确认和重试的数量,删除不可操作的信号,并且不通过简单地提高所有阈值来掩盖噪音。

晚上没有值班时发出警报

我有一个小团队,没有 24/7 待命:晚上有一个人可以待命,但他没有搭建服务器,也不知道“db-01 CPU 96%”是什么意思。我需要带有上下文和可理解的操作的关键信号到达,并且需要等到早上才收到非关键信号。如何设置夜间监控警报?

使用Servers Sentinel,我将严重性和通道分开,将角色/客户端附加到主机名,并且仅在持续违规后配置规则。我通过测试检查消息,在收件人 Webhook 中留下运行手册的链接,并使用指标图/运行状况评估,以便值班人员可以区分一次性峰值和降级。

我免费构建一个 Alertmanager 路由计划,通过可用网关将关键事件发送到呼叫/聊天,并将其余事件发送到每日队列。我编写了包含三个操作、所有者和升级标准的操作手册,添加仪表板链接并定期发出培训警报;免费通话渠道取决于所选服务。

统一监控阈值(按主机划分例外)

我的服务器是由不同的人设置的:磁盘警告为 80%、85% 或 95%,并且任何地方都没有写下原因。我想更改一次基本阈值,但要注意数据库、文件服务器和小型系统分区的例外情况。如何管理监控模式而不发生偏差?

通过Servers Sentinel,我设置了一个全局配置模板,并且在特定服务器上我仅覆盖所需的密钥;覆盖级联在默认值之上,而不是复制整个配置。我将偏差视为例外,更改总体阈值一次并检查哪些主机故意保持不同的值。

我免费将 Prometheus 规则和库存参数存储在 Git 中,生成 Jsonnet/Ansible 规则,并要求进行审查,并说明异常的原因和截止日期。我运行 CI 语法检查、部署配置的差异以及覆盖报告;如果没有这样的纪律,即使是自由堆栈也会很快恢复为手动漂移。

通过 RDP 和 SSH 即时检测暴力破解

当我每周查看安全事件日志和 auth.log 时,我只发现密码猜测。此时,从第一批失败到最终成功登录,已经过去了几个小时,一个 IP 可以攻击多个服务器。当攻击开始时,如何通知 RDP/SSH 暴力攻击?

通过Servers Sentinel,我启用本地身份验证检测:Windows 或 Linux 上的代理读取 RDP/SSH 事件并使用顶级 IP 源传输主动攻击。我将规则路由到直播频道并在主机之间匹配一个源;符合条件的付费或试用计划提供检测功能。

我免费收集 Wazuh/Elastic 或 Loki 中的 Windows 4625 和 sshd 失败密码,通过 source_ip 创建滑动窗口的关联,并为后续成功的 4624/Accepted 创建警报。我通过 NTP 同步时间、标准化 IPv4/IPv6 并排除测试扫描仪;自由路径需要单独的收集器和规则支持。

按维度计算可用性和 SLA

在与客户的合同中,我写下了SLA,例如每月99.9%,但现在可用性是通过感觉和电话来评估的。对于争议,我们需要每次停机的开始、结束和原因,排除商定的工作和单一公式。如何组织正常运行时间监控和 SLA 报告?

通过Servers Sentinel,我从外部点创建 TCP/TLS/API 检查,存储结果历史记录,并将应用程序不可用与缺少代理遥测分开。我设置 SLO,记录维护并生成有时间限制的定期报告;签字前与客户约定检查间隔、检查区域及排除规则。

我免费在受控站点之外部署 blackbox_exporter 和 Prometheus,将可用性视为成功探测/预期探测并存储 Alertmanager 事件。我在单独的日志中记录维护,同步 UTC 并生成 Grafana 报告;一个验证点并不能证明全局可用性,因此如有必要,我会添加一个独立的探测器。

持续监控审计的证据

审计员、保险公司或客户询问我如何知道系统在整个期间受到监控、谁收到了警报以及哪些事件已关闭。仅当前的绿色仪表板还不够,因为它无法确认上个月的情况。如何准备持续服务器监控的证据?

通过Servers Sentinel,我可以保存指标、正常运行时间检查、规则设置、通道和事件的历史记录,并使用审核日志来查看适当计划上的所有者和策略更改。我上传准确时间段的报告,附上交付测试并解释代理的 mTLS 身份;我注意到数据的缺乏是观察中的一个空白,而不是常态。

我将 Prometheus/Loki/Wazuh 免费存储在安全服务器上,并在 Git 中进行备份、配置和批准,并将事件存储在票证系统中。我每月记录覆盖范围、差距、警报测试和例外情况列表,签署报告并限制访问;没有关闭程序的工具本身并不是控制的证据。

一名管理员监控多个客户的服务器

作为 MSP 或新任管理员,我监控不同公司、提供商和网络的服务器。客户有不同的工作时间、阈值和联系人,但我想要一个问题队列,而不混合数据和访问权限。如何组织多租户服务器监控?

借助Servers Sentinel,我按团队/租户拆分机群,分配查看者、操作员和管理员角色,并应用基本模板(客户端例外)。我按健康评分对所有主机进行排序,向所有者发送通知,并在需要隔离和无限机队的情况下使用业务/自托管选项。

我免费部署单独的 Prometheus 租户/实例,或者在 Grafana 中使用严格的标签和 ACL 隔离数据,将客户端机密存储在不同的保管库中。我从清单生成配置,按租户/所有者路由 Alertmanager,并测试阻止交叉访问;安全多租户比一个共享仪表板需要更多的工作。

保持有关公园规范和设置的知识

我的情况是:有关哪台服务器重要、什么负载正常以及阈值为何更改的所有信息都在一名管理员的头脑中。当休假或解雇时,新人看到的数字没有上下文,不知道哪个偏差是危险的。如何将监控历史记录转化为可转移的操作文档?

使用Servers Sentinel,我可以按角色和所有者对主机进行签名,存储指标系列、全局模板和显式覆盖,并将通道与所有者相关联。我使用历史记录作为基线,在变更流程旁边记录非标准阈值的原因,并在转移权限之前为新操作员授予仅查看角色。

我免费在 Git 中维护清单和操作手册,为每个覆盖添加仪表板链接、所有者、依赖项和理由,并通过拉取请求接受更改。我将 Grafana/Prometheus 配置存储为代码,标记部署/维护,并将事件转移给另一名员工,每季度一次;如果没有组织实践,图形本身就无法保留知识。

具有最小权限的安全监控代理

据我了解,监控代理位于每台服务器上,并成为信任链的一部分。我不想打开传入端口、传递持久注册令牌或让云面板能够在整个队列中执行任意命令。如何评估和安全部署监控代理?

对于Servers Sentinel,我使用双向 TLS 出站连接:每个代理都会收到客户端证书,并且短期连接令牌不会替换已颁发的身份。我检查服务权限、收集的指标和日志列表,禁用不必要的操作,在一台主机上部署试点,并在删除服务器时控制证书的吊销。

免费地,我在单独的非特权帐户下安装node_exporter/windows_exporter,仅监听localhost/VPN并限制收集器集。我使用 TLS/mTLS 或网络 ACL 保护抓取、签署数据包、提交版本、扫描更新,并且不启用从不受信任的来源写入的文本文件脚本;我将配置管理与监控分开。

07信任

谁在开发、你付款给谁,以及代理程序能在你的服务器群里做什么

在生产服务器群中以管理员权限部署任何东西之前,这三个问题值得先有答案。

01

谁在开发

Servers Sentinel 由 Recovery Toolbox 首席服务器安全专家 Victor G. Bobrov 编写:20 多年系统开发与安全经验,持有 Microsoft MCSD/MCDBA 认证。健康评分、告警规则以及本站的文档都是他的工作,以本人署名发布,而不是匿名品牌。 文档 →

02

你付款给谁

供应商是在保加利亚(欧盟)注册的 File Master LLC:Bulstat/VAT 180842207,办公室位于瓦尔纳,可通过电话与邮件联系。付款由 PayPro Global 作为登记商户处理;服务条款、隐私政策和数据处理协议均全文公开,而非概要。 服务条款 · 隐私 · DPA

03

代理程序能做什么、不能做什么

代理程序读取本地指标和所在主机自己的认证日志,并通过双向 TLS 向外发送。它不开放任何入站端口,也没有远程命令通道:外部无法指使它在你的服务器上执行任何东西。每个代理都用客户端证书注册,注册令牌是短期的 —— 即使被窃取,也无法冒充已注册的主机。面板本身以 docker-compose 栈的形式提供,可以运行在你自己的硬件上。 安装代理 →

Recovery Toolbox / File Master LLC

联系 Recovery Toolbox

Recovery Toolbox 与 File Master LLC 的联系方式,以及公司首席安全专家 Victor G. Bobrov 的简介。

公司办公室

File Master LLC 是 Recovery Toolbox 在线服务和软件产品背后的法律实体。

File Master LLC
Serena app., office C13
Golden Sands, Varna, 9007
保加利亚,欧盟
Bulstat/增值税
180842207

关于 Recovery Toolbox

File Master LLC 开发并维护 Recovery Toolbox 的在线服务和软件产品,用于修复损坏的文件、数据库和邮件存储格式。公司专注于为需要恢复损坏数据访问权限的用户、IT 专业人员和企业提供实用的恢复工具。

欢迎您的意见和建议。请通过电子邮件向我们发送对网站的反馈: webmaster@recoverytoolbox.com

Victor G. Bobrov, server security specialist and author of Servers Sentinel
安全专家

Victor G. Bobrov

服务器安全专家 · 20 多年系统开发与安全经验

Victor G. Bobrov 在 File Master LLC / Recovery Toolbox 负责安全研发。他定义了 Servers Sentinel 在服务器群中监视的内容:由主机指标得出的健康评分、认证日志中的暴力破解活动、相对 CIS 基线的配置漂移,以及必须在管理员察觉异常之前触发的告警。

  • 服务器群监控
  • 服务器加固与 CIS
  • 告警与事件响应
  • MCSD
  • MCDBA

Microsoft 认证

Microsoft Certified Solutions Developer - MCSD。Microsoft Certified Database Administrator - MCDBA。

MCSD MCDBA

让 Servers Sentinel 对准你的第一台服务器

添加主机,运行一行命令,一分钟内即可看到上报。首台服务器免费。