8
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Amazon CloudWatchでEC2上のプロセス死活監視と自動復旧する方法(インスタンス自体の再起動なし)

Last updated at Posted at 2022-12-17

はじめに

オンプレからクラウドへリフト&シフト案件にて、
既存の監視ツールをそのまま移行している経験はありませんか。
OSレイヤーより上の監視を行う際はサードパーティの監視ツールをそのまま使用するケースがあるかと思います。
そういった監視サービスは便利な反面ライセンス管理・更新の手間/コストがかかるため極力導入を控えたいといった課題がある中、
本記事ではOSレイヤーより上のプロセス監視をAWSの機能を組み合わせて実現させた記事になります。

結論

以下サービスの組み合わせでプロセス死活監視/自動復旧が実現可能でした。
※ただし、自動復旧のための再起動シェルは作成が必要です。

組み合わせたサービス

【死活監視検知/メール連絡】
「CloudWatchアラーム」⇒「SNS」

【死活監視検知/自動復旧】
「CloudWatchアラーム」⇒「EventBritge」⇒「SSM RunCommand」
※RunCommandで実行させるシェルは別途作成

CloudWatchで収集できるプロセス監視観点

今回は「procstat」というプラグインを使用して、
プロセス情報収集/メトリクス検出できるようにします。
procstatプラグインを使用して収集できるプロセス情報は以下の通りです。

収集可能な情報

【使用しそうな主要情報】
・pid_count(プロセスID の数)
  ※正常動作中なら1、停止中なら0となり死活監視に使用
・cpu_time(プロセスで CPU を使用する時間)
・memory_data(プロセスで使用するメモリの量)

【その他取得可能な情報全量】
procstat プラグインでプロセスメトリクスを収集する

実装してみた

■構成図
【死活監視検知/メール連絡】
image.png

【死活監視検知/自動復旧】
image.png

1.【死活監視検知/メール連絡】の実装

<前提>
・使用OS:AmazonLinux2
・EC2の構築手順は割愛
・EC2に対し以下IAMロールが付与されている
  ・CloudWatchAgentServerPolicy(CloudWatchエージェントとの通信用)
  ・CloudWatchAgentAdminPolicy(CloudWatchエージェントとの通信用)
  ・AmazonSSMManagedInstanceCore(セッションマネージャ接続用)
   参考元:CloudWatch エージェントで使用する IAM ロールとユーザーを作成する

1-1.CloudWatch Agentの導入

※AmazonLinux2であればインスタンス内にAgent用パッケージが存在しているが、今回は汎用的に使用できるRunCommandで導入

①AWSコンソールより「Systems maneger」⇒「RunCommand」

②パラメータとして以下入力
・コマンドドキュメント:AWS-ConfigureAWSPackage
・Action:install
・Installation Type:Uninstall and reinstall
・Name:AmazonCloudWatchAgent
・Version:latest
image.png

1-2.CloudWatch Agentの設定(プロセス/その他メトリクス・ログ取得)

③AWSコンソールより「Systems maneger」⇒「ParameterStore」
※CloudWatch エージェント設定を実施

④以下jsonファイルを値としてパラメータを設定
・名前:AmazonCloudWatch-linux-config
・タイプ:文字列
・データ型:text
・値:以下jsonファイル


採取する対象メトリクス:
 ・cpu
  →CPU がアイドル状態の時間の割合(%)
  →CPU が I/O 操作の完了を待機している時間の割合(%)
  ※CPUは標準メトリクスである程度の情報は確認できるため、不要としてもよい
 ・disk
  →ディスクスペース合計に対する使用済みの割合(%)
  ※ディスクは標準メトリクスである程度の情報は確認できるため、不要としてもよい
 ・メモリ
  →現在使用中のメモリの割合(%)
 ・プロセス
  →「プロセス名:httpd」として起動中のプロセス数(カウント)

 ※採取する対象OSログ:
  OSログとして出力される「messageログ」「auditログ」をCloudwatchLogsへ転送設定

  <参照資料>
   設定手順:CloudWatch エージェント設定ファイルを手動で作成または編集する
   採取対象メトリクス一覧:Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス
   procstatについて:procstat 向けの CloudWatch エージェントの設定

