表題の件、以下の過去記事に書いたが、この時点では送信される本文ががログメッセージだけとなっていて、通知メールとしては不十分なため本文もカスタマイズしてみた。 CloudWatchLogsのログ監視 - サブスクリプションフィルタ + Lambdaでメール送信 各種設定は冒頭の過去記事と同様のため割愛するとして、コードは変更前・後両方載せておく。 変更前：lambda_function.py(1) import base64 import json import zlib import datetime import os import boto3 from botocore.exceptions import ClientError print('Loading function') def lambda_handler(event, context): data = zlib.decompress(base64.b64decode(event['awslogs']['data']), 16+zlib.MAX_WBITS) data_json = json.loads(data) log_entire_json = json.loads(json.dumps(data_json["logEvents"], ensure_ascii=False)) log_entire_len = len(log_entire_json) print(log_entire_json) for i in range(log_entire_len): log_json = json.loads(json.dumps(data_json["logEvents"][i], ensure_ascii=False)) try: sns = boto3.client('sns') #SNS Publish publishResponse = sns.publish( TopicArn = os.environ['SNS_TOPIC_ARN'], Message = log_json['message'], Subject = os.environ['ALARM_SUBJECT'] ) except Exception as e: print(e) 参考...

elaborate 複雑な、入り組んだ 精巧な、精密な 入念な、苦心の末の 他動詞としては「〜を詳しく調べる」 Irvine Welshの"Trainspotting"読書中に登場した単語だと思うが、何ページかはもう覚えていない。

AWSで過去普通にやってた監視実装も、2,3年経つと（或いはそれより短い周期で）陳腐化する。以前は限られたサービスのリソース範囲でやれることをやっていればよかったが、今はSSM(Systems Manager)、Lambda、EventBridgeなどの「登場人物」が増えて、カスタマイズが可能になったからだ。やれることが増えた分、実装が複雑になる。その分チャレンジングな分野になって楽しめると言えないこともないが…、時間が足りないんだ。頭痛ぇな、まったく。絡み合った糸をほぐすためにまとめてみる。 監視の種別としては大枠としてノード監視、閾値監視、ログ監視、プロセス監視、イベント監視と想定する。それぞれの実装方式が若干異なってくるため整理したい。 監視方式大枠 ノード監視 CloudWatchアラーム(ステータスチェック) ー＞ (EventBridgeルール) ー＞ Lambda ー＞ SNSトピック ー＞ メール送信 ※ハード障害等でインスタンスが落ちた時に発動される想定。手動で落とした時は発動しないので通知は来ない。 閾値監視 CloudWatchアラーム（閾値チェック） ー＞ (EventBridgeルール) ー＞ Lambda ー＞ SNSトピック ー＞ メール送信 ※EC2インスタンスのCPU使用率、ディスク使用率を想定。メモリ監視は別途カスタムメトリクスの実装がいる。 ログ監視 CloudWatchLogsでログ出力（サブスクリプションフィルタキーワード検知）ー＞ Lambda ー＞ SNSトピック ー＞ メール送信 ※これだけEventBridgeを使用しない。 プロセス監視 EC2インスタンス上のプロセス数監視に相当する。検索すると「プロセス落ちていたらインスタンス再起動」アクションの事例が多いが、今回やりたいのはメール通知だけ。一応メモっておくけど。 CWエージェント + SSM + インスタンス停止、Lamabdaなし EC2上のプロセスを監視し自動復旧する CWエージェント + SSM + 自動再起動、Lamabdaなし AWSでプロセス監視を実装したい CWエージェント + Lamabda + SSM + 自動再起動 EC2のプロセス監視と自動再起動 procstat事例 以下はSSMを使用せず、procstatプラグインを使用してプロセス監視する例。記事には監視設定以降の通知イベント事例はなし。 CloudWatch Agent でProcstatプラグインの利用が可能になりました SSMを使わずCloudwatchでEC2上のプロセス監視をしてみる 以下は途中まで参照したところ（後半は有料サービスの案内）、アラームを作成するところまでわかりやすかった。であれば、閾値監視と同様にEBルールを挟んでLambdaをターゲットに指定 ー＞ SNSトピックに渡されてメール送信、でいけるはず。 CloudWatchでプロセス監視する手順をLinuxとWindowsともに詳しく紹介 イベント監視 イベント発生 ー＞ (EventBridgeルール) ー＞ Lambda ー＞ SNSトピック ー＞ メール送信 ※1....

