Zenn
✨

#AWS EKSの障害時対応方法を考える-1

2021/03/09に公開
AWS
tech

はじめに

AWS EKSを使ってきて知識が付いてきだしたので自分の整理も兼ねてまとめます。
前提条件などは詳しく書きます。至らぬ点もあるかもしれませんがご容赦ください。

自分が作っているEKSって障害起きたときにどうすんねん！っていうのを初心者ながら考えていく記事です。今回アプリケーションの部分は割愛します。

構成

  1. AWS EKSの障害時対応方法を考える-1
    • ログの収集について記載します。
  2. AWS EKSの障害時対応方法を考える-2
    • ログの分析について記載します。

EKSのログについて考える

EKSのログ、特にEKS基盤に乗っているアプリケーションのログについて調査し、取得する。なおかつそのログを統合的に見えるようにするにはどうすれば実現可能かを考える機会がありました。今回はそれについて考えます。

EKSのログはどこにでるのか

EKSのログは基本的にはcloudwatchで確認します。cloudwatchのロググループにログが吐き出されています。(cloudwatch,FluentDのデーモンセットがデプロイされているものとします。)

今回はtest-demo-eksという名前を作成しました。


その中は以下のような構成になっています。ちなみにアプリケーションはAWSの公式が提供しているものになります。
https://eks-for-aws-summit-online.workshop.aws/010_create_cloud9.html

さてログをみでみましょう

以上のようなログ構成となっています。
これではわかりにくいのでcloudwatch container insightというサービスを使用してみます。

cloudwatch container insight

(ここからはcontainer insightの設定はしてあるものとします)
実際にコンテナインサイトのグラフは次のように表示されます。

もう少したくさんありますが、このようなものがタイプ、Namespace.service,podなどのタイプごとに出力されます。

さてこのような感じでメトリクスが見えるようになりました。
これをもっと細かく関連するログだけ見たい！という時は、cloudwatch logs insightというサービスを用いて、以下のようなクエリを書きます。(クエリは参考です。)

fields @timestamp, @log, @logStream, @message
| filter ispresent(kubernetes.container_name) and kubernetes.container_name like /your-container-name/
| sort @timestamp desc
| limit 50

この画面で叩くと

このような画面になります。(実際は下に関連するログが出ています。)

さてここまでで、ログをある程度可視化するところまで行きました。ここまでである程度見れそうですが、pod全部のログを統合的に見れたほうがいいよなという思いが湧いてきますね・・・

次回の記事で統合的にログを見るための方法について記事化します。

Discussion