redash のアラート機能を使って Slack に通知する設定を試した

こんにちは! SRE を担当している多田です(@tada_infra).

データの可視化を redash で実現する中で特定のデータが閾値に達した時に Slack に通知して欲しいといった要件があり,redash のアラート機能をその要件に合うものかを検証してみたのでこの記事に検証した内容を整理してきます.

検証で使った環境

検証で使った環境は redash の AMI を使っています.東京リージョンのものを使ったので ami-060741a96307668be を指定しています.

redash.io

redash アラート機能設定

今回のケースではデータがリアルタイムで更新される社内システムがあり,そのデータを redash からクエリを発行して見たいといった条件を想定した検証しています.検証した内容にフォーカスするため redash の初期セットアップやデータソース,アラートに関連するクエリ結果の事前設定は割愛し,設定済み前提でアラート機能を使うために設定した内容を以下では書きます.

Slack の設定

まず,アラート発生後の通知先として Slack に通知したいので Slack の設定からです.Settings > Alert Destinations > New Alert Destinationから Slack を選択します.

次に, Slack 自体の設定ですが設定名と Incoming Webhook URL を設定しました.

以上でアラート先の設定自体は完了です.

アラート設定

そして,アラート設定に移っていきます.上部メニューのCreate > Alert を選択します.

1. 最初にQuery 欄に事前定義したアラートに関連するクエリを選択します.
2. 次にアラート通知したい結果が入っているカラムを指定します.
3. そして,アラートの条件を指定していきます.今回は Value が 100 以下になった時にアラートを出すよう設定しています.
4. 最後に先ほど指定した Slack の設定を通知先から選んで Add で追加し,Save ボタンで保存します.

以上でアラート設定が完了です.

Slack への通知結果

あとはデータが閾値に達するまで待つだけですが,閾値に達した時に以下の画像のように通知されます.このような形で Slack へのアラート投稿ができました.

設定中に感じた注意点

設定自体は完了なのですが,redash のアラート設定を試して感じた注意点を最後にまとめます.

• アラート通知できる条件で指定できる値は1つだけなので,クエリ結果で複数レコードが返る場合1レコードしか返らないようにしないと意図したアラートは発行が難しい
• 画面上で確認する限り条件分岐ができるわけではなさそうなので複雑な処理する場合はコードで制御が必要になると思われる

まとめ

redash のアラート機能で Slack 通知する設定を検証したのでまとめました.クエリの結果を1つに絞れればリアルタイムでコードを書くことなく通知できたのは手軽に設定できてよかったなという感覚でした.

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください！

engineers.snaq.me

Auto Scaling の AMI に Mackerel Agent を導入する時の設定でハマったこと

こんにちは! SRE を担当している多田です(@tada_infra).

Auto Scaling の EC2 に Mackerel を入れて監視をしたい時にベースの AMI にMackerel Agent を導入します.今回初歩的な躓きだったのですが,Auto Scaling が起動した時に Mackerel で監視できるはずが監視情報が確認できずにいたのを解消したのでその対処を記事にまとめます.

Auto Scaling の時の Mackerel 設定

Mackerel を Auto Scaling 環境で使う時の設定は下記のドキュメントに記載があります.

mackerel.io

Auto Scaling 向けの作業としてやらなきゃいけない設定は2点あります.まず, /etc/mackerel-agent/mackerel-agent.conf でホスト起動時のステータス設定です.Auto Scaling で起動してきた時のホストを自動で監視できるようにするために推奨されている設定です.個人的には加えて設定するロールが決まっていれば合わせて roles の定義も入れておくと Mackerel の登録時にホストだけでなくロールの設定もされた状態になるので,オススメです.

$ cat /etc/mackerel-agent/mackerel-agent.con
~中略~
roles = ["サービス名:ロール名"]

[host_status]
on_start = "working"

次に,ホストが Auto Scaling からホストが削除される時に Mackerel からも自動退役してもらう設定です.自分が扱った環境は /etc/sysconfig/mackerel-agent に AUTO_RETIREMENT=1 を追加してます.

$ cat /etc/sysconfig/mackerel-agent
# OTHER_OPTS=-v
AUTO_RETIREMENT=1

以上2点で自動登録と自動退役の設定ができた状態になったので,自分はこの時点で AMI を作っていました.

ハマった事象とその対処

