継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

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

タダです.

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-agentAUTO_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 導入から導入後にやったこととこれからのことを整理する

タダです.

この記事は 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 においたのは今後開発者に開発だけでなく自分たちが開発したシステムの監視に介入してもらいたいし,監視設定を変更したい場合に開発者からプルリクをあげてもらい自分がレビューするといったフローにしていくための意図でやってます.

f:id:sadayoshi_tada:20201206092339p:plain

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

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

Mackerel からのアラート通知例 f:id:sadayoshi_tada:20201206092012p:plain

f:id:sadayoshi_tada:20201206092212p:plain

アラートごとの対応内容の一部抜粋 f:id:sadayoshi_tada:20201206150831p:plain

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

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

障害対応テンプレートの一部抜粋 f:id:sadayoshi_tada:20201206094323p:plain

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

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.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

AWS のデータベースの専門知識を証明する『AWS 認定 Database Speciality』の試験勉強でやったことを整理する

タダです.

普段業務でデータベースをよく触るようになってきたこともありその勉強の一環で,11/28 に「AWS 認定 Database Speciality」を受けて合格しました.今回は自分がどんな勉強をしたかを振り返り,今後受験される方の勉強の参考になれば嬉しいです.

試験範囲について

試験範囲については試験のガイドで確認できます.データベースサービスを特徴を理解して,各トピックでの設計や実装するための知識が問われそうだと認識しました.

AWS 認定データベース — 専門知識」 (DBS-C01) 試験は、データベースロールを遂行する人を対象としています。この試験では、データベースに関する全体的な理解度 (例: 設計、移行、展開、アクセス、保守、自動化、監視、セキュリティ保護、トラブルシューティング) を評価します。

AWS データベースサービスの主な特徴について明確に理解する。

・ニーズと要件を分析し、AWS サービスを使用した適切なデータベースソリューションを設計および提案する。

aws.amazon.com

試験の割合が以下のようになっています.

試験分野 試験における比重
分野 1: ワークロード固有のデータベース設計 26%
分野 2: 展開および移行 20%
分野 3: 管理および運用 18%
分野 4: 監視およびトラブルシューティング 18%
分野 5: データベースセキュリティ 18%

試験勉強で注力したこと

次に,試験に向けて注力して勉強したことをまとめていきます.大きく2つのことをやりました.ちなみに自分の能力は AWS に関する業務を行って5年ほどで,データベースに関わる業務が増えたのはここ1年くらいという状況です.

1. 問われるトピックを確認する

サンプル問題や模擬試験を解くことでどのような問題が問われるのかを確認しました.サンプル問題を解いてみた感じですが,Aurora,RDS,DynamoDB,ElastiCache,DMSあたりが問われそうだと感じたのでこれらのサービスで足りてない知識を補うことにしました.

サンプル問題リンク

2. データベースサービス知識を深める

データベースサービスの理解のためには概要をさらうのに下記のページや BlackBelt シリーズと各種ドキュメントをみていきました.特にデータベースサービスのアップデートを追えていない物を中心に知識を補填していきました.

aws.amazon.com

BlackBelt シリーズで見た物

ドキュメントで見た物

docs.aws.amazon.com

docs.aws.amazon.com

docs.aws.amazon.com

docs.aws.amazon.com

試験の結果

試験の結果は750点の合格ラインで780点でした.ギリギリ😇 f:id:sadayoshi_tada:20201130132115p:plain

まとめ

AWS 認定 Database Speciality」に向けて勉強した内容をおおまかにまとめました.自分が追えていなかったデータベースの知識を勉強できて今後の業務に活かせそうこともさらえてよかったです.Alexa Skill Builder Speciality は来年廃止になるようなので次は,来月にNetwork Speciality に挑みたいと思います!

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

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

タダです.

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.tomlinputs.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 メトリクスにプロセスが取れているかの確認

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

f:id:sadayoshi_tada:20201127081621p:plain f:id:sadayoshi_tada:20201127081739p:plain

まとめ

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

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

タダです.

11/18 にJAWS-UG 朝会 にて「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 に参加するのが久々でしたが現場感のある話を聞けて楽しかったですし,また機会作って参加しきます😌

他の方の勉強会参加記事

omuron.hateblo.jp