タウリンの効果。過去に見つけたネタをバラバラにメモっていたのをまとめておく。 タウリンとは、一言で言うと。 タウリンは分子量124の含硫アミノ酸。タンパク質の構成成分にはならないが、細胞内の遊離アミノ酸としてはグルタミンと並んでもっとも高濃度に存在し、かつグルタミンに類似する成分。またタウリンは脳内のアミノ酸の中では2番目に多く存在する。 タウリンは疲れが溜まっていると多く消費される、年齢を重ねると減少、男性より女性が不足しがち、とも言われている。 タウリンの効果としてはアセトアルデヒトの代謝促進による肝機能サポートがよく知られているが、記憶力や認知能力の改善、目の網膜の保護、便通の改善等、意外な効能もある様子。 そんなタウリンの効果について、とりあえず箇条書きで。 神経伝達、海馬の増強や安定化をサポート。 記憶力に関与するグリア細胞の活性化を促進する。(注1) アルコールや有害物質から発生するアセトアルデヒトの代謝を促進する。 心筋を強くして疲労回復を促す。（ただし即効性はないらしい？） 心臓のポンプ作用を高めて筋肉により多くの血液を送り込み、持久力を高める。（ドイツの研究より） 細胞のミトコンドリアの数を増やす（ミトコンドリアのタンパク質合成に必須）(注2) 目の網膜や角膜を保護する。 腸管の抗炎症作用 血圧や血糖値のバランスをサポート。 肝臓・心臓の機能強化 胆汁を生成し、コレステロールや中性脂肪の代謝をコントロール インスリン分泌促進 便の水分を増やし、便秘を改善する。 ニューロンのカリウム除去をサポートし、ニューロンが過度に活発化することを防ぐ。 タウリンはレシチンと併用することで細胞の細胞膜を丈夫にし、細胞が正常な形状を保つようにサポートをする。 髪の毛の成長にも不可欠なタンパク質IGF-1(インスリン様成長因子)を増やす (注1) 記憶を司ると言われる海馬にはグリア細胞が多く存在する。 また以下のように認知機能の改善を示す研究がある。 迷路試験（Y-maze test）と受動的回避試験（passive avoidance test）で、タウリンを摂取したマウスの認知機能が正常な状態に回復することが確認された。さらに、アルツハイマー病の症状である大脳皮質の炎症が抑えられたほか、脳の海馬から分泌されるアミロイドベータの量も減り、記憶力に深く関与するグリア細胞の活性化が促進されることが確認された。 注目すべき特徴は、タウリンの脳機能改善効果がアルツハイマー病において選択的に表れるということだ。従来の治療薬物が正常のマウスでは脳機能の異常を来たしたのに対し、タウリンは正常のマウスで脳機能の異常を来たすことはなかった。タウリンの持つもう一つの特性は、タウリンが脳の血管壁を透過しやすいため、口から摂取しても脳にうまく吸収されることだ。別途の複雑な投与過程を経る必要がなく、飲料水などの食物からタウリンを摂っても効果が高い。 タウリンがアルツハイマー病治療に有効だと判明 (注2) 「ただしタウリンが細胞内のエネルギー生産組織であるミトコンドリアの数を増やすのは、タウリン サプリを継続的に数か月～半年ほど摂取した場合に限られます。」（参照リンクは消滅） タウリンを多く含む食材 貝・甲殻類（サザエ、牡蠣、帆立、蛤、あさり、しじみ、タコ、イカ、カニ等） ブリやカツオの血合い 鯵や鯖などの近海魚 タウリンを多く含む食材としてはタコ・イカのイメージが強かったのだが、ダントツで多いのは牡蠣だった。100g中1180mg。サザエの方が100g1500mgで含有量としては多いが、摂取量・摂取回数は一般的に考えて少ない。 余談だが牡蠣は亜鉛も多く含んでいて、その亜鉛はグルタミン酸興奮毒性（神経細胞死の一因）から脳を守る機能を果たす。また、記憶を司る海馬には最高濃度の亜鉛が存在する。脳の海馬をサポートするタウリンと亜鉛を両方含む牡蠣は、最強ブレインフードだった！ タウリンを多く含む食品一覧 ポイントは魚介類と血合肉 タウリン摂取時の注意 食間・空腹時の摂取が有効。 アスピリンと併用しないこと。（薬理作用を増強させてしまうため余計な負担がかかる。バファリンは原材料としてアスピリンを含む） …と、万能選手的なタウリンではあるが、日本国内ではタウリン単体のサプリメントは販売されていない。このためタウリンのサプリはiHerbで時々購入しているが、在庫切れのことが多く割と入手困難ではある。日本の薬事法に規制があって、一回で購入可能な量・個数が制限されているから、まとめ買いもできないのだ。（おそらく鷲のマークの製薬会社の圧力） iHerb独自ブランドのタウリンサプリが安価で嬉しいけど、数ヶ月前から在庫切れ状態が続いている。しょうがないから、今日別の高いやつをポチってしまった。