ここまでの設定で Auto Scaling を起動した際に自分の環境では,Mackerel にホストは認識されるけど,サーバー上の CPU,メモリ,ディスクといったメトリクスが表示されてない状態になっていました.Mackerel サポートの方々に協力いただき,Mackerel Agent の起動時のメッセージを確認したところ API request failed: Host Already Retired というメッセージがでていました.Mackerel 側で既に退役済みのホストとしてなっておりメトリックのデータ送信が行われてない場合のメッセージになっていました.この原因は /var/lib/mackerel-agent/id ファイルが存在した状態でAMI 化してしまったため発生しました.

対処内容

/var/lib/mackerel-agent/idは Mackerel 側でホストを一意に識別するためのファイルであり,このファイルがある状態で Auto Scaling で起動した EC2 はもう退役している扱いになってしまいます.そのため,AMI 化する前に /var/lib/mackerel-agent/idを削除しておく,もしくはファイルを退避させる必要があり,今回は削除して AMI 化したところ意図通りメトリクスを確認できるようになりました.

ドキュメント引用文

Mackerel では、管理対象のホストを一意に識別するために、各ホスト毎に「ホストID」を発行し、それに関連付ける形で管理をしています（参照）。 このID情報は、Linux系OSのホストであれば「/var/lib/mackerel-agent/id」ファイルに、Windows OS の場合はインストールフォルダ内の「id」ファイルに、記録されています。

オートスケールによるスケールアウト時に起動させるインスタンスのベースイメージとして、mackerel-agent がインストール済みのカスタムマシンイメージを作成する際には、このホストIDを記録したファイルが含まれた状態でイメージ化をしないよう、注意してください。 （削除せずにイメージ化し、それを元にスケールアウトがおこなわれた場合、Mackerel は起動した全てのサーバを同一のサーバとして識別します。）

mackerel.io

まとめ

Auto Scaling 環境での Mackerel Agent 導入でハマったことを整理しました.ドキュメントの見落としが原因でハマっていたのですが,Mackerel サポートの方々に調査にご協力いただいたおかげで早急に解決に至りました!ありがとうございました🙇‍♂️ 自分と同じ間違いをする方が増えないよう自戒を込めて記事化します.

元記事

元記事はこちらです.

Mackerel 導入から導入後にやったこととこれからのことを整理する

こんにちは! SRE を担当している多田です(@tada_infra).

この記事は Mackerelアドベントカレンダー2020の7日目の記事です.皆さんにとって2020年はどんな1年でしたか？いろんなことが変化した1年だったんじゃないかなと思いますが,自分も働き方や9月に会社が変わった1年でした.転職して始めた取り組みとして監視周りがあり,組織内の課題から Mackerel の導入と組織内の方針を決めたりしていきました.そんな Mackerel 導入とその後を振り返っていきたいと思います.

Mackerel の導入前の監視

Mackerel 導入前の監視は CloudWatch で AWS サービスのみを監視しており,EC2 や Aurora などのパフォーマンスに影響があるところを下記のスライドのように Slack にアラート通知している状況でした.

ただ,アラートが鳴っても誰がどんなアクションを起こすのかが不明だったり,開発者もアラート通知チャンネルに入っているが何をしていいかわからないという状況でした.また,サービス提供している部分の中には監視が間に合っていないところがありました.そのため,CloudWatch の監視に加えて外部の監視サービスを検討することになりました.いくつか選択肢がありますが,コストや扱うシステムの監視を賄える物を検討して,最終的に Mackerel を導入することにしています.

Mackerel の導入後にやったこと

Mackerel を導入することになり,自分が取りまとめて検証と組織展開していくためにいくつかの取り組みを行ったのでそれを紹介してきます.

1. Mackerel で監視する箇所の特定とドキュメント化

まずは,Mackerel で監視する箇所の特定を行っていきました.自分が所属する会社では toC 向けのサービスを提供しているのですが,外型監視ができていなくてよくある証明書の有効期限が切れてアクセスできない事象も転職してすぐに起こっていました.なので,ユーザーに最も近いところから監視の設定をいれてきました.また,それらを GitHub にドキュメント化しました.GitHub においたのは今後開発者に開発だけでなく自分たちが開発したシステムの監視に介入してもらい,監視設定を変更したい場合に開発者からプルリクをあげてもらい自分がレビューするといったフローにしていくための意図でやってます.

2. アラート発生時に開発者が担当するシステムごとに対応内容と対応者の明記

