AWSでのログ監視メール送信はサブスクリプションフィルタ + Lambda + SNSを使用するのがスタンダード。みんなやっていそうなことだが未経験だったのでやってみた。基本参考にしたのは王道クラメソさんの記事だったが、ちょっとわかりにくいところがあったので他の記事も合わせて参照して若干やり方変えつつ検証した。 今回はマネコン作業メインでやったが、CLIやTerraformなどAPI経由で実装する場合追加作業が発生するため注意が必要。(後述 補足事項に記載) 参考 CloudWatch Logs を文字列検知してログ内容をメールを送信してみた サブスクリプションフィルター版 【AWS】CloudWatch Logsからシステムログをメール通知する。 CloudWatch Logs のサブスクリプションフィルタを使って特定文字列を検知したログをEメール通知する ※CLI実装例 以下は今後の参考用 CloudWatchLogsの内容をフィルタリングしてLambdaで通知させたい ※除外キーワードをコードで記述する例 CloudWatchLogsからLambda経由でログメッセージを通知する ※Terraform実装例 処理概要 CWLにログが出力される CWLのサブスクリプションフィルタでキーワード検知 Lambda関数起動 SNSに連携される メール通知 作業概要 SNSトピック作成〜サブスクライブ Lambda用IAMロール作成 Lambda関数作成 ロググループ/ログストリーム作成 ロググループにサブスクリプションフィルタ作成 （配信先に3.のLambda関数を指定） テストログ送信〜メール通知確認 ※ログストリーム作成は検証時のみ。通常は自動生成される。 今回の検証に使用したアイテム（個人メモ） アイテム 名称 SNSトピック log-monitor-topic Lambda用IAMロール send-log-filter-role Lambda関数 send-log-filter-function サブスクリプションフィルタ send-log-filter やったこと SNSトピック作成〜サブスクライブ 過去記事:AWS EventBridge + SNSからのメール件名をカスタマイズするに書いたので省略。ここではCLIでやってるけどマネコンでも特にハマるところはない。アクセスポリシーはデフォルトにした。 Lambda用IAMロール作成 とりあえず以下のマネージドポリシーをアタッチ。 CloudEatchLogsFullAccess AmazonSNSFullAccess Lambda関数作成 (1) 参考ブログのコード貼り付け import base64 import json import zlib import datetime import os import boto3 from botocore....

