https://hdknr.github.io/blogs/tags/%E3%82%AA%E3%83%96%E3%82%B6%E3%83%BC%E3%83%90%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3/Recent content in オブザーバビリティ on hdknr blogHugo -- 0.157.0jaFri, 08 May 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/05/apprise--%E3%82%B7%E3%83%95%E3%83%88%E7%AE%A1%E7%90%86%E3%83%84%E3%83%BC%E3%83%AB%E3%81%A7-oncall-%E8%87%AA%E4%BD%9C%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E3%82%92%E7%B5%84%E3%82%80-pyshiftor-toolsgoalert-%E3%81%AE%E5%BD%B9%E5%89%B2%E3%81%A8%E9%81%B8%E3%81%B3%E6%96%B9/Fri, 08 May 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/05/apprise--%E3%82%B7%E3%83%95%E3%83%88%E7%AE%A1%E7%90%86%E3%83%84%E3%83%BC%E3%83%AB%E3%81%A7-oncall-%E8%87%AA%E4%BD%9C%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E3%82%92%E7%B5%84%E3%82%80-pyshiftor-toolsgoalert-%E3%81%AE%E5%BD%B9%E5%89%B2%E3%81%A8%E9%81%B8%E3%81%B3%E6%96%B9/<p><a href="https://hdknr.github.io/blogs/posts/2026/05/2026-05-08-grafana-oncall-irm-incident-response/">前回の記事</a>で「Apprise + 自作 Web サービスで OnCall 相当を組む」例を示しました。この記事ではよくある誤解を整理し、<strong>シフト管理を含めた自作 OnCall スタックの現実的な選択肢</strong>を深掘りします。</p> <h2 id="まずは-apprise-の正しい位置付けを確認">まずは Apprise の正しい位置付けを確認</h2> <p><a href="https://github.com/caronc/apprise">Apprise</a> は名前から「シフト管理ができそう」と誤解されがちですが、実際の役割は明確に分かれています。</p> <p><strong>正しい位置付け</strong>:</p> <ul> <li>Apprise は <strong>「通知の超便利ハブ」</strong> — 1 つのコードで Slack / メール / SMS / LINE / Telegram など 100 種類以上の通知先に統一インタフェースで送る</li> <li><strong>シフト管理機能（カレンダー、ローテーション、当番判定）は持たない</strong></li> <li>「シフト管理に Apprise を使う」とは、<strong>シフトロジックは別のライブラリ / DB / カレンダーで持ち、通知配信だけ Apprise に任せる</strong>という意味</li> </ul> <p>つまり Apprise は「<strong>組んだシフトを確実に届ける道具</strong>」であり、「シフトを組む道具」ではありません。前回記事のコード例で <code>get_policy_for_now()</code> を Python で書いていたのは、まさにこの「シフト判定ロジックを自作」の実装です。</p> <h2 id="シフト管理を自作する場合に組み合わせる-python-ライブラリ">シフト管理を「自作する場合」に組み合わせる Python ライブラリ</h2> <p>シフトロジックを自分で書くなら、以下のライブラリが Apprise と相性が良い。</p> <h3 id="1-pyshiftpoint85pyshift--古典的なシフトローテ">1. PyShift（point85/PyShift） — 古典的なシフトローテ</h3> <p><a href="https://github.com/point85/PyShift">point85/PyShift</a> は、Java 版の Shift ライブラリを Python に移植したもの。PyPI では <code>PyWorkShift</code> として配布されています。</p>https://hdknr.github.io/blogs/posts/2026/05/grafana-oncall-%E3%81%AF%E7%B5%82%E3%82%8F%E3%81%A3%E3%81%9Fgrafana-cloud-irm-%E3%81%8C%E5%A7%8B%E3%81%BE%E3%81%A3%E3%81%9F-%E3%82%AA%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%AB%E4%BD%93%E5%88%B6%E3%81%AE%E7%8F%BE%E4%BB%A3%E7%9A%84%E9%81%B8%E6%8A%9E%E8%82%A2%E3%82%92%E6%95%B4%E7%90%86%E3%81%99%E3%82%8B/Fri, 08 May 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/05/grafana-oncall-%E3%81%AF%E7%B5%82%E3%82%8F%E3%81%A3%E3%81%9Fgrafana-cloud-irm-%E3%81%8C%E5%A7%8B%E3%81%BE%E3%81%A3%E3%81%9F-%E3%82%AA%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%AB%E4%BD%93%E5%88%B6%E3%81%AE%E7%8F%BE%E4%BB%A3%E7%9A%84%E9%81%B8%E6%8A%9E%E8%82%A2%E3%82%92%E6%95%B4%E7%90%86%E3%81%99%E3%82%8B/<p><a href="https://hdknr.github.io/blogs/posts/2026/05/2026-05-08-prometheus-loki-grafana-server-monitoring-stack/">前回の記事</a>で「サーバー監視の王道スタック」として Prometheus + Loki + Grafana + Alloy を整理しました。アラート設計のセクションで触れた <strong>Grafana OnCall</strong> について、改めて単独で深掘りします。</p> <p>ただし重要な注意点があります — <strong>Grafana OnCall OSS（grafana/oncall リポジトリ）は 2026 年 3 月 24 日にアーカイブされました</strong>。後継は **Grafana Cloud IRM（Incident Response Management）**で、OnCall と Incident の両アプリが 1 つに統合されています。</p> <p>「Grafana OnCall を新規導入したい」「既存環境を移行すべきか」という人に向けて、<strong>何が終わって、何が始まったのか</strong>を整理します。</p> <h2 id="grafana-oncall-とは何だったのか">Grafana OnCall とは何だったのか</h2> <p>Grafana OnCall は <strong>「アラートが鳴った後の対応フロー」を管理するツール</strong>でした。</p> <ul> <li>Prometheus / Loki / Grafana が「<strong>異常を検知する</strong>」までを担当</li> <li>Grafana OnCall は「<strong>鳴ったアラートを誰に・どうやって届け、どう対応するか</strong>」を管理</li> </ul> <p>PagerDuty や Opsgenie の OSS 互換ツールとして、Grafana エコシステムの中で重要なポジションを占めていました。</p> <h3 id="主な機能当時">主な機能（当時）</h3> <ol> <li><strong>アラートの集約とルーティング</strong> — 複数の監視システムからのアラートを統合、内容に応じてチームへ振り分け</li> <li><strong>オンコールシフト管理</strong> — 担当者のカレンダー（シフト表）に従って当番者にだけ通知</li> <li><strong>エスカレーションポリシー</strong> — 一定時間応答がなければ次の担当者へ自動エスカレーション</li> <li><strong>ChatOps 連携</strong> — Slack / Telegram 上でアラート確認・対応開始（Acknowledge）・解決（Resolve）が完結</li> <li><strong>柔軟な通知手段</strong> — Slack / Microsoft Teams / SMS / 自動音声通話（電話）/ モバイルプッシュ</li> <li><strong>IaC 対応</strong> — Terraform プロバイダで設定をコード管理可能</li> </ol> <h3 id="連携先インテグレーション">連携先（インテグレーション）</h3> <table> <thead> <tr> <th>カテゴリ</th> <th>代表的な連携先</th> </tr> </thead> <tbody> <tr> <td>監視・アラート検知</td> <td>Grafana, Prometheus (Alertmanager), Datadog, Zabbix, AWS CloudWatch, New Relic</td> </tr> <tr> <td>通知・コミュニケーション</td> <td>Slack, Microsoft Teams, Telegram, SMS, 自動音声通話</td> </tr> </tbody> </table> <p>OSS 版で自社サーバーに構築することも、Grafana Cloud のマネージドサービスとして利用することも可能でした。</p>https://hdknr.github.io/blogs/posts/2026/05/%E7%8F%BE%E4%BB%A3%E7%9A%84%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E7%9B%A3%E8%A6%96%E3%81%AE%E7%8E%8B%E9%81%93%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF-prometheus--loki--grafana--alloy-%E3%81%A7%E5%A7%8B%E3%82%81%E3%82%8B%E3%82%AA%E3%83%96%E3%82%B6%E3%83%BC%E3%83%90%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3%E5%9F%BA%E7%9B%A4/Fri, 08 May 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/05/%E7%8F%BE%E4%BB%A3%E7%9A%84%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E7%9B%A3%E8%A6%96%E3%81%AE%E7%8E%8B%E9%81%93%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF-prometheus--loki--grafana--alloy-%E3%81%A7%E5%A7%8B%E3%82%81%E3%82%8B%E3%82%AA%E3%83%96%E3%82%B6%E3%83%BC%E3%83%90%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3%E5%9F%BA%E7%9B%A4/<p>サーバー監視は「死活監視 + リソース監視」の時代から、<strong>「メトリクス + ログ + トレース」を 1 つの画面で相関分析する</strong>オブザーバビリティの時代に移りました。クラウドネイティブ環境では、<strong>Grafana Labs の OSS スタック</strong>（Prometheus + Loki + Grafana + Alloy）が、コスト・自由度・運用ノウハウの蓄積において事実上の王道になっています。</p> <p>この記事では、なぜこの組み合わせが現代の標準なのか、各コンポーネントがどう役割分担しているのか、そして最小構成から本番運用までの全体像を整理します。</p> <p><img alt="Prometheus・Loki・Tempo を Grafana Alloy が一括収集し、Grafana で可視化するサーバー監視スタックの全体構成図。各サーバー / コンテナで Alloy がメトリクス・ログ・トレースを収集し、Prometheus / Loki / Tempo に振り分け、Grafana が PromQL と LogQL でクエリしてダッシュボード化、Slack/メールにアラート通知する流れを示している" loading="lazy" src="https://hdknr.github.io/blogs/images/loki-grafana-alloy-stack.png"></p> <h2 id="なぜこの構成が王道なのか">なぜこの構成が「王道」なのか</h2> <p>サーバー監視の選択肢は大きく分けて 3 系統あります。</p> <table> <thead> <tr> <th>カテゴリ</th> <th>代表例</th> <th>特徴</th> </tr> </thead> <tbody> <tr> <td><strong>OSS スタック（Grafana Labs）</strong></td> <td>Prometheus + Loki + Grafana + Alloy</td> <td>無料、自由度高、運用責任は自分で</td> </tr> <tr> <td><strong>OSS スタック（Elastic）</strong></td> <td>Elasticsearch + Logstash + Kibana + Beats</td> <td>全文検索が強力、コストとリソース消費が大</td> </tr> <tr> <td><strong>SaaS</strong></td> <td>Datadog、New Relic、Grafana Cloud</td> <td>楽だが高価、データ主権がない</td> </tr> </tbody> </table> <p>このうち <strong>Prometheus + Loki + Grafana + Alloy</strong> が王道とされる理由:</p>