{
  "metrics": {
    "namespace": "CWAgent-test",
    "append_dimensions": {
      "ImageId": "${aws:ImageId}",
      "InstanceId": "${aws:InstanceId}",
      "InstanceType": "${aws:InstanceType}",
      "AutoScalingGroupName": "${aws:AutoScalingGroupName}"
    },
    "metrics_collected": {
      "cpu": {
        "resources": ["*"],
        "measurement": ["cpu_usage_idle", "cpu_usage_iowait"],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": ["used_percent"],
        "metrics_collection_interval": 60
      },
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "procstat": [
        {
          "exe": "httpd",
          "measurement": ["pid_count"],
          "metrics_collection_interval": 60
        }
      ]
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/audit/audit.log",
            "log_group_name": "audit",
            "log_stream_name": "{ip_address}"
          },
          {
            "file_path": "/var/log/messages",
            "log_group_name": "messages",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

image.png

⑤AWSコンソールより「Systems maneger」⇒「RunCommand」

⑥ ④で作成したパラメータをインプットに実行
・コマンドドキュメント:AmazonCloudWatch-ManageAgent
・Action:configure
・Mode:ec2
・Optional Configuration Lovation:AmazonCloudWatch-linux-config(④で作成したパラメータ)

image.png
※設定を行ったメトリクスが取得できたことを確認
image.png

1-3.メール通知用SNS作成

①AWSコンソールより「SNS」⇒「トピック」
image.png

② ①で作成したトピックに紐づくサブスクリプション作成
image.png

1-4.CloudWatch Alermの作成

①AWSコンソールより「Cloud Watch」⇒「アラーム」⇒「1-2.CloudWatch Agentの設定にて採取対象としてプロセス用メトリクスを選択」

②メトリクス検知条件を設定
条件:「1より低い」を設定
 →0であればプロセスダウンを意味し、死活監視として検知設定

image.png

③「1-3.メール通知用SNS作成」にて作成したSNSをトリガーとして設定
image.png

③以下アラーム名を設定
アラーム名:Cloudwatch-Process-Alarm
※本アラーム名はEventBritgeの検出条件に使用
image.png

2.【死活監視検知/自動復旧】の実装

※「1.【死活監視検知/メール連絡】の実装」が完了している前提とします。
 また、メール通知が不要な場合は、「1-3.メール通知用SNS作成」をスキップして、
 Cloudwatchアラームのトリガーとして設定しなければOKです。

2-1.EventBritge設定

①AWSコンソールより「EventBritge」⇒「ルール」⇒「ルールを作成」

②イベントパターンを以下設定値の通り設定
・作成のメソッド:カスタムパターン
・イベントパターン:以下jsonファイル参照

<設定したイベントパターン>
「アラーム名:Cloudwatch-Process-Alarm」にてステータスが「OK」から[ALARM]に変更されたときに検知できるよう設定
イベントパターンに使用できるイベントはサポートされているサービスからの CloudWatch Events イベントの例を参照

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"],
  "detail": {
    "alarmName": ["Cloudwatch-Process-Alarm"],
    "state": {
      "value": ["ALARM"]
    }
  }
}

image.png

③ターゲットを以下設定値の通り設定
・ターゲットタイプ:AWSのサービス
・ターゲットを選択:System Manager 実行コマンド(RunCommandのこと)
・ドキュメント:AWS-RunShellScript
・ターゲットキー:InstanceIds(タグをターゲットとする設定も可)
・ターゲット値:i-0daf1e81fa39ce4ab(ターゲットとなるインスタンスID)
・Commands:★ここでプロセスに沿った再起動シェルを入力★
 ※今回は「httpd」を想定している
image.png!

2-2.検証

①現在のステータスが「OK」であることを確認
image.png

②プロセスを止め、ステータスが「Alarm」となったことを確認
image.png

③ステータス検知のSNSが登録したアドレスに届いたことを確認
image.png

④ステータスが「EventBritge」がトリガーされプロセス起動コマンドが実行されたことを確認
 ※RunCommandから実施成功履歴を確認
image.png

⑤プロセスが自動的に再起動され、現在のステータスが「OK」となったことを確認
image.png

その他補足事項

・エージェント導入サーバの以下ファイルディレクトリ配下に、適用中のエージェント設定ファイルが格納されている。
 /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d

終わりに

今回はAWSサービスだけでプロセス監視の実現をしてみました。
システムとしてプロセス監視の導入を検討している方の参考になれば幸いです。

8
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?