SQS、ElastiCache、Lambdaで作る高可用なアラート通知システム | GREE Engineering
インフラのいわほり（@egmc）です。 サーバ監視を構成するシステムは色々ありますが、今回はAWS環境上での監視に使われているアラート通知の仕組みについて紹介させて頂きます。 監視システムの構築そのものは2015年頃、AWSの本格的な利用に伴い、AWS環境を対象とした新規システム（AWSモニタリングシステム）の構築プロジェクトにて作成されたものですが、稼働から約2年が経過し、それなりに実績が積めてきたのではないかと思います。 通知システムにはYusuraという名前がついていて、機能的には過去のエントリで紹介されていたAWACSに近いものとなります。 主な機能としては 設定に基づいた通知先の振り分け アラートの集約(summarize) 同一アラートの抑制（suppress） インスタンスのタグ情報に基づいたignore処理（特定のタグがついているインスタンスを通知の対象とする） を行います
CloudWatch + SQS でバッチサーバー冗長化のために実装した「sqsjkr」の話 - KAYAC engineers' blog
Lobiの吉村(moulin)です。今回はCloudWatch + SQSのバッチサーバ冗長化のために作成した「sqsjkr」についてご紹介します。また、sqsjkrはGo実装です。 github.com 目次 背景 sqsjkrについて 運用について 背景 バッチサーバーとは、マシンリソースの消費が高い処理を定期的に実行させたい場合、本体アプリケーションに影響が及ばないようにするために建てられるバッチ処理専用のサーバーを指し、Lobiでも様々なバッチ処理を実行するサーバーを建てています。 バッチサーバーはcrontabが設定されているものが1台、バックアップとして同じ構成でcrontabが設定されていないものが1台起動しており、cronを実行するサーバーに障害が発生した場合は、手動でcrontabをバックアップのサーバーに設定することでフェイルオーバーする運用をしていました。 しかし、バ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