次に,開発者ごとで担当しているシステム領域が異なるのでそれぞれの担当領域のアラートを Slack でメンションし,アラートごとにどんな対応をするかを定義して開発者と認識合わせを行いました.Mackerel 導入前アラートは Slack の @channel で通知されるもののアラートがなっていても誰もどんなアクションを起こしていいのかがわからない状態になっていたので,誰がどんな対応をするかを明らかにする必要がありました.これによってこれまで疎遠だった開発者をシステム監視の領域に踏み込んでもらえるようになったと思います.

Mackerel からのアラート通知例

アラートごとの対応内容の一部抜粋

3. 障害対応テンプレートの策定

システムごとのアラートと対応者,対応内容が決まったので組織的に障害発生から障害対応完了,その後の振り返りまでのアクションリストをまとめた障害対応テンプレートを作りました.会社ではドキュメントを esa を使っているので esa に対応内容をまとめています.この定義を行って障害発生時にどう動いて,障害対応後どう動くかを整理することができたと思います.ただ後述しますが,テンプレートを実際に使う機会が日常業務ではアラートが頻発したり,高負荷なシステムが今のところないので,予防訓練でこのテンプレートを使って障害対応を練習していきたいと考えています.

障害対応テンプレートの一部抜粋

これからやっていきたいこと

Mackerel を導入し,運用するに当たって決め事や障害発生時の対応フローが決まりましたが,今後やっていきたいこともあります.

1. 障害対応訓練
2. オンコール対応フローの構築
3. Mackerel ならではの機能の活用

1. 障害対応訓練

1つ目は障害対応訓練です.入社当初は1アカウント本番環境しかなかったのでやり辛さがありましたが,用途ごとにアカウントを分離しております.分離できたアカウントで開発者と障害対応訓練をやっていき,障害対応テンプレートを使ってそれぞれがやるべきことを確認していきたいと考えてます.

sadayoshi-tada.hatenablog.com

2. オンコール対応フローの構築

2つ目はシステム規模が大きくなっていた時にオンコール対応フローの構築です.今今はシステム規模的にも日々の負荷的にもそこまで大きいものではないのでオンコール対応の構築はまだ行っていないのですが,事業のスケールと合わせてシステムもより信頼度の向上を行うためにもオンコール対応フローを構築していきたいです.

3. Mackerel ならではの機能の活用

今は Mackerel Agent で標準利用可能なサーバーからのメトリックと EC2 ではプロセスの監視を行っているほどですが,Mackerel ならではのプラグインの開発や EventBridge と連携して自動復旧の仕組みを作ってみたいとも考えてます.

blog.a-know.me

mackerel.io

まとめ

Mackerel を導入したやったこととこれからやっていきたいことを書きました.監視をエージェント入れてから即座に始められたおかげで今まで見えなかったものがデータとして関係者全員が見えてくるようになって改善や運用業務でアクションがしやすくなりました.今後も Mackerel を活用して自社でのよりよい運用のあり方を追求していきたいです.

監視のツールをいれて見えなかったことが見えてきたおかげで回ってなかった改善や見直しができてる
データを集めて可視化して一緒にチームで見て考える機会大事だ

— Sadayoshi Tada🎉 (@tada_infra) 2020年11月11日

元記事

元記事はこちらです.

CloudWatch Agent で procstat プラグインを使った EC2 のプロセス監視を設定する

こんにちは! SRE を担当している多田です(@tada_infra).

CloudWatch Agent は EC2 から CPU,メモリなどのメトリクスをとったり,CloudWatch Logs にログを出力できますし,AWS Compute Optimizer を有効活用するためにも役立てることができます.今回は,procstat プラグインを使って Nginx のプロセス監視できるように CloudWatch メトリクスに送る検証をしました.多くの方が CloudWatch Agent でのプロセス監視設定を記事にされているのですが,自分も試してみたため記事にします.

CloudWatch Agent の導入

予め CloudWatchAgentServerPolicy をアタッチした IAM ロールを適用した Amazon Linux 2 の環境に CloudWatch Agent を導入します.

sudo yum install amazon-cloudwatch-agent

プロセス数を設定ファイルを編集する

手動で設定ファイルを定義し,CloudWatch メトリクスをおくります.

docs.aws.amazon.com

/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.jsonを編集してきます.