昨年の過去ツイのスレッドでちょっと気になるのを見つけたので、若干手を入れてここにまとめて書いておく。 暴力の加害者に対して被害者が好意を抱く「ストックホルム症候群」と567脳、マスク厨の心理は似てないか？側から見ると、あの人たちは自由や人権を奪われている今の状況を愛しているように見える。 その裏では「認知的不協和の解消」が発生している可能性がある。これは、自分の内部の矛盾に一貫性を持たせようとする機能。「新しい生活様式」だの、自粛しろマスクつけろだの、不自由で不本意な状況を強いられているが、それを受け入れている自分に葛藤が生じているはずなのだ。 だからマナーだの何だの言って正当化している。または無意識に自分を麻痺させている。どちらにしても認知に修正を加えて不協和（矛盾）を解消しようとしているわけで、つまり認知に歪みが発生している。だから苦痛さえ感じなくなっているのではないかと想像する。 それから、「沖縄から貧困がなくならない本当の理由」（樋口耕太郎著）からの引用なのだが、こういった自己防衛の心理も働いているかとも。 人間は激しい痛みを感じると、自分の感覚を鈍らせて自己防衛を図る性質があるが、それは絶望の耐え難い痛みを和らげるために、自分自身に打つ麻酔のようなものだ。 自分に麻酔を打って思考や身体感覚を麻痺させたり、自ら認知を歪ませれば、見かけ上は苦痛が和らぐ。しかし同時に生きる上でのあらゆる喜びもまた、感じることができなくなる。そして本来あるべき自分の自由と権利を、忘却の彼方に押しやっている。それは虚構の世界を生きているだけなのだ。 …と、まぁ当時はこんなことを思いつくままに呟いてみたが、大半の世間のコロナ恐怖脳はここまで複雑な心理の綾などなく、自分で調べたり考察することもなくひたすら垂れ流される情報を鵜呑みにして怖いね怖いねと決まり文句を言ってるだけのように見える、それが世間の掟だから。 もちろん、マスク・アルコール消毒・検温や在宅勤務を強制または半強制されることに疑問を抱くこともない。一切の疑問も抱かずに、受け入れているのだ。昼の外食時に周りから聞こえてくる会話を聞いていると呆れる、それなりに一流と呼ばれる企業に勤めていてある程度の地位についていそうな人たちが、そんな具合なのである。 まぁ何にせよ、認知の歪みが生じていることは確か、40度近い真夏日に病気でもないのにマスクとか異常でしかないよ。 それから「家庭内ストックホルム症候群」という言葉もある。児童虐待やDVを受けている被害者が、自分を虐待・無視などで苦しめる親や配偶者（多くの場合夫）に不満や憎しみを抱きつつも、見捨てられたらどうしようと、過剰な不安や恐怖心が芽生える。そこで無意識の内に親や配偶者が気に入られるように「良い子」「良い妻」を演じてしまう…ということらしい。 いやでもこれって別に、ストックホルム症候群という名称を持ち出すまでもなく、より普遍的な事象だと思うな、人間が暴力・抑圧・嫌がらせに対して自分の心を麻痺させて適応を試みる心理が働くのは、きっと人間のデフォルト機能なんだよ、悲しい機能だけど。 DVの他に大学内の教授と生徒の間に発生する「アカハラ」、職場のパワハラでも同様の状態になるよね、理不尽なハラスメントを受けているのに、それを客観視できない状態にあると、相手に気に入られようとして相手に従い、相手の意に沿うように行動してしまうんだ。 これには2つの要因がある、生き延びるための生存本能と、他者に愛されたい、承認されたいという、ヒトとしての社会的本能。しかしそれで相手がハラスメントを辞めるかと言ったら逆だ、「こいつはいじめれば何でも言うことをきく」と思われてエスカレートするだけだ、全く本質的な解決にはならず、状況が悪化するだけなんだよ。 ここまでの文章は、今年2021年の1月に別のブログに投稿した内容を編集・加筆したものだ。そこに置いておいても塩漬けになるだけだからこっちに持ってきた。文章中に登場するツイは、とうにアカウント削除したので今は存在しない。「家庭内ストックホルム症候群」から先は今回追記したもの。主旨が途中からずれている気がするが、まぁ気にしない。 Twitterなんか最低のクソメディアだと思うが、ふと思いついて書いたことでも後でこうして振り返って考察することもあるから、そういう意味では少しはやる価値あったかな。 結局何が言いたいのかってね、多くの人間は、ハラスメントを受けている最中は、状況を客観視できないんだよ、かつ、生存本能と社会的本能のためにその状況に適応しようとして、自分を押し殺してハラスメントをする相手や周囲に従ったり、意に沿わない行動をとったりしがちなんだ。これは自覚しないといけないし、あらゆるハラスメントには声をあげ、全力で抵抗しなけりゃいけないんだ、それこそ、羊や奴隷ではなく、主権を持った人間として生きるために。 過去記事にも書いたDylan Thomasの詩の一部。本来の詩の主旨は違うけど、今のこの世界に対して、全く同じことを言いたいね。 Do not go gentle into that good night, Rage, rage against the dying of the light. あぁまったく、俺はやっぱりこのまま死ぬわけにはいかねぇ、大人しく従ってちゃダメなんだ、激怒して、憤怒して、死にもの狂いで抵抗しなくちゃいけないんだ。

Mac上のpython3。しばらく前にhomebrewと一緒に削除してしまったので入れ直した。 $ brew install python3 $ which python3 /usr/local/bin/python3 $ python3 -V Python 3.9.7 $ pip3 -V pip 21.2.4 from /usr/local/lib/python3.9/site-packages/pip (python 3.9) pythonだけで実行するとゴニョゴニョ言われる。 $ python Your PYTHONPATH points to a site-packages dir for Python 3.x but you are running Python 2.x! PYTHONPATH is currently: "/usr/local/lib/python3.9/site-packages:" You should `unset PYTHONPATH` to fix this. $ unset PYTHONPATH で、この後pythonを実行すると2系になってしまう。 $ python WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software....

あー、マジやべぇ、息が詰まりそうだ、いろいろと、勘弁してくれよもう的な動きが多くてさ、めっちゃやり辛い。まじで、10月入ってからすげえやり辛くなった。鬱屈がたまってどうしようもねぇ。 しばらく前から通勤時に英文小説読む余力もないし、Tumblrやり過ぎるとDVT症候群で頭痛と目眩がするし、イヤホンで大音量で音楽聴きすぎて耳がイカレそうだし、もう何を支えにしていいかわからないな、オレは生き延びることができるんだろうか？ そりゃ仕事があるだけありがたい立場だってことは忘れちゃいけないけどね、もし今「戦争」状態じゃなかったらいつでも出ていけるんだからな、なにせ俺様能力高いからな。 うん、そのつもりでやっていくしかねぇ。

