対象:自宅PC(Windows 10/11)
前回:Alloy → Prometheus → Grafana で OS メトリクスが見えた
今回:**「身近な困りごと」**に寄せて監視を楽しくする(=続く)
この記事でやること(ゴール)
- 「CPUグラフは出た。でも…」から一歩進めて、以下を可視化する
- プロセス監視(VSCode/Chrome/Docker Desktop など “落ちたら困る”)
- サービス監視(Docker など “止まってたら困る”)
- ネットワークの詰まり(回線が変な時に気づける)
- (おまけ)Windowsイベントログ を Loki に流して “ログも触る”
※ログは Prometheus ではなく Loki が得意です。Alloyは Windows Event Log を読む
loki.source.windowseventを持っています。
ただし、今回は「最小で体験」したいので “おまけ扱い” にします。
1) Alloy(メトリクス)側:プロセス監視を追加する
1.1 process collector を有効化する(重要)
windows_exporter の process collector は、環境によってはデフォルトで無効です。
そのため Alloy 側の enabled_collectors に process を足します。
%PROGRAMFILES%\GrafanaLabs\Alloy\config.alloy の prometheus.exporter.windows を次のように変更:
prometheus.exporter.windows "selfpc" {
enabled_collectors = [
"cpu", "logical_disk", "net", "os", "service", "system",
"memory", "cs",
"process",
]
// 例:プロセス名を絞る(メトリクス爆発を防ぐ)
// Windowsはプロセス名にバリエーションが出やすいので正規表現で寄せるのが楽
process {
include = "(Code|chrome|Docker Desktop).*"
}
}
Alloyサービス再起動を忘れずに。
1.2 “落ちてないか” の確認クエリ(PromQL)
Grafana Explore で次を打ちます。
VSCode / Chrome / Docker Desktop の “存在チェック”
count by (process) (windows_process_info{process=~"Code|chrome|Docker Desktop"})
- 0 になったら「そのプロセスは存在しない」
- “落ちた/起動してない” が見える
プロセスのメトリクスは量が増えやすいので、「includeで絞る」がコツです。
2) サービス監視:Docker(例)が動いてるか
service collector は windows_service_state を出します。
状態ごとに 1/0 を持つので、「runningが0」で落ちてる判定ができます。
Dockerのサービス例(環境により名前が違うので注意)
windows_service_state{name="com.docker.service", state="running"} == 0
サービス名は Windows のサービス一覧(services.msc)で確認できます。
まずはwindows_service_stateを Explore で眺めて “それっぽいname” を探すのが早いです。
3) ネットワーク:回線が詰まってないか
ネットワークは「上り/下りが張り付き」「大量転送が続く」などで体感に直結します。
送受信(bytes/sec)
sum by (instance) (rate(windows_net_bytes_total[2m]))
受信だけ(bytes/sec)
sum by (instance) (rate(windows_net_bytes_received_total[2m]))
送信だけ(bytes/sec)
sum by (instance) (rate(windows_net_bytes_sent_total[2m]))
4) (おまけ)Windowsイベントログを Loki に送って “ログも触る”
4.1 追加コンテナ:Loki を docker-compose に入れる
docker-compose.yml を次のように増やします(既存はそのまま)。
loki:
image: grafana/loki:latest
container_name: loki
command: -config.file=/etc/loki/local-config.yaml
ports:
- "3100:3100"
起動し直し:
docker compose up -d
4.2 Grafanaに Loki データソースを追加(Provisioning)
grafana/provisioning/datasources/datasource.yml をこうします(Prometheusは既存のまま、追記):
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: http://prometheus:9090
isDefault: true
- name: Loki
type: loki
access: proxy
url: http://loki:3100
Grafana を再起動:
docker restart grafana
4.3 Alloy に Windows Event Log の収集を追加
Alloyは loki.source.windowsevent で Windowsイベントログを読めます。
config.alloy に以下を追記(メトリクス部分はそのまま):
// ---- Windows Event Log → Loki ----
loki.source.windowsevent "application" {
eventlog_name = "Application"
forward_to = [loki.write.local.receiver]
}
loki.source.windowsevent "system" {
eventlog_name = "System"
forward_to = [loki.write.local.receiver]
}
loki.write "local" {
endpoint {
url = "http://localhost:3100/loki/api/v1/push"
}
}
Alloyサービス再起動。
4.4 Grafanaでログを見る
Grafana → Explore → データソースを Loki にして、例:
ここまで来ると「メトリクス(Prometheus)+ログ(Loki)」の入り口が揃います。
5) “自分向け”ダッシュボードの作り方(おすすめの型)
- まずは 1画面に4つだけ置く(増やしすぎない)
- CPU使用率
- メモリ空き
- ディスク使用率(C:)
- “落ちたら困るプロセス”の存在数(count)
- 「困った時だけ見る」から「眺めると気づける」へ
次回予告(第3回)
第3回は 通知で完成です。
- Grafana Alerting の Contact point / Notification policy
- “うるさくない”ための設計(for、まとめ方、夜は黙る)
- 例:ディスク逼迫、Docker停止、ネットワーク張り付き
- (おまけ)イベントログのエラー増加を検知
参考
Windowsイベントログを読む(loki.source.windowsevent)
https://grafana.com/docs/alloy/latest/reference/components/loki/loki.source.windowsevent/
AlloyでWindowsを監視する(メトリクス&イベントログ)
https://grafana.com/docs/alloy/latest/monitor/monitor-windows/
loki.write(Lokiへ送る)
https://grafana.com/docs/alloy/latest/reference/components/loki/loki.write/