{
    "metrics": {
        "metrics_collected": {
            "procstat": [
                {
                    "exe": "nginx",
                    "measurement": [
                        "pid_count"
                    ],
                    "metrics_collection_interval": 60
                }
            ]
        }
    }
}

編集後,CloudWatch Agent に設定ファイルを読み込ませます./opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml に inputs.procstat セクションが追加されていて,CloudWatch Agent が起動できていれば CloudWatch メトリクスに送れているはずなので確認してきます.

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl  -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s

/opt/aws/amazon-cloudwatch-agent/bin/config-downloader --output-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d --download-source file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml --multi-config default
Successfully fetched the config and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_amazon-cloudwatch-agent.json.tmp
Start configuration validation...
/opt/aws/amazon-cloudwatch-agent/bin/config-translator --input /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --input-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d --output /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml --multi-config default
2020/11/26 23:02:31 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_amazon-cloudwatch-agent.json.tmp ...
Valid Json input schema.
I! Detecting runasuser...
No csm configuration found.
No log configuration found.
Configuration validation first phase succeeded
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
Configuration validation second phase succeeded
Configuration validation succeeded
Redirecting to /bin/systemctl stop amazon-cloudwatch-agent.service
Redirecting to /bin/systemctl restart amazon-cloudwatch-agent.service
$ cat /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
~中略~
[inputs]

  [[inputs.procstat]]
    exe = "nginx"
    fieldpass = ["pid_count"]
    interval = "60s"
    pid_finder = "native"
    tagexclude = ["user", "result"]
    [inputs.procstat.tags]
      metricPath = "metrics"
~中略~
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
{
  "status": "running",
  "starttime": "2020-11-26T23:02:31+0000",
  "version": "1.247345.35"
}

CloudWatch メトリクスにプロセスが取れているかの確認

CWAgent に exe,host,pid_finder というメトリクス(プロセスに関連付けられたプロセス ID の数)が追加されてました.意図的に nginx を停止,再度起動してグラフが上がっていくのを確認できました.

まとめ

CloudWatch Agent の procstat プラグインでのプロセス監視できるよう設定を行いました.設定は簡単にできたので別サーバーへの横展開していく時にも活用していきたいと思います.

元記事

元記事はこちらです.

JAWS-UG 朝会 #15 で『AWS Organizations と一緒にはじめるアカウント分離』の取り組みを発表した

みなさん、はじめまして！

スナックミー で SRE を担当している多田です(@tada_infra).スナックミー のエンジニアによるブログが誕生しました! 今後記事で情報発信をしていくのでブログ購読をしてもらえると嬉しいです🙌

スナックミー のエンジニアブログ1発目としてこの記事では 11/18 にJAWS-UG 朝会 #15 にて「AWS Organizations と一緒にはじめるアカウント分離」と題して登壇させていただいたので,登壇資料と登壇を振り返っていきます.

jawsug-asa.connpass.com

登壇資料

登壇資料はこちらです.

今回の登壇の振り返り

今回の発表では現在取り組んでいるアカウントを用途ごとに分離していく活動の模様を発表させてもらいました.入社してからアカウントが1つしかない状況を見て感じた課題からアカウントを用途ごとに分離していっており,アカウント分離にあたっては Landing Zone の考え方を参考にさせてもらって AWS Organizations でアカウント管理をしはじめています.

aws.amazon.com

AWS Organizations と AWS SSO を組み合わせた形でログインしてもらうこともこれまでは直ログインになっているところから変更していきたいですし,他の業務で使っているアプリケーションも AWS SSO と連携できるところも良いなと思っており,社内全体で使えるようにしていきたいと考えてます.今後のアカウントを増やしていく時も引き続き Landing Zone の考え方を参考に分離しつつ,ガードレール機能も設定していきます.

まとめ

AWS Organizations を使ってアカウント分離をしはじめた話を発表させてもらいました.AWS の活用を今後も広げていくとアカウントの数も増えてくるので,AWS Organizations を軸に管理手法とルール作りをやっていきたいと思います.JAWS-UG に参加するのが久々でしたが現場感のある話を聞けて楽しかったですし,また機会作って参加しきます😌

JAWS-UGの参加も久々でしたが、やっぱり現場感があって楽しいですね😌
また参加して機会いただければ発表させてもらいたいです！ #jawsug_asa

— Sadayoshi Tada🎉 (@tada_infra) 2020年11月18日

他の方の勉強会参加記事

omuron.hateblo.jp

元記事

元記事はこちらです.