前のブログの続きで、もにかじ7で話した小ネタその2。 実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます？って話です。 まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。 ※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。 でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。 そうすると、 『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』 みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか？ みんななんかやってますか？ というようなことを参加者に聞いてみました。 参加者の中では、AutoScalingしてい
CloudWatchがあればZabbixとできること大して変わらないし 「CloudWatchでだいたいの要件は満たせそうですね。」 とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。 統合監視ができる CloudWatchはあくまでもAWSの中の事象だけを見ます。 しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、 クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。 そういった場合すべてを統合的に見られる監視ツールが必要となります。 またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。 たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを
本日、Mackerelをベータ公開しました。 Mackerelは、ウェブアプリケーションのパフォーマンスとインフラを管理するための新しいサービスです。 Mackerelとは Mackerelは、次のような問題を解決することを目指しています。 複数のサーバのリソース状況を効率的に可視化 各種ツールと連携することでサーバ情報の多重管理を解消 複数のクラウド環境を一元管理 リソース消費状況を可視化するだけではなく、APIによる各種ツールとの連携で、開発と運用の自動化をより促進させていきます。 詳細は、下記のリンクからどうぞ。 利用開始 https://mackerel.io/ja/ ヘルプページ https://mackerel.io/ja/docs/ 正式化に向けて ベータ期間中は、すべての機能を無料でご利用いただけます。正式版では無料でご利用いただける範囲に制限がつきます（料金などの詳細は正
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
