Runbook は手順書ではなく判断の入口である – アラート、ダッシュボード、ログを対応へつなぐ 作者: si62512548投稿日: 2026年7月22日カテゴリー: 監視タグ: Alertmanager, Grafana, Loki, Prometheus, Runbook, SRE, アラート, 監視, 監視設計, 運用設計, 障害対応Runbook は手順書ではなく判断の入口である – アラート、ダッシュボード、ログを対応へつなぐ へのコメントはまだありません Runbook は固定手順を並べるだけの文書ではなく、アラート通知を受けた人が影響範囲、原因候補、確認画面、ログ、エスカレーション条件へ進むための入口です。Prometheus、Alertmanager、Grafana、Loki と Runbook の関係を整理します。
Alertmanager の通知設計 – ルーティング、抑制、沈黙、責任分界を分ける 作者: si62512548投稿日: 2026年7月22日カテゴリー: 監視タグ: Alertmanager, Grafana, Prometheus, SLO, SRE, アラート, 監視, 監視設計, 運用設計Alertmanager の通知設計 – ルーティング、抑制、沈黙、責任分界を分ける へのコメントはまだありません Alertmanager はアラートを発火させる場所ではなく、通知の束ね方、宛先、抑制、沈黙、エスカレーションを設計する場所です。Prometheus の alert rule と Alertmanager の役割を分け、通知疲れを避けるための設計観点を整理します。
Grafana ダッシュボードはグラフを並べる場所ではない – 運用判断の順番を設計する 作者: si62512548投稿日: 2026年7月22日カテゴリー: 監視タグ: Grafana, LogQL, Loki, ModSecurity, Observability, Prometheus, ダッシュボード, ログ設計, 監視, 運用設計Grafana ダッシュボードはグラフを並べる場所ではない – 運用判断の順番を設計する へのコメントはまだありません Grafana ダッシュボードを、グラフの置き場ではなく、異常検知、分類、絞り込み、詳細確認へ進む運用判断の順番として設計する考え方を整理します。
Loki のラベルに何を入れるべきか – 検索性とカーディナリティの境界 作者: si62512548投稿日: 2026年7月22日カテゴリー: 監視タグ: Ceph, Grafana, Grafana Alloy, LogQL, Loki, ModSecurity, Observability, カーディナリティ, ログ設計, 監視Loki のラベルに何を入れるべきか – 検索性とカーディナリティの境界 へのコメントはまだありません Loki のラベルに source、job、host、filename のどこまでを入れるべきか、ModSecurity audit log、network syslog、Ubuntu journal、Ceph ログを例に整理します。
ピーク時間帯と定期処理を混ぜない – 業務時間、バッチ、バックアップ、障害対応で考える運用設計 作者: si62512548投稿日: 2026年7月17日カテゴリー: 設計・運用タグ: バックアップ, バッチ処理, 変更管理, 監視, 運用設計, 障害対応ピーク時間帯と定期処理を混ぜない – 業務時間、バッチ、バックアップ、障害対応で考える運用設計 へのコメントはまだありません 業務ピーク、夜間バッチ、バックアップ、メンテナンス、障害対応を同じ運用時間として扱わず、時間帯ごとの前提から運用設計を整理します。
リソース上限を倍率だけで考えない – CPU、メモリ、同時接続数、障害時の余白で見る 作者: si62512548投稿日: 2026年7月17日カテゴリー: 設計・運用タグ: CPU, SRE, キャパシティ管理, メモリ, リソース設計, 監視リソース上限を倍率だけで考えない – CPU、メモリ、同時接続数、障害時の余白で見る へのコメントはまだありません CPU、メモリ、同時接続数、キュー、障害時の余力を分け、リソース上限を単純な倍率ではなく影響範囲として設計する考え方を整理します。
Prometheus と Loki は何が違うのか – メトリクス、ログ、トレース、アラートの役割を分ける 作者: si62512548投稿日: 2026年7月17日カテゴリー: 監視タグ: SLO, オブザーバビリティ, トレース, メトリクス, ログ, 監視Prometheus と Loki は何が違うのか – メトリクス、ログ、トレース、アラートの役割を分ける へのコメントはまだありません Prometheus は状態と傾向を継続的に見るためのもの、Loki は出来事と理由を読むためのものです。メトリクス、ログ、トレース、外形監視、アラート、SLO の役割を分けて整理します。
Ubuntu 26.04 smartctl exporter の基本設定 – Prometheus でディスク SMART メトリクスを収集する 作者: si62512548投稿日: 2026年7月11日カテゴリー: Ubuntuタグ: Exporter, Prometheus, Ubuntu 26.04, Ubuntu Server, 監視, 監視設計Ubuntu 26.04 smartctl exporter の基本設定 – Prometheus でディスク SMART メトリクスを収集する へのコメントはまだありません Ubuntu 26.04 の物理ホストで smartctl exporter を使い、S.M.A.R.T. 情報を Prometheus メトリクスとして収集します。smartd との役割分担、/metrics 確認、scrape 設計、通知責任を確認します。
Ubuntu 26.04 smartd の基本設定 – S.M.A.R.T. で物理ディスクを監視する 作者: si62512548投稿日: 2026年7月11日カテゴリー: Ubuntuタグ: Ansible, journald, systemd, Ubuntu 26.04, Ubuntu Server, ストレージ, 監視, 監視設計Ubuntu 26.04 smartd の基本設定 – S.M.A.R.T. で物理ディスクを監視する へのコメントはまだありません Ubuntu 26.04 の物理ホストで smartd と smartmontools を使い、S.M.A.R.T. 状態を継続監視します。ConditionVirtualization、smartd.conf、DEVICESCAN、journald 記録、Ansible 管理の判断点を確認します。
Kubernetes kube-state-metrics の基本 – オブジェクト状態を監視に渡す 作者: si62512548投稿日: 2026年7月8日カテゴリー: Kubernetesタグ: Kubernetes, Prometheus, PVC, メトリクス, 監視, 監視設計Kubernetes kube-state-metrics の基本 – オブジェクト状態を監視に渡す へのコメントはまだありません kube-state-metrics を、CPU やメモリ使用量ではなく Kubernetes API のオブジェクト状態を Prometheus へ渡す部品として扱い、Deployment、Pod、PVC、Node、Job の状態監視とアラート設計を確認します。