10月25日の明け方に見た夢。コンサート会場みたいなところ。そこはロンドンである。観客が大勢いて賑わっている。そしてノーマスク。「あぁ、マスク圧解禁されたのか！」と嬉しい。よく見ると数人はマスクしている、でもほぼノーマスク。あぁ。 もうずっとリアル世界で不快なものしか見てないから、せめてここだけでも。これくらいいいだろ….

表題の件、通知メールの件名はわかりやすいのにしたいよねというニーズに対応すべく、以下参考に試してみた。やったことはほぼこちらの記事の通り。 Amazon SNS で送られる CloudWatch Events ルールの通知内容をカスタマイズする 上記の通りやっていけばできるんだけれど、整理するためにも自分用に記録残す。ちなみに2021年10月現在、CloudWatch EventsはEventBridgeになっている。移行期間中だからまだ違和感があるが、この記事では名称は「EventBridge」とする。それと後半で書いているが、今回の事例ではCloudTrailが有効になっていることが前提なので、現状無効の場合は有効にしておく。 各種リソースに類似の名称が多くて混乱するので、これも自分用に整理。以下、今回作成したリソース名称。 アイテム 名称 SNSトピック custom-event-notification Lambda用IAMロール custom-event-mail-role Lambda関数 custom-mail-function eventルール custom-mail-rule ではここから作業内容の記録に入る。 SNSトピック作成 $ aws sns create-topic --name custom-event-notification サブスク（サブスクリプション）作成 $ aws sns subscribe --topic-arn arn:aws:sns:ap-northeast-1:my-account-id:custom-event-notification --protocol email --notification-endpoint [my mail address] { "SubscriptionArn": "pending confirmation" } 指定したアドレスにメールが届くので、リンク押下してconfirmする。その後マネコンのSNS画面を見るとサブスクのステータスがconfirmedになっているはず。 または、以下確認コマンド $ aws sns list-subscriptions-by-topic --topic-arn arn:aws:sns:ap-northeast-1:my-account-id:custom-event-notification ここからLambdaの作業に入る。最初にLambda用のIAMロールを作成。以下の内容で信頼ポリシー用のJSONファイルを用意し、それを指定してロール作成実行。 trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } $ aws iam create-role --role-name custom-event-mail-role --assume-role-policy-document file://trust-policy....

CloudWatchLogsからS3へログをエクスポートする。基本的に以下の通りにやればできるのだが、説明が冗長だったりわかりにくいところがあるので自分用に書いておく。IAMユーザ作成の手順とかいらん。親切のつもりだろうけど、無駄に記事が長くなって読む気が失せる… コンソールを使用してログデータを Amazon S3 にエクスポートする 概要。ログストリームのエクスポートはログストリームの画面ではなく、ロググループの画面から行う。事前にログエクスポート専用S3バケットを用意し、ドキュメントの通りにバケットポリシーを設定しておく。適当なランダム値のプレフィクスを作成し、バケットポリシーに反映する。バケットにオブジェクトロックがかかっていると動作しないので注意。 バケットポリシーサンプル { "Version": "2012-10-17", "Statement": [ { "Action": "s3:GetBucketAcl", "Effect": "Allow", "Resource": "arn:aws:s3:::my-app-logs", "Principal": { "Service": "logs.ap-northeast-1.amazonaws.com" } }, { "Action": "s3:PutObject" , "Effect": "Allow", "Resource": "arn:aws:s3:::my-app-logs/sjh6dert3a/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } }, "Principal": { "Service": "logs.ap-northeast-1.amazonaws.com" } } ] } 上記前提条件が整った上で、以下実行する。カッコ内は英語表記の場合。 対象のログストリーム画面上で、「アクション」(Actions)のプルダウンから、「データをAmazon S3に エクスポート」(Export data to Amazon S3)を選択。 次画面でバケット名、作成しておいたS3のプレフィクス名、ログストリーム、時間の範囲指定を行い、「エクスポート」実行 エクスポート先のS3では確かzip化された状態で格納されていたと思う。 ドキュメント中の表現一部「ランダムに生成されたプレフィクス」、これがわかりにくかった。ログエクスポート先のS3にランダム文字列のプレフィクスが存在するのが望ましいようだ。なぜ普通の文字列ではなくランダム値が望ましいのかはよくわからん。「生成されたランダム文字列」と書かれているもんだから、どこで生成してるんだ？と混乱した。これは自分で適当に決めた値でよい。 上記に書いた作業は必要に応じてアドホック的に行う対応であり、定常的対応であればLambdaなりshellなりでバッチ化するだろう。 追記 ということで、Lambdaによるログエクスポートの記事書いた。 CloudWatch LogsからS3にエクスポート(Lambda/Python)