オブザーバビリティ

前回の記事で「Apprise + 自作 Web サービスで OnCall 相当を組む」例を示しました。この記事ではよくある誤解を整理し、シフト管理を含めた自作 OnCall スタックの現実的な選択肢を深掘りします。 まずは Apprise の正しい位置付けを確認 Apprise は名前から「シフト管理ができそう」と誤解されがちですが、実際の役割は明確に分かれています。 正しい位置付け: Apprise は 「通知の超便利ハブ」 — 1 つのコードで Slack / メール / SMS / LINE / Telegram など 100 種類以上の通知先に統一インタフェースで送る シフト管理機能（カレンダー、ローテーション、当番判定）は持たない 「シフト管理に Apprise を使う」とは、シフトロジックは別のライブラリ / DB / カレンダーで持ち、通知配信だけ Apprise に任せるという意味 つまり Apprise は「組んだシフトを確実に届ける道具」であり、「シフトを組む道具」ではありません。前回記事のコード例で get_policy_for_now() を Python で書いていたのは、まさにこの「シフト判定ロジックを自作」の実装です。 シフト管理を「自作する場合」に組み合わせる Python ライブラリ シフトロジックを自分で書くなら、以下のライブラリが Apprise と相性が良い。 1. PyShift（point85/PyShift） — 古典的なシフトローテ point85/PyShift は、Java 版の Shift ライブラリを Python に移植したもの。PyPI では PyWorkShift として配布されています。 ...

前回の記事で「サーバー監視の王道スタック」として Prometheus + Loki + Grafana + Alloy を整理しました。アラート設計のセクションで触れた Grafana OnCall について、改めて単独で深掘りします。 ただし重要な注意点があります — Grafana OnCall OSS（grafana/oncall リポジトリ）は 2026 年 3 月 24 日にアーカイブされました。後継は **Grafana Cloud IRM（Incident Response Management）**で、OnCall と Incident の両アプリが 1 つに統合されています。 「Grafana OnCall を新規導入したい」「既存環境を移行すべきか」という人に向けて、何が終わって、何が始まったのかを整理します。 Grafana OnCall とは何だったのか Grafana OnCall は 「アラートが鳴った後の対応フロー」を管理するツールでした。 Prometheus / Loki / Grafana が「異常を検知する」までを担当 Grafana OnCall は「鳴ったアラートを誰に・どうやって届け、どう対応するか」を管理 PagerDuty や Opsgenie の OSS 互換ツールとして、Grafana エコシステムの中で重要なポジションを占めていました。 主な機能（当時） アラートの集約とルーティング — 複数の監視システムからのアラートを統合、内容に応じてチームへ振り分け オンコールシフト管理 — 担当者のカレンダー（シフト表）に従って当番者にだけ通知 エスカレーションポリシー — 一定時間応答がなければ次の担当者へ自動エスカレーション ChatOps 連携 — Slack / Telegram 上でアラート確認・対応開始（Acknowledge）・解決（Resolve）が完結 柔軟な通知手段 — Slack / Microsoft Teams / SMS / 自動音声通話（電話）/ モバイルプッシュ IaC 対応 — Terraform プロバイダで設定をコード管理可能 連携先（インテグレーション） カテゴリ 代表的な連携先 監視・アラート検知 Grafana, Prometheus (Alertmanager), Datadog, Zabbix, AWS CloudWatch, New Relic 通知・コミュニケーション Slack, Microsoft Teams, Telegram, SMS, 自動音声通話 OSS 版で自社サーバーに構築することも、Grafana Cloud のマネージドサービスとして利用することも可能でした。 ...

サーバー監視は「死活監視 + リソース監視」の時代から、「メトリクス + ログ + トレース」を 1 つの画面で相関分析するオブザーバビリティの時代に移りました。クラウドネイティブ環境では、Grafana Labs の OSS スタック（Prometheus + Loki + Grafana + Alloy）が、コスト・自由度・運用ノウハウの蓄積において事実上の王道になっています。 この記事では、なぜこの組み合わせが現代の標準なのか、各コンポーネントがどう役割分担しているのか、そして最小構成から本番運用までの全体像を整理します。 なぜこの構成が「王道」なのか サーバー監視の選択肢は大きく分けて 3 系統あります。 カテゴリ 代表例 特徴 OSS スタック（Grafana Labs） Prometheus + Loki + Grafana + Alloy 無料、自由度高、運用責任は自分で OSS スタック（Elastic） Elasticsearch + Logstash + Kibana + Beats 全文検索が強力、コストとリソース消費が大 SaaS Datadog、New Relic、Grafana Cloud 楽だが高価、データ主権がない このうち Prometheus + Loki + Grafana + Alloy が王道とされる理由: ...