エンジニアの園田です。して公開したので、その説明のポストとなります。github.com昨日の小ネタ記事はこちらです。ノウハウに依存し、属人化してしまいます。外部サービスの場合、ホスト課金も増えてしまいます。弱く、ホスト自動登録を行うためには(ノウハウ自体はありふれているが)標準機能にないハックが必要となります。)も検討しましたが、どうせ監視システムの運用コストがかかるなら内製してしまえ!とカッとなって実装した次第であります。運用監視の要件として、ホストごとの監視を必須とする場合(官公庁とかだとよくある)にもマッチするかと思われます。タグにそのファイルへの参照を設定します。インスタンス削除時も同様に、タグから定義を参照して当該アラームを削除します。説明だけだと意味不明だと思いますので、実際の監視設定手順を書きます。監視定義ファイルを格納するバケットを作成こちらは既存のバケットでも構いません。サンプルがあるので、それを利用します。インスタンスに付与するタグを追加します。起動済みのインスタンスに対して監視を適用する場合はインスタンスにも直接タグを付与する必要があります。介さずに動作確認を行う場合もインスタンスにタグを直接付与してください。アップロードしたオブジェクトのキー(ファイル名)を設定することで、インスタンスと監視定義を紐づけます。緊急通知用と通常通知用の2つのトピックを作成します。トピック名はなんでも構いません。"system-notification"トピックが作成できたら、適当なメールアドレスをサブスクリプションとして登録しておきます。コマンドがインストールされていない場合はインストールしてください。aws-sam-cliソースをパッケージングします。ソースアーカイブがアップロードされます。テンプレートとしてコンパイルされます。コマンドを実行します。パラメータを渡す必要があります。設定されているパラメータ以外は必須になります。コンソールから直接実行してみます。関数の画面から、「テストイベントの設定」を開いて、空のイベントデータを設定します。生成されていることが確認できます。以上が簡単な監視定義の適用手順となります。モデルのスキーマについて説明がありますが、より詳しい説明を書きます。監視定義ファイルは以下のようになっています。テンプレートになっていることがわかります。監視といっても、そのインスタンスの用途によって監視内容は様々です。いうサービスでも異なるメトリクスに対する複数の監視定義が必要になることが多々あります。それらについて、共通の監視定義を毎回実装するのは運用上避けたいので、他の監視定義をincludeすることで定義の継承を可能としています。ステータスチェックの監視テンプレートがあるとします。インスタンスで利用したい、というユースケースの場合、以下のようにアップロード済みの監視定義を継承することができます。]ステージング環境など、緊急通知を送信したくないインスタンスに対しては以下のように緊急通知だけを除外した定義を利用できます。AI・機械学習チームの笹川です。いう...2019-03-27GAE/Goで技術書典むけのダウンロードカードアプリを作ったエンジニアリンググループの滝安(@juntaki)です。月別アーカイブ注目記事はてなブログをはじめよう!m3techさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。