継続は力なり

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

AWS Backup Restore testing のジョブ失敗を Slack に通知する

タダです.

AWS Backup Restore testing のジョブが失敗したら通知して監視できるようにしたいと思い,AWS Chatbot を通じて Slack 通知する検証を行いました.その設定をこの記事に記載します.

AWS Backup Restore testing のジョブの失敗通知設定方法

過去記事に記載した方法と同じなため割愛します.

sadayoshi-tada.hatenablog.com

EventBridge でジョブのステートをチェックする

EventBridge で AWS Backup Restore testing のジョブステータス遷移を見ることができ,その中に FAILED があったため,このイベントを SNS トピックを通知してみることにしました.

docs.aws.amazon.com

EventBridge ルールのイベントパターンは以下のように定義しました.加えて SNS トピックのアクセスポリシーは events.amazonaws.com から SNS 通知を許可しました.

イベントパターン

{
  "detail": {
    "status": ["FAILED"]
  },
  "detail-type": ["Restore Job State Change"],
  "source": ["aws.backup"]
}

SNS アクセスポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:ap-northeast-1:[アカウント番号]:[トピック名]"
    }
  ]
}

AWS Backup Restore testing のジョブの失敗通知結果

AWS Backup Restore testing ジョブで IAM 権限を意図的に不足した状態でテストを行ったところ,次のように Slack 通知されました.失敗した理由が Message に記載があり確認できます.

Slack 通知メッセージイメージ

まとめ

AWS Backup Restore testing のジョブ失敗を Slack 通知してみたので備忘録にまとめました.

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

『TechBrew in 東京 〜SRE大集合!信頼性を高める取り組み〜』に参加して各社の信頼性向上の取組みを学んだ

タダです.

TechBrew in 東京 〜SRE大集合!信頼性を高める取り組み〜」に参加してきたので,参加の感想をまとめていきます.

findy.connpass.com

イベント概要と参加目的

「自社では信頼性を高めるためにどのような取り組みを行っているのか?」をテーマのLTで各社の取り組みを共有し合える場

転職以降に他社の事例を聞いたり,話す機会がかなり減ったのを危惧して今回参加させていただきました.

発表のサマリーと感想

各発表ごとにサマリーと感想をまとめていきます.

SREに活かすセルフ・アウェアネス

@syossan27さんによる SRE 文脈でのソフトスキルに関するお話でした.SRE に限らず組織で働くことは組織内で協調していく必要があると思いますし,Indeed 社では求人票に書かれているのは印象的でした.また,ポストモーテムで非難しないのは当然としてなぜなぜ分析をしてしまうと自己嫌悪に陥りやすいため What から入るのも印象的でした.

発表資料

SIEMってサイトの信頼性向上に寄与するの?

@yuta_k0911さんから SIEM を使ったセキュリティログ分析のお話でした.セキュリティログ分析はなかなか手を回すのは後手になりがちな印象がありますが,SIEM OpenSearch を使うことで分析しやすさがあるんだなという学びがありました.そして,分析するだけでなくプロアクティブなアクションにつなげていくことで信頼性向上に繋げる考え方は自分自身,足場を固める活動として日々やらねばと背筋が伸びました.

発表資料

チームと成長するSRE

@maruloopさんから開発者の成長とSREの成長に関するお話でした.自分が所属してきた組織で SRE のメンバーから導入したツールや仕組みなどは属人的になりがちな印象で,それらを如何に他の人に技術伝承していくかが長期的に大事だと思っています.考え方次第ですが,特定の人への負荷集中や人依存につながるのは個人的に良くないと思っていて同じ組織で可能な限り同一のオペレーションをできて全体としてのパフォーマンスが高い状態になったほうが良いかと思います.なので,発表の中での定期ハンズオンや SRE チームが各メンバーごとの多重ワークを許容し議論できる状態にあるのは素晴らしいと感じました.

発表資料

トイル撲滅から始める改善手法とその結果

@yjszk666さんの解決されたトイル撲滅のお話でした.トイル撲滅はむちゃくちゃ喫緊で自分も潰した話があったので共感の嵐でした.中でもトイルを誰もやりたくない仕事と定義してからそれを拾いに行ってから潰すムーブとトイルを潰す空気を作れているのが最高で,改めて自社のトイル撲滅をもっとやって向き合うべき課題の時間捻出に繋げたいと思いました.

関連記事

made.livesense.co.jp

発表資料

ジョインしたてのSREが信頼性向上に取り組む(監視設計編)

KK さんによる監視設計のお話でした.監視設計をビジネスフレームワーク(5W1H)に落とし込んでやっているのは初めて見た切り口ではありましたが,各設計項目ごとに必要な考慮事項が整理しやすくなるかもなと思いました.

イベントレポート zenn.dev

発表資料

ガチめなインフラエンジアから見たSRE

@barieroさんのキャリアで初めて SRE ロールになってからどんなことが求められているかを考察された発表でした.SRE がサービスの信頼性を高めるところを主眼に置いて関わるっていうのは同意で今後の信頼性向上の取組みも気なった発表でした.

発表資料

入社1ヶ月目でSREチームの方針とあり方を見直している話

