こんにちは。Photoraitエンジニアのヒエイです。

Photoraitではサービスのエラー監視にSentryを導入しています。

Sentryとは

エラー収集・可視化ツール

サイトで発生させたエラーをこのツールに送信しツール画面上からエラー詳細を確認でき、エラー解決に役立てることができます。

Sentryを導入してしばらく経ちましたが、運用上の問題を抱えていました。

  • 明確な監視体制がない
  • どんなエラーが出ていて、どれだけのエラー数があるのか把握しきれていない。

エラー数に関してはSentryツール上を見れば確認できる事ではありますが、サイト運営者自身がエラー数と内訳を定期的に観測できるようにする体制が必要でした。

今回はエラー数と内訳を監視できるようにした話を主に書きます。

方針

以下の内容で集計スクリプトを作成します。

  • SentryApiを使って集計を行う。
    • 集計はGoogle App Scriptを使用
  • 直近一週間以内に上がったissue一覧を取得。issue数を集計。
  • issueのエラー文、エラー詳細、エラー数、sentryリンクも一覧化する。
  • 集計結果はGoogle SpreadSheetに排出。エラー数をslackに通知。

この集計自動化により、エラーissue数の定点観測と内訳を可視化し監視体制に役立てたいと思います。

 

集計スクリプト作成

Sentry Apiを使用

List a Project’s Issuesを使います。

エンドポイントは

/api/0/projects/{organization_slug}/{project_slug}/issues/

sentry側でauth tokenを発行し、curlを例に以下のようにリクエストを投げます。

curl https://sentry.io/api/0/projects/{organization_slug}/{project_slug}/issues/?query=is:unresolved&statsPeriod=14d \ -H 'Authorization: Bearer <auth_token>'
  •  query=is:unresolved
    • unresilvedステータスのリストを取得。
  • statsPeriod=14d
    • 24h、14dが選択できます。7日間分欲しいので14dに設定。

レスポンスの形がこちらになります。

エラー数を取得する

レスポンスにstatsというパラメータがあります。

stats: {
    14 d: [
      ......
      [
        1608076800,
        1
      ],
      [
        1608163200,
        0
      ]
    ]
}

それぞれの配列に

  • timestamp
  • エラー数

という形で日付ごとのエラー数が格納されているので直近7日間分のエラー数を加算する集計をさせる事にしました。

エラーリストの作成とデータ排出

スプレッドシートに集計シート、エラー数集計という名前でがあらかじめシート用意されている前提とします。

集計した結果を上記シートに書き込みます。

const ss = SpreadsheetApp.getActiveSpreadsheet();

const issueSheet = ss.getSheetByName('集計シート');
// あらかじめ用意していたエラー数用シート取得
const issueCountSheet = ss.getSheetByName('エラー数集計');

// ここでList a Project'sのエンドポイントからエラーリスト取得のメソッド呼び出し例
const list = Sentryapi.getWeeklyErrorList();
const issueList = JSON.parse(list);

const sumCount = [
    ['php', 0],
    ['js', 0],
];
issueList.forEach(issue => {
      let errNum = 0;

      // 7日前から集計日前日までのエラー数を取得
      for (let i = 6; i <= 12; i++) {
        if (issue.stats['14d'][i][1] > 0) {
          // エラー数を加算
          errNum += issue.stats['14d'][i][1];
        }
      }
      // エラー数が0ならスキップ
      if (errNum < 1) {
        return;
      }
      // スプレッドシートにissueデータインサート
      issueSheet.appendRow([
        issue.title,
        issue.metadata.value,
        issue.platform,
        Math.floor(errNum),
        issue.permalink
      ]);

      // issue数を種類ごとに加算
      sumCount[issue.platform]++;
});

// 集計したissue数を書き込み
sumCount.forEach(platformCount => {
    issueCountSheet.appendRow(platformCount);
});

webpack、docker、claspを使い、「チーム活性化と、GASでGaroonスケジュールをSlack通知」のようにGASにデプロイしています。

通知

集計したissue数をslackに通知するようにしました。毎週決められた曜日に直近1週間分エラーとして通知されます。

以下画像内のプロジェクト名と件数は仮です。

基本的にクリティカルなエラーはすぐに解消対応をしている体制でいましたが、サイトに影響の無い軽微なエラーが多く件数として上がっていました。

 

監視と体制

ルールとフロー

  • 詳細に関しては伏せますが対応優先度や対応フローをまとめたルールブックを作成しました。
  • 開発陣主導の活性化活動も始めました。営業やディレクターもいるPhotoraitチーム全体の定例会議で活動内容や数値面の共有と、Sentryとエラーの付き合い方について紙芝居にした説明を実施しています。（自宅で子供に絵本を読んでいる習慣が活かされました）

改善活動

  • 毎週上がったissue数を確認し、作成されたエラー一覧から原因と対策方針を決め修正実対応をしています。
  • サービス毎のissue数をグラフ化し、観測できる状態を作りました。
  • 週毎に発生したissue数を指標として設定しました。エラー数は障害などで急激に数値が跳ねる可能性もあるため、あくまで対応優先度を決める値とし、監視する指標はissue数として定点観測しています。

フェーズを設定

  • 活動開始当初は、監視体制を作る・エラーの多いissueを減らしてゆく、という方針で活動していましたが段々エラーを潰してゆくとニッチなエラーが残されてゆき、これはエラーと呼べるものか、何を持って対応すべきエラーとするかという対応への向き合い方が変わってくると考えました。
  • そこで活動フェーズを作成し、状況により活動方針を変更する予定です。

 

さいごに

まだまだ駆け出しの段階だと思いますが、いざ体制を作って改善対応を始めるとチームで楽しく活動できている思います。今後もサービスクオリティ改善に向けて対策活動を続けていきます。

Join Us !

ウエディングパークでは、一緒に働く仲間を募集しています！
ご興味ある方は、お気軽にお問合せください（カジュアル面談から可）

採用情報を見る