全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
初めてFargateを触ったので、運用保守の観点で構築時に設定しておいた方が良いポイントをまとめました。 デプロイの自動化と書いているのにデプロイの話薄めになってしまいました…。 こちらはJAWS-UG朝会 #28で発表したものになります。
とある同僚経由で、AWSユーザーのお客様から言われたこと... "AWS CloudWatchと同じようにAzureの標準サービスで監視したい!" というわけで、仮想マシンに関して、AWS CloudWatchで監視できる基本的なメトリックを基準に、Azureの標準サービスでの監視を考察してみます。 まず最初に、AWS CloudWatchとAzure Monitorの主要な機能を比較してみます。 利用料金が発生するトリガーが異なりますが、あとは大きな差は無いように思います。 次に、AWS CloudWatchの基本モニタリングで監視可能なメトリックスを基準にして、Azure Monitorで監視可能なメトリックを列挙してみます。 Azureの場合、"NetworkPacketIn"と"NetworkPacketOut"のようなNICが送受信したトラフィックについては、Azure Moni
渡辺です。 現在のEC2のデフォルト機能では、EC2インスタンスのメモリ使用量をCloudWatchで確認することはできません。 ですが、AWS CLIと簡単なスクリプトを使えば、Custom MetricsとしてCloudWatchに表示することができます。 ただし、一般的なLinuxのメモリ使用量であればシェルスクリプトで簡単に取得できるのですが、TomcatなどのJavaのアプリケーションサーバではもう一手間必要です。 Javaでのメモリ管理の仕組み Java(JVM)はヒープ領域というメモリを仮想マシンの内部に確保し、ヒープ領域の中でインスタンスなどを割り当てる仕組みになっています。 したがって、OSから見たJavaのメモリ消費量を見ても、それはJVMが確保しているヒープ領域の使用メモリ量です。 内部的にどの程度メモリを消費しているかは解りません。 JVMのヒープ領域がどの程度メモ
CloudWatchがあればZabbixとできること大して変わらないし 「CloudWatchでだいたいの要件は満たせそうですね。」 とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。 統合監視ができる CloudWatchはあくまでもAWSの中の事象だけを見ます。 しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、 クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。 そういった場合すべてを統合的に見られる監視ツールが必要となります。 またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。 たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを
○:標準で使えます ×:標準で使えません 補足 1.リソース監視の監視項目 CloudWatchはデフォルトでメモリー使用率やディスク使用量、ロードアベレージがないので必要であればカスタムメトリクスとして追加する必要があります。監視項目は以下のページをご覧ください。 [CloudWatch]グラフの確認方法と確認できるグラフ一覧(EC2/ELB/RDS) Zabbixエージェント - Zabbixオフィシャル日本語サイト 2.Zabbixからフルマネージドサービスを監視 ZabbixではRDSやELBのリソースを監視する機能はありません。Zabbixでフルマネージドサービスを監視したい場合はCloudWatchから値を取得するスクリプトを実装する必要があります。 ZabbixでAWS/CloudWatchの値を取得してみた 3.カスタムメトリクスを使えば可能 カスタムメトリクスの追加方法は
追記 リポジトリの名前を以下の通りに変えたのと初回のみ Alarm 設定が出来るようにしてみた。 cloudwatch-agent 上記をインスタンス上におく Chef の Cookbook も後からアップする予定。 何番煎じ? か解らないくらいだが必要に迫られてインスタンスリソースをCloudWatch のカスタムメトリクスを投げるスクリプト書いた。 ググると Java 版の CLI ツールを使った例は良くみるのであえて Python 版のコマンドラインツールを利用することにした。 おソース github inokappa/resource2cloudwatch リソースと言っても 以下が取ってカスタムメトリクスに送る。 CPU 使用率 Load Average メモリ使用量(メガ) Root パーティションのディスク使用量(メガ) こんな感じ なんで CloudWatch なの? なん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く