CloudWatchアラーム + SNSトピックでメール飛ばす時の件名を変更したい。ということで、過去記事 AWS EventBridge + SNSからのメール件名をカスタマイズする でイベントからのメール通知でやったことを、アラームに変えてやってみた。アラームのトリガーはEC2インスタンスCPU使用率閾値超えとする。 ベースの参照は以下クラメソさんネタ。ただしこちらは本文のカスタマイズであり、件名は変えていない。またLambdaも使用していない。これに先の過去記事パターンを合体させてやってみた。 CloudWatch アラームの通知メールを少しでも読みやすくしたい 処理概要 CloudWatchアラームのステータスがALARMに変わる。 Lambda関数起動 SNSに連携される メール通知 作業概要 SNSトピック作成〜サブスクライブ CloudWatchアラーム作成 Lambda関数作成（Lambda用IAMロールは既存流用） EventBridgeルール作成 EventBridgeルールのターゲットに3.のLambda関数を設定する 対象EC2インスタンスのCPU負荷を上げてアラームステータスにする メール通知確認 検証に使用したアイテム アイテム 名称 SNSトピック alarm-notification-topic CloudWatchアラーム CPU_Utilization_Test Lambda関数 cw-alarm-sns-function EventBridgeルール cw-alarm-rule やったこと SNSトピック作成、Lambda関数作成は冒頭のリンク過去記事でもやったので省略。Lambda関数の環境変数でSNSトピック、メール件名を指定している。一応後半にスクショあり。 CLIよりCloudWatchアラーム作成。少ない負荷でもアラームステータスになるように閾値は10%にしてある。 $ aws cloudwatch put-metric-alarm --alarm-name "CPU_Utilization_Test" \ --metric-name "CPUUtilization" \ --namespace "AWS/EC2" \ --statistic "Maximum" \ --period 60 \ --evaluation-periods 1 \ --datapoints-to-alarm 1 \ --threshold 10 \ --comparison-operator "GreaterThanThreshold" \ --dimensions "Name=InstanceId,Value=i-0xxxxxxxxxxx9" EventBridgeルールの作成。以下の場合、“CPU_Utilization_“を含むアラームと関連付けられる...

