PagerDuty Tips(Terraform/オンコール通知/インシデント分析)
今までの連載ではPagerDuty自体が持つ機能を紹介してきましたが、今回は趣旨を変え、ちょっとした小ネタを紹介していこうかと思います。
Terraformによる管理
Infrastructure as Codeと言われて久しいですが、ChefやPuppetといったツールを利用して構成管理を行うことは珍しくなくなりました。そういったツールの中でも、HashiCorp社が提供するTerraformは複数のリソースをまとめて管理できる優れものです。TerraformにはProvidersという仕組みがあり、様々なインフラリソースやサービスを扱えるようになっています。もちろんPagerDutyのProviderも用意されています。公式に用意されているProviderはGitHub(https://github.com/terraform-providers)に公開されていますが、ない場合でも自分で書いて拡張できます。
Terraformによる管理では、ユーザー、チーム、エスカレーションポリシー、サービス、スケジュール、メンテナンスウィンドウなど、今まで紹介してきたほとんどの機能がカバーされています。ただし、0.10.0より古いバイナリだと動かないのでご注意ください。
PagerDutyのようなSaaSの設定もコード化することで、設定の抜け漏れや間違いを仕組みで防ぐことができますし、反映前にレビューを行うこともできます。もちろん、コードを書いてリポジトリにプッシュしてプルリクエストを作って……と手間は増えますが、それ以上に得られるものも多いです。
現在のオンコール担当が誰なのかを自動で通知
今日のオンコール担当は誰なのか、というのはブラウザでPagerDutyの設定画面を見に行けばわかりますが、自動で通知されるとさらに便利です。そこで、PagerDutyのSREチームが作成したpd-oncall-chat-topicというツールを使ってみてはいかがでしょうか。
AWSとSlackが前提になってしまいますが、定期的にAWS LambdaがPagerDutyのAPIからオンコール担当を取得し、Slackの特定のチャンネルトピックを更新してくれます。
注意点としてはデフォルトでそのまま使うと、CloudFormation・KMS・Lambda・DynamoDBがカナダリージョンで作成されてしまいます。またREADMEに書いてありますが、LambdaとDynamoDBを使っている都合上、若干の料金が発生します。
Incident分析
PagerDutyにはアナリティクスの画面があり、インシデントの数・Ackまでにかかった時間・Resolveされるまでの時間などをチームごとやユーザーごとにグラフで見ることができます。
これはこれである程度の振り返りを行うことは可能ですが、もう少しディープに分析する方法をご紹介します。
メニューのAnalyticsからSystem Reportを選択し、その後Incidentsタブをクリックしてください。右上で期間を指定できるので分析したい期間をここで選びましょう。単位も選べるのでここではMonthを選択します。
すると画面下に1カ月毎のインシデントのサマリーが表示されますので、先ほど指定した期間分、Download CSVをクリックしてダウンロードします。次に、ダウンロードしたファイルをマージして1つにまとめます。例えば6カ月を指定した場合は6個のファイルをマージしますが、ヘッダがついているのでそこだけ注意が必要です。以下のような感じで処理できます。
$ find ~/Downloads/ -name 'incidents*.csv' -print0 | xargs -0 awk 'NR==1 || FNR!=1' > ~/Downloads/combined.csv
CSVが用意できたら、PagerDutyが用意しているPivot Tableへ取り込みましょう。
https://docs.google.com/spreadsheets/d/18xwIe3MqlBvHk4dgsyp_CTONyY6yb3HP0wn-8Nu7Ahc/edit#gid=449890498このGoogle Spreadsheetをテンプレートとして、ファイルメニューからコピーを作成します。次にInputシートへ移動し、ファイルメニューから先ほどのCSVをインポートします。この時サンプルデータは上書きしてください。インポートが終わったら、他のシートへ結果が反映されます。
例えば曜日・時間帯別に発生したインシデントを、ヒートマップのように見ることができたりします。いくつかのシートでは、ピボットテーブルのフィルタでservice_nameやescalation_policy_nameがブランクのみになっているので、必要に応じて変更してお使いください。
取り込んだデータのサマリーが一番右のCalculationsシートにありますので、そこでフィルタを活用してデータを絞り込むことができます。例えば上記の画面(テンプレートに含まれているサンプルのデータです)では、日曜日の遅い時間になるほどインシデントの発生数が増えており、そのインシデントの正体は一体何なのかを調べることが可能です。
まとめ
6回に渡ってPagerDutyについて紹介してきた本連載の締めくくりとして、今回はTerraform、オンコール通知、インシデントの分析についてみてきました。インシデント分析をしてみると思わぬ気付きや、設定の不備が見つかったりします。特に難しい作業ではないので、ぜひ一度分析してみることをお勧めします。また、各種ツールとの連携についての日本語の解説はこちらで参照できます。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- PagerDutyのアプリ連携(Slack/JIRA/Custom Incident Action)
- モニタリングシステム連携とインシデントの抑制
- PagerDutyをもっと使い込む コンテナ活用とAPIの利用例
- PagerDutyのエスカレーションポリシーとサービス
- システム運用エンジニアを幸せにするソリューションPagerDutyとは
- クラウドアプリケーションを構築してデータを送信しよう
- Oracle Cloud Hangout Cafe Season7 #2「IaC のベストプラクティス」(2023年7月5日開催)
- TerraformからPulumiへの移行
- CloudサービスとRPAの連携
- データをDynamoDBへ保存&mockmockによるIoTシステムのテスト方法