運用中のAPIでエラーが出たときどうやって検知してSlackに通知しよう 〜概要編〜

はじめに

これは KWC Advent Calendar 2022 の記事です。

はじめまして、（株）KDDIウェブコミュニケーションズ でバックエンドエンジニアをしていますchihirosと言います。2021年11月にKWCへ入社し、熊本や福岡などからフルリモートで日々業務を行っています。

この記事では本番稼働中のプログラムがエラーを出したときに、どうやったらエラーの存在に気づけるのかについて書いていきます。

1日目の記事、試用期間中に会社の主力事業のAWS環境をゼロからTerraform化した の中にも書かれてあるように、弊社ではビジネス向けにレンタルサーバーを提供しています。その中で一部の社内システムにはAWSやAzureと言ったクラウドを使っています。

*紹介*
こちらは内容は概要編になっておりまして、実装編はこちらになります。（明日公開です！！）
リンクは該当記事が公開され次第、修正いたします。

目次

1. 前提条件
2. 最終目標
3. どこでSlackにメッセージを送信するべきなのか
4. システムの構成
5. いざ実装へ
6. まとめ

前提条件

私の主な業務はAPIの開発でして言語はGoを使っています。APIはAWS ECS上で動作しています。
構成としてはこんな感じです。（画像はimageです）
ログは全てCloudWatch Logsに保存されています。

弊社では、一部の社内サービスをオンプレからクラウドにリプレイスしており、バックエンドとしてはAPIの種類や機能を増やしたり、既存のシステムとの通信を行うために社内ライブラリの開発をGoでしています。
クラウドのシステム環境はインフラ・アプリ含め絶賛構築中でして、これからDevOpsの環境が整っていきます。

本題に戻りますが、ここからが運用中のAPIが出したエラーをどうやって検知するかのお話です。

最終目標

1. チャットツールはSlackを使っているので、アラートはSlackに飛ばしたい
2. AWS ECS上で動いているAPI内部でエラーが発生した時にSlackへ通知したい
3. エラーでなくとも、特定のログなどをSlackへ送れたら嬉しい

どこでSlackにメッセージを送信するべきなのか

上で掲げた最終目標を達成するためには、まず、Slackにメッセージを送る機能をどこかに実装する必要があります。

• ここで言う「どこかに」とはメッセージ送信の機能をプログラム内部に組み込むか、外部に実装するかのことです
  1. プログラム内部に+αでメッセージ送信の機能を組み込む場合
     • エラー処理の中でWebhookを叩いたり、Slack SDKを使ってメッセージ送信してあげたら良さそう
  2. プラグラム外部にメッセージ送信の機能を作る場合
     1. プログラムが吐いたログを見て、場合によってはメッセージを送信してあげるとか
     2. 特定のエラーに限りメトリクスを送るようにしてみるとか
        1. DatadogやGrafanaなどを使っていく予定があれば相性良さそう

1. プログラム内部に+αで組み込む場合

• エラー処理の中でWebhookを叩いたり、Slack SDKを使ってメッセージ送信してあげる
  • メリット
    • 特に無い気がする
    • 強いて言えば、通知にリアルタイム性があるぐらい？
  • デメリット
    • メッセージの内容やメンションなどちょっとした変更をするだけでも、プログラム全体をデプロイし直す必要がある
    • プログラムの主機能 +α(メッセージ送信) となるため、プラグラム自体の機能が増えてしまい出来ることが多くなってしまう
    • ↑ 個人的にはAPI自体で出来ることは最低限にしてあげたい（何でも出来るから何でもやろうのモノリシック化を避けていきたい）

やるとしたら、コードはこんな感じになるんだと思います。
とにかくWebhookURLにPOSTでデータを送ればメッセージが届きます。

main.go

func SendSlackMessage(msg string) {
	url := "https://hooks.slack.com/services/XXXXXXXX/YYYYYYY/ZZZZZZZZZZ"
	values := map[string]string{"text": msg}
	jsonValue, _ := json.Marshal(values)
	http.Post(url, "application/json", bytes.NewBuffer(jsonValue))
}

func main() {
	SendSlackMessage("これはGoから送信したメッセージです")
}
// ----------------------------------------------------
func main() {
    conn, err := sql.Open("postgres", "")
	if err != nil {
		SendSlackMessage("DBのコネクション取得に失敗しているよ！！")
		return
	}
	defer conn.Close()
}

cURLの場合

curl --request POST \
  --url https://hooks.slack.com/services/XXXXXXXX/YYYYYYY/ZZZZZZZZZZ \
  --header 'content-type: application/json' \
  --data '{"text": "これはcURLで送信したメッセージです"}'

2. プラグラム外部にメッセージ送信の機能を作る場合

• 外部に独立したメッセージ送信の機能を作る場合
  • メリット
    • 機能の分離・明確化が行える
      • アラートの通知はAWS ChatbotやLambdaに任せることが出来る
    • 通知の機能が独立していることでメンテナンスのしやすさが上がる
    • 複数のシステムから使うことが出来る
  • デメリット
    • 実装の仕方次第ではエラーが出てから通知までにタイムラグが出ることも
      • 実際に作ってみてタイムラグが許容出来る範囲か確認した方がいいかも

結局どっちにしたの？

最終的には、Slackに通知する機能をAPIの外部に実装しました。

ただ、APIの開発を行い始めたときは、機能の実装を優先したため、APIに+αでSlack通知の仕組みを入れていました。しかし、APIが2,3個と増えていくについれて管理が手間になってきたので、社内の共通ライブラリを作ったタイミングでSlack通知の機能を外部に出しました。

CloudWatch Logs、 ログを見るか？ メトリクスを見るか？

AWS ECSで動いているAPIのログはCloudWatch Logsに溜まっているため、ここを見てメッセージを送るようにしました。

次に問題となってくるのはログ メトリクスのどっちを見るのかです。
このどっちを見るべきなのか答えを出せていません。すいません。 orz

今回、Slackへ送りたいアラートの内容としてはAPI内部で発生したエラーのため、
ログを見てSlackへ通知を送るように実装しました。

今後、Datadogなどが環境に入って来たらOpenMetrics形式でメトリクスを出す仕組みを作ろうと思います。

システムの構成

最終的にはSREの協力を得ながら次のような構成になりました。

1. APIのログはCloudWatch Logsに溜まっていきます
2. CloudWatch　Logsでは、Subscription filterを使い特定の文字が含まれるログを検知します
   1. 今回は_SLACK_NOTIFYをトリガーにしています
3. 特定の文字があった場合は、そのログがeventとしてLambdaへ送られるようにしています
4. Lambdaの中でeventを中身を見て、必要な処理をしてからSlackにメッセージを送信します

AWSには追加料金なしで使えるChatbotがありますが、今回はメッセージの内容をeventの中身に応じて変えたかったためLambdaを使っています。

いざ実装へ

概要の説明だけでここまで長くなってしまったので、実装はこちらをご覧ください。

まとめ

今回は CloudWatch Logs+Subscription filter+Lambdaを使って、Slackへメッセージを送信する機能をAPIの外部に作りました。
ただ、これはシステムのスケールや用件に応じてはAPI内部に入れても良いと思っています。
みなさんの環境に応じて色々と試してみてください。

宣伝

KWC Advent Calendar 2022はまだ、続きますので良ければ他の記事もご覧ください。