職場とか、いろんなチーム・グループの中で、「この人がいてくれると安心」「いてくれるだけでいい」と思える人が稀にいる。本当に、稀に、だが。そういう人と、その他の人々の違いは一体何なのか、とモヤっと不思議に思っていた。若干解明できそうなのが、以下の記事。ここに書かれている要因だけではないと思うが、理由の一部としては納得できる。 「いるだけでチームの雰囲気をよくする人」の口癖4つ。“ど” から始まるあの言葉がかなり使える （以降軽くNSFW画像あり。閲覧注意） 記事では「いるだけでチームの雰囲気をよくする人」の4つの要素を述べている。 「ちょうどよかった」悪い状況にある時でもポジティブに捉える 「ありがとう」を言う時に別途感謝の言葉を添える どの、どのように、どちらか、等「ど」ではじまる質問で相手の話を引き出す 「教えてください」で相手へのリスペクトの気持ちを表す 上記のうち、1.と2.は他の自己啓発系コンテンツでもよく目にする話なので割愛する。まぁ「感謝の言葉を出し惜しみしない」、これは確かに大事だよ、俺も実践してる。相手によるけどね。 3.は、俺はこれは実践する気ないけど、要するに聞き上手になって相手の気分をよくしてやれ、つうことだ。 ハーバード大学の研究論文（2012年）によると、自分の話をしているとき、おいしい食事をするときや収入を得るときと同じように脳の報酬系という部位が活性化したことが、 約300人の脳をfMRIでスキャンした結果からわかったのだそう。私たちが聞き上手な人に好感を抱くのは、「自分の話をするのが好き！」という人間の本能を満たしてくれるからなのかもしれません。 「上手に質問をすれば共感力が上がり、相手に好感を抱かせることができる」につながる、と。俺は「聞き上手ボランティア」をやる気はさらさらないが、興味深いのは先の引用にある「自分の話をするのが好き！という人間の本能」だ。よくいるよな、人の話は全然聞かないで、延々と自分のことを話したがるやつ。（ま、経験上女に多いという傾向は、ある） 俺は今までそういうやつのことを、ただ自己愛が強くて、その自己愛を充足させるために他人に自分話を押売りして聞かせているもんだと思っていた。しかし上記引用で、「自分の話をしているときに脳の報酬系が活性化する」というのを読んで「そうか！」とひらめいた。脳の報酬系とはドーパミンのことである。ドーパミンは快楽を司る神経伝達物質だ。つまり自分のことを話すのは、人類共通の快感だったのだ！ まぁ確かに、自分だってそういう面があるのは認めるよ。よく「話を聞いてもらってスッキリした」って言うもんな。何で話すだけでスッキリするのかって、ちゃんと理由があったんだな。しかしこれも度がすぎると聞かされる相手が迷惑だし、みっともないという自覚はある。自分のことを延々と話す人は、その制御が効かなくて、自らの快感原則に従って暴走しているんだろう。プラス自己愛もあるだろうけどね、どっちにしろこの手の人間とは遠い距離を置きたいものである。相手だけ満足して、自分はエネルギー吸い取られるだけだからな… 話が大分脱線した、本来の主旨に戻る。うまい質問の仕方。「ど」で始まる疑問符がキーらしいが、具体的には記事の引用を俺なりにアレンジすると以下のようになる。（仕事関連の想定じゃないとピンと来ないもんで…） キーワード 質問例 What ー＞「どう、どんな」 どんな理由でこの仕事を始めたんですか？ Who ー＞「どの人、どんな人」 どんな人と仕事してみたいですか？ When ー＞「どんなとき、どのタイミング」 どんなときに達成感を感じますか？ Where ー＞「どこに、どこで」 どこでその分野を学んだのですか？ Why ー＞「どうして」 どうしてその製品に人気が集中するんでしょうね？ Which ー＞「どれ、どっち」 どちらのアイデアが気に入りましたか？ How ー＞「どうやって、どのように」 どのようにしてその課題を解決したんですか？ 自己愛満々野郎の自分話を聞かされるのはゴメンだが、まともな相手とのコミュニケーション手法としては頭の片隅においておこう。 人はだれでも、自分に助言を求めてくる人の見識を高く評価する （We all admire the wisdom of people who come to us for advice.） ー 19世紀のイギリスの作家 アーサー・ヘルプスの言葉 最後の「教えてください」。これは相手を間接的に褒める手法だそうだ。ほぉぉ。 ブリガム・ヤング大学助教授で、組織の対人関係を研究するケイティ・リルエンクイスト氏らは、「助言を求められることは、基本的に嬉しいことだ」と言います。 なぜなら、助言を求める行為には、暗黙に「あなたの考えや価値観を支持している」というメッセージが含まれるから。 「教えてください」とアドバイスを求めることは、相手を立てることと同様の意味をもつのです。 これはわかる気がするな、同じ助言の依頼でも「教えてくれくれ」的に無作法または横暴に聞かれると不愉快でしかないが、リスペクトの気持ちを込めた依頼は、相手の気分をよくすることができる。 そこには「あなたは私が知らない知見/情報を持っていると思う、あなたのその知恵を私に分けて貰えたら非常にうれしい」という、メタメッセージが込められているんだ。そういうメッセージを受け取って悪い気分になる人間は滅多にいない。 まぁ自分今もいろいろ思うことがあってこの記事を書いているわけだが….、まったく関係なく、ふと別の言葉を思い出した。 村上龍の小説「5分後の世界」に登場するミズノ少尉は、「絶対に最悪の事態を想像するな」と言った。俺はミズノ少尉のような器ではない。けど、ミズノ少尉のような存在をリスペクトするし、こういう人物と一緒に仕事ができたら嬉しいし、（それこそ、いてくれるだけでいい）少なくとも自分もミズノ少尉に近づけるように努めたいとは思う。 何か主旨が散逸してしまい、「いてくれるだけでいい人」の理由は解明されていない気がする。まぁ理由は他にもいろいろあるよね、ということで。

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