记得那是去年在香港机房值班的一个夜里，凌晨两点，我正准备打盹，电话突然响起。电话那头，客户语气很急：“为什么我们Windows节点上的服务状态看不到？Linux日志正常收集，但Windows全是空白。”
这一瞬间，我彻底清醒了。跨系统混合集群的监控问题，一直是我们团队头疼的难题。不同系统、不同协议、不同的日志标准……想要统一在一张大屏上实时展示，远比在PPT里讲的要复杂得多。那一夜开始，我下定决心要解决香港机房里这个跨系统可视化的顽疾。

一、混合集群的现实场景

在香港的数据中心，我们的环境大致是这样的：

在这样的环境下，传统的单系统监控（比如Zabbix只管Linux，Nagios外挂Windows插件）已经不够用了。客户需要的是一张统一的可视化大屏，能在 Grafana 或 Kibana 里直观看到每个节点的 CPU、内存、服务状态、日志趋势，不论是Windows还是Linux。

二、技术选型与架构设计

我没有直接去堆工具，而是先画了一张架构草图，明确几个核心问题：

采集层统一：

Linux 节点 → Prometheus Node Exporter

Windows 节点 → wmi_exporter（现在叫 windows_exporter）

日志层统一：

统一用 Filebeat 采集日志，不管是 Windows Event Log 还是 Linux syslog，全部送到 Elasticsearch。

监控存储与分析：

指标数据走 Prometheus + Alertmanager。

日志数据走 ELK Stack。

可视化大屏：

Grafana 做性能指标展示。

Kibana 做日志搜索和可视化。

最终架构如下：

Windows/Linux 节点 → Exporter/Filebeat → Prometheus/Elasticsearch → Grafana/Kibana → 大屏展示

三、部署过程中的实操细节

1. Windows 端监控部署

我先在一台 Windows Server 上安装 windows_exporter：

# 下载并安装
Invoke-WebRequest -Uri https://github.com/prometheus-community/windows_exporter/releases/download/v0.16.0/windows_exporter-0.16.0-amd64.exe -OutFile windows_exporter.exe

# 安装为服务
.\windows_exporter.exe --install --collector.cpu --collector.memory --collector.logical_disk --collector.net

启动后，访问 http://server-ip:9182/metrics 就能看到一堆指标。坑在这里：Windows防火墙默认拦截9182端口，我第一次采集时Prometheus报错“connection refused”，现场花了半小时排查，最后在 PowerShell 里加了一条规则才解决：

New-NetFirewallRule -DisplayName "Prometheus Exporter" -Direction Inbound -Protocol TCP -LocalPort 9182 -Action Allow

2. Linux 端监控部署

Linux上熟悉很多，直接安装 node_exporter：

wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar -xzf node_exporter-*.tar.gz
cd node_exporter-1.6.0.linux-amd64

# 启动为 systemd 服务
cat <<EOF >/etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target

[Service]
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now node_exporter

端口是 9100，记得在防火墙上放行。

3. Prometheus 配置

在 Prometheus 的 prometheus.yml 里加上两个 job：

scrape_configs:
  - job_name: 'windows'
    static_configs:
      - targets: ['192.168.1.21:9182','192.168.1.22:9182']

  - job_name: 'linux'
    static_configs:
      - targets: ['192.168.1.31:9100','192.168.1.32:9100']

保存后重启 Prometheus，就能统一采集两类指标。

4. 日志统一（Filebeat）

Windows 用 Filebeat 收集事件日志：

filebeat.inputs:
  - type: winlog
    event_logs:
      - name: Application
      - name: System

Linux 用 Filebeat 收集 syslog：

filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/*.log

两边的日志统一送到 Elasticsearch，后续在 Kibana 里做索引。

四、遇到的坑与解决过程

Windows 采集不全：

默认的 windows_exporter 并不会收集 IIS 请求数，我当时客户死活要看 IIS QPS，只能启用 iis collector。但这个模块需要 IIS 管理扩展，装好后才有数据。

跨系统时间戳不一致：

Windows 用的是本地时区，Linux 默认 UTC，导致 Grafana 里曲线错位。最后在所有节点上统一 NTP，并强制 Prometheus 使用 UTC 时间。

日志量过大：

Windows Event Log 一晚上就能爆 20GB，如果直接丢 Elasticsearch 会把集群拖死。我在 Filebeat 加了筛选，只保留 Error 和 Warning 级别，剩下的 archive 到 NAS。

五、最终成果与大屏展示

经过两周折腾，最终在 Grafana 大屏上，我们能同时看到：

• Windows/Linux 节点的 CPU、内存、磁盘、网络趋势。
• IIS 与 Nginx 的请求量曲线对比。
• 数据库主从延迟、Redis QPS 实时监控。
• 日志错误趋势与关键事件告警。

一张大屏，解决了客户最关心的 “跨系统统一监控与可视化” 难题。

六、Grafana 大屏配置示例（JSON导出片段）

在 Grafana 上配置好面板后，我把它导出成 JSON，这样同事在别的环境里也能快速复用。下面是一个简化版的片段（实际 JSON 很长，这里只放重点部分）：

{
  "title": "Windows & Linux Cluster Monitoring",
  "timezone": "utc",
  "panels": [
    {
      "type": "graph",
      "title": "CPU Usage",
      "targets": [
        {
          "expr": "100 - (avg by (instance) (irate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)",
          "legendFormat": "{{instance}}"
        }
      ],
      "yaxes": [
        {
          "format": "percent",
          "min": 0,
          "max": 100
        }
      ]
    },
    {
      "type": "graph",
      "title": "Memory Usage",
      "targets": [
        {
          "expr": "(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100",
          "legendFormat": "{{instance}}"
        }
      ],
      "yaxes": [
        {
          "format": "percent",
          "min": 0,
          "max": 100
        }
      ]
    },
    {
      "type": "graph",
      "title": "IIS Requests (Windows)",
      "targets": [
        {
          "expr": "rate(windows_iis_requests_total[5m])",
          "legendFormat": "{{instance}}"
        }
      ]
    },
    {
      "type": "graph",
      "title": "Nginx Requests (Linux)",
      "targets": [
        {
          "expr": "rate(nginx_http_requests_total[5m])",
          "legendFormat": "{{instance}}"
        }
      ]
    }
  ]
}

在这份配置里，我重点展示了几个常见的监控项：

• CPU 使用率（跨 Windows/Linux 一致计算方式）
• 内存占用（使用可用内存和总内存计算百分比）
• IIS 请求曲线（通过 windows_exporter 的 IIS Collector 提供）
• Nginx 请求曲线（通过 nginx_exporter 或 log-based metrics 提供）

在香港机房的大屏上，这些图表左右分列，清晰地对比了两类系统的运行状态。

七、Prometheus 告警规则示例

光有大屏还不够，夜深人静的时候没人盯着屏幕，告警才是运维的最后防线。我在 Prometheus 里配置了几条告警规则，并用 Alertmanager 推送到钉钉/Slack。

以下是部分示例：

groups:
- name: windows-linux-alerts
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "High CPU usage on {{ $labels.instance }}"
      description: "CPU usage > 90% for more than 5 minutes."

  - alert: LowMemoryAvailable
    expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Low memory on {{ $labels.instance }}"
      description: "Available memory < 10%."

  - alert: IISDown
    expr: rate(windows_iis_requests_total[5m]) == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "IIS service down on {{ $labels.instance }}"
      description: "No IIS requests detected in last 2 minutes."

  - alert: NginxHighErrorRate
    expr: (rate(nginx_http_requests_total{status=~"5.."}[5m]) / rate(nginx_http_requests_total[5m])) > 0.1
    for: 3m
    labels:
      severity: critical
    annotations:
      summary: "Nginx 5xx error rate too high on {{ $labels.instance }}"
      description: "More than 10% of requests are failing with 5xx errors."

这几条规则覆盖了：

• CPU高占用（Windows/Linux通用）
• 内存不足
• IIS无请求（可能服务挂了）
• Nginx 5xx 错误率过高

当这些触发时，Alertmanager 会第一时间把告警推到运维群，我在凌晨接电话的次数也随之锐减。

八、现场的收尾与感受

记得第一次在 Grafana 上看到 IIS 与 Nginx 请求曲线并列的那一刻，我心里是真的松了一口气。那晚我跟同事调侃：“以后谁再说 Windows 和 Linux 是两套世界，我就拉他到机房看这张大屏。”

后来每当客户参观香港机房，我都会特意带他们看这套监控体系，不是炫耀，而是想告诉他们：跨系统的运维，其实也能做到真正的统一和可视化。