🦁

Heroku + Goでのシステムログ設計プラクティス

に公開
Go
Heroku
tech

Heroku + Go 構成におけるシステムログ設計のベストプラクティス

ゴール

Heroku上で稼働するGo製のAPIサーバーにおいて、クラッシュや障害の検知とその追跡を確実に行うためのシステムログ設計について解説します。
ちなみに私の環境はGoがバックエンドでフロントはFirebaseのHostingです。

現状の課題

  • クラッシュ時にHeroku標準ログにしか頼れない。
  • 障害発生後にログが流れてしまい、原因追跡が困難。
  • 通知がないため、異常に気づけない。

解決すべきポイント

課題 解決策
クラッシュに即座に気付きたい ログアラートで通知を受ける
クラッシュ直後のログを見たい ログを外部サービスに集約・検索
長期保存は不要 クラッシュ時のログが見れれば十分

採用する構成（ベストプラクティス）

Heroku + Papertrail + Slack通知のミニマルで強力な構成。

[Heroku Go Backend]
       ↓ stdout
   [Papertrail] ← クラッシュログ収集 & Slack通知

Papertrail の導入手順

  1. HerokuにPapertrailを追加
heroku addons:create papertrail

  1. Herokuログが自動的にPapertrailへ流れる（Logplex経由）

  2. 補足：Papertrailは基本無料で使える

項目 内容
ログ保存期間 最大 7 日間
ログ転送量（容量） 月間 50 MB（過去には 100MB の場合も）
検索対象 最近のログのみ（保存期間内に限る）
アラート機能 メールやSlackなど一部連携が可能

Slack通知の設定

  1. Papertrailの管理画面にアクセス
  2. [Saved Searches] → [Create a new saved search]
  3. 検索条件を設定（例: program:app AND severity>=err）
  4. アラート → [Webhooks or Slack] を設定

SlackのIncoming Webhook URLを登録すれば完了！

補足：なぜSentryを使わないか

  • 今回はHerokuログで十分に追跡できる構成
  • Go側でpanicやerrorを明示的にログ出力することが前提
  • クライアント側の例外までは今回対象外（Firebaseには導入可能）

まとめ

  • Heroku標準のログは一時的で、見逃しリスクがある
  • Papertrailを使えばログを集約・検索・通知が可能
  • Slack通知によって、障害に即時対応可能な体制が整う

おまけ：panic時にログを出力するGoコード例

defer func() {
    if r := recover(); r != nil {
        log.Printf("[panic] %v\n%s", r, debug.Stack())
    }
}()

今回のベスト構成

  • Papertrail（Heroku Addon）
  • Slack通知（アラート連携）
  • Goログにエラー出力を忘れずに！

シンプルで、でも確実にクラッシュを検知・追跡できる構成です。

Discussion