@ohsawa0515さんによる出向された組織での SRE チーム方針とあり方を見直しているお話でした.技術組織はチームトポロジーに沿った組織体になっていて,SRE チームはプラットフォームの分類になっていたそうです.しかし,様々な課題から現場は各チームに Embeded SRE の形ではいっていき課題解決にあたられています.自分自身もやはり感じるのは課題に取り組みやすくするためにそのチームに所属して一緒に課題を解くことだと思っているため,その後の活動込みでどういう課題改善なされるのか楽しみになりました.

発表資料

Datadog実行基盤をEC2からECSへ移行してみた

@Y0u281さんによる Datadog の実行基盤の移行のお話でした.最初の課題提起から実行基盤を ECS に乗せる過程で得られるメリットとそれに伴う実績コストを評価した上で実行されてて Fact ベースな判断をされていて素晴らしいし,コスト削減にもつながっていて一石四鳥では?と思うほど取り組みでした.

発表資料

懇親会

お酒飲みつつ,各社のお話や雑談をさせてもらって楽しかったです.

全体の記念写真

個別で延長戦させてもらった時の写真

まとめ

久々のオフライン勉強会に参加して各社の取組みを聞くことができて勉強になりました.来週は CI/CD のテーマの勉強会があるので,これも参加してレポートを書きます.

findy.connpass.com

Amazon OpenSearch Service でスローログを有効化しているのにログがでない...?時の解決方法を試した

タダです.

Amazon OpenSearch Service でスローログを有効化しているのに何もログがないって思ったことはありませんか?自分はあります.これでは遅いクエリの分析ができない...そんな状況からログを出すことができたので対処法をまとめていきます.

Amazon OpenSearch Service のログ有効化する方法

そもそも Amazon OpenSearch Service でログを有効化する方法はどのようにするかというと,ドキュメントにコンソール利用の方法と AWS CLI,AWS SDKの記載があり,これに従って設定していきます.

スローログの閾値を設定する

本題ですが,スローログを有効化してもログが出てこないのは閾値を設定してないからです.閾値の設定の仕方はドキュメントに記載があります.つまり,Amazon OpenSearch Service に対して PUT リクエストを送り閾値を設定するということですね.以下,curl でリクエストを送った場合の例になりますが,1秒以上かかるリクエストを WARN ログとして出力する例です.

$ curl -XPUT 'domain-endpoint/index-name/_settings' -H 'Content-Type: application/json' -d '{
"index.search.slowlog.threshold.query.warn": "1s"
}'

関連ドキュメント docs.aws.amazon.com

これで curl domain-endpoint/index-name/_settings?pretty を叩いて slowlog のセクションが出ていれば CloudWatch Logs にスローログが出力されます.

$ curl domain-endpoint/index-name/_settings?pretty
{
  "index-name" : {
    "settings" : {
      "index" : {
        "search" : {
          "slowlog" : {
            "threshold" : {
              "query" : {
                "warn" : "1s"
              }
            }
          }
        }
  ~中略~
}

なお,スローログのフィールド情報は下記ページに日本語記事の解説があり,大変勉強になりました.

www.elastic.co

まとめ

Amazon OpenSearch Service でスローログに何も出ない場合の理由とその対処をまとめました.

CloudWatch Logs のログから秒,分,時間ごとの件数を集計する時にむちゃくちゃ重宝した構文の紹介

タダです.

CloudWatch Logs から時間ごとのログの件数を集計することがあったのを今回の調査で初めて知ったのでまとめておきます.

stas 構文

それは stats 構文で名前の通りログのパターン分析に役立つ役割のようです.下記のクエリでは Exception の件数を5分ごとに集計して降順で表示することができます.

filter @message like /Exception/
| stats count(*) as exceptionCount by bin(5m)
| sort exceptionCount desc

docs.aws.amazon.com

この bin(5m) の値は例えば,1秒毎であれば bin(1s) とできるし,1時間毎であれば bin(60m) とすれば時間の間隔を調整して集計できます.今回自分は,膨大な CloudWatch Logs の中から特定のログパターンで発生したリクエストの件数を集計しレポートする役割を持っていたので,この stats 構文を使っての集計はとても役立ちました.

まとめ

今回は時間毎のログ集計で役立った stats 構文の紹介でした.

SecurityHub の違反してるリソースの検出されたリストを出力する方法をまとめる

タダです.

先日SecurityHub を運用していて違反しているリソースを通知することはやっていてアラートを放置してしまっていたので,その違反の修正を方針を決めてやりました.その際に,違反してるリソースを一覧で出す時の方法を実践して学んだのでまとめておきます.

AWS マネジメントコンソールから出力する場合

マネジメントコンソールから出力する場合は検出ルールの詳細からDownload ボタンを押すと CSV ファイルをダウンロードできます.Compliance Status,Severity,ID, Title, Failed checks , Unknown checks , Not available checks , Passed checks , Custom parameters の順番のカラムで出力されます.

ただ,この段階ではどの AWS リソースで違反が発生しているかはわからないため,個別のチェックツールを詳細で見て Failedステータスのルールを確認すると違反したリソース一覧を確認できるため,これで修正対応をしていくことができました.

AWS CLI から出力する場合

既に検索したら多くの記事が公開されていたのですが,下記の記事を参照させてもらいました.「5. 以下の条件に合致したコントロール数を取得」で利用しているコマンド の部分のコマンドでほしい結果を得られました.

blog.serverworks.co.jp

まとめ

SecurityHub の違反してるリソースを一覧で出す時の方法をまとめました.