AWS 白帯シリーズ(14) fluent-plugin-cloudwatch-logs を使って CloudWatch Logs にログを送ってみる | iret.media
cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。 追記（2014/07/24） export AWS_REGION=us-east-1 が引き継がれず service コマンドから td-agent が起動出来なくなる件ですが、@repeatedly さんにご指摘頂き /etc/sysconfig/td-agent に export AWS_REGION=us-east-1 を追加することで service コマンドにて td-agent の起動、再起動が出来ることを確認しております。 @repeatedly さん、有難うございました！ はじめに 先週、各インスタンスのログを CloudWatch に収集することが出来る CloudWatch Logs というサービスがリリースされました。CloudWatch Logs に関する情報は下記を
AWS 白帯シリーズ(8) Amazon CloudWatch Logs を日本で 12 番目位に試してみる | iret.media
cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。 追記（2） 今回試した手順は以下のドキュメントを参考にしてセットアップしました。 Quick Start: Install and Configure the CloudWatch Logs Agent on an Existing EC2 Instance 追記 勝手に CloudWatch Logs Q&A をやってみます。 コストは？ 現時点では下記のように記載されておりました。 $0.50 per GB ingested $0.03 per GB archived per month** 無料ではないようです！ アーカイブの仕様は？ コストにも絡むことですが…こちらを抜粋させて頂くと… Data archived by CloudWatch Logs includes 26 byte
Fluentd を使って CloudWatch のメトリクスを Graphite で見れるようにする | iret.media
cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。 はじめに CloudWatch は AWS で標準で利用出来る監視ツール メトリクスを収集してマネジメントコンソールがグラフの表示を確認出来たり Alarm を作成することでしきい値を超えた場合等の通知等も行える 但し、メトリクスの保存期間が 2 週間に限られている為、長期レポーティングが必要な場合には別の方法でメトリクスを蓄積する方法を検討する必要がある 今回は Fluentd のプラグイン 2 種類を利用して CloudWatch から Graphite にメトリクスデータを蓄積して Grafana のカッコイイ画面でグラフを見るような流れを作ってみる 作業にあたって fluentd とは fluentd もはや説明不要の泣く子も黙るログ収集ソリューション Graphite と Graf
cloudpackブログ - NagiosのCloudWatchプラグイン(Python版AWSコマンドラインツール版)
以前、「NagiosのCloudWatchプラグイン(PHP版)」にてNagiosでCloudWatchのメトリックスを監視する プラグインを作りましたが、 「Python版AWSコマンドラインツールでCloudWatchのメトリックス情報を取得」にて 紹介したようにPython版AWSコマンドラインツールが利用できるようになりましたので、 そちらを利用する形で上記プラグインを作り直してみました。 プラグインは、下記のようになります。 # cat check_cloudwatch #!/bin/sh . `dirname $0`/utils.sh set -e trap 'echo "UNKNOWN: $?"; exit $STATE_UNKNOWN' ERR WARN=0 CRIT=0 REVERSE=false while getopts c:w:n:m:d:s:r OPTNAME;
cloudpackブログ - Python版AWSコマンドラインツールでCloudWatchのメトリックス情報を取得
表題の件に関して、今回取り扱う課題は以下になります。 –dimensionsの指定方法 dateコマンドのフォーマットと時刻(相対的)の指定方法 jqの出力のダブルクウォートを削除("10"→10) Python版AWSコマンドラインツールでCloudWatchのメトリックス情報を取得する方法は下記の通りです。 # aws cloudwatch get-metric-statistics > --namespace AWS/EC2 > --metric-name CPUUtilization > --dimensions '{"name":"InstanceId","value":"i-xxxxxxxx"}' > --statistics Average > --period 60 > --start-time `date -u -d '10 minutes ago' +%Y-%m-%dT
cloudpackブログ - AIDEで改竄検知した情報をCloudWatchで管理する
以前紹介した記事でAIDEで改竄検知した情報をFluentdでまとめることができましたが、 グラフ化やアラート通知(閾値超え)を素早く行うため、CloudWatchでデータを管理したいと考えました。 そこで以下のツールを利用して実現してみます。 suz-lab.github : fluent-plugin-clooudwatch_ya インストール等は、以前紹介した「FluentdのCloudWatchプラグイン(fluent-plugin-cloudwatch_ya)を RubyGems.orgに公開してみた」を参照下さい。 冒頭で紹介した記事ではAIDEでの改竄検知情報を下記の形式ログへと調整しました。 2013-02-09T22:41:46+09:00 parsed.syslog {"total":"384","added":"2","removed":"2","changed":"
cloudpackブログ - CloudWatchのコマンドラインツールでDynamoDBの統計情報作成
以前、DynamoDBをIAMでアクセス制限の記事を紹介しました。 我々の業務では、実際のテーブル設計に比べ運用後のリソース管理が気になります。 DynamoDBの良いところはスループットが保障されるというところがありますが、設定した値が 保障されると言う意味であり、その値が適切でない場合は当然レスポンスが悪くなってしまいます。 また、それを恐れるあまり、値を大きくしてしまうと、後々請求額に驚くことになります。 スループットの値は変更が効きます。 そこで今回はDynamoDBの稼動統計を行うために情報取得をしてみます。 ○情報取得方法 AWSでは稼動情報を見る事ができるCloudWatchという機能があります。 こちらはEC2やRDS等AWSで扱っているサービスの情報を全て取得できるので、 動きがおかしいと思った時は、ManagementConsoleからグラフ化されたものを見る事もできま
cloudpackブログ - CloudWatchをチェック(Read/Write)するNagiosプラグイン
CloudWatchをチェック(Read/Write)するNagiosプラグインを下記のように作ってみました。 #!/bin/sh . `dirname $0`/utils.sh WARN=wrire CRIT=read while getopts c:w:n:r: OPTNAME; do case "$OPTNAME" in w) WARN="$OPTARG" ;; c) CRIT="$OPTARG" ;; n) NAMESPACE="$OPTARG" ;; r) REGION="$OPTARG" ;; *) echo "UNKNOWN: Usage" exit $STATE_UNKNOWN ;; esac done aws --region=$REGION --output text --endpoint-url=http://monitoring.$REGION.amazonaws.
cloudpackブログ - DataCounterプラグインとCloudWatchプラグインの連携(再び)
近頃いろいろと試していたFluentdのCloudWatchプラグインですが、(仕様の)紆余曲折を経て FluentdのCloudWatchプラグイン(fluent-plugin-cloudwatch_ya)をRubyGems.orgに公開してみたの 記事のようにRubyGems.orgに公開しました。 下記で紹介してきた記事の内容も対応できるよう調整していた為、改めて最新のもので同じ事を実現してみようと 思います。 (上記の記事の方法でfluent-plugin-cloudwatch_yaはインストール済みとします) dstat(fluent-plugin-dstat)の情報をCloudWatchに登録してみた FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた(UPDATE2!) FluentdからCloudWatchのカスタムメトリクスにデータを登録して
cloudpackブログ - FluentdのCloudWatchプラグイン(fluent-plugin-cloudwatch_ya)をRubyGems.orgに公開してみた
下記一連の記事でアップデートしてきた、FluentdのCloudWatchプラグインをRubyGems.orgに公開してみました。 既にfluent-plugin-cloudwatchは登録済みだったため、プラグイン名を fluent-plugin-cloudwatch_ya(Yet Another Plugin for Amazon CloudWatch)としました。 dstat(fluent-plugin-dstat)の情報をCloudWatchに登録してみた FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた(UPDATE2!) FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた(UPDATE!) FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた ソースはGitHubになります。 インストール
cloudpackブログ - FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた(UPDATE2!)
以前紹介した記事(「 FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた(UPDATE!) 」)を 更にアップデートしてみました。 ○変更点 DataCounterの一つの集計ログからCloudWatchへ複数のデータを登録可能に DataCounterは一つでよい(patternNで区別) Dimensionをタグ(Tag)からキー(Key)に変更 KeyにはpatternNのキーを登録 ○設定ファイル(/etc/td-agent/td-agent.conf) type tail format syslog path /opt/suz-lab/var/log/syslog/all.log pos_file /opt/suz-lab/var/lib/td-agent/pos/tail.syslog.pos tag tail.syslog type copy t
cloudpackブログ - dstat(fluent-plugin-dstat)の情報をCloudWatchに登録してみた(その2)
これまで下記のようにFluentdを使ってCloudWatchのカスタムメトリクスにデータ登録作業をしてきました。 FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた(UPDATE2!) FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた(UPDATE!) FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた 今回は、fluent-plugin-dstatの紹介の記事のプラグインで取得したデータを、CloudWatchに登録してみました。 (CloudWatchプラグインを汎用化するための目的もあります) 最終的にはCloudWatchは下記のような状態になります。 (Load Avarageの1分平均をCloudWatchに登録) ○dstatとfluent-plugin-dstatのインストール #
cloudpackブログ - FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた(UPDATE!)
本記事は少し古いものになりますので、新しい情報は「FluentdからCloudWatchのカスタムメトリクスにデータを 登録してみた(UPDATE2!)」を参照下さい。 以前の記事(「FluentdからCloudWatchのカスタムメトリクスにデータを登録してみた」)にて仕組みと それを実現するFluentdのプラグイン(out_cloudwatch.rb)を紹介しました。 今回は、それを更に次のようなことができるようにアップデートしてみました。 ※historyはbashのHistoryログが対象です。 また、auditはauditdのAuditログが対象となります。 上記の紹介記事からの改良点 複数のDataCounterプラグインで集計をした結果を、一つのCloudWatchプラグインでデータ登録 できるように。 一つのCloudWatchプラグインで、複数のカスタムメトリクスを対象
cloudpackブログ - Python版のAWSコマンドラインツールでCloudWatchのカスタムメトリクスにデータ登録
以前、「Python版AWSコマンドラインツールをCentOS6で使ってみた」の記事を紹介しましたが、 今回は、このコマンドラインツールを使ってCloudWatchのカスタムメトリクスにデータを登録してみました。 まずは登録するデータをJSON形式で用意します。 # cat test1.json { "metric_name": "Test Metric", "timestamp" : "2013-01-13T12:03:55+0900", "value" : 300, "unit" : "Count", "dimensions" : [ {"name": "InstanceId", "value": "i-aaaaaaaa"} ] } # cat test2.json { "metric_name": "Test Metric", "timestamp" : "2013-01-13T12
cloudpackブログ - CloudWatchのDetailed Monitoringで追加される機能
CloudWatchでDetailed Monitoringを有効にすると、EC2のモニタリングの間隔が1分毎になることは よく知られていると思います。 実は、それだけではなく、Dimensionと呼ばれるメトリクスをグルーピングするような機能も追加されます。 基本的にはAmazon Elastic Compute Cloud Dimensions and Metricsの記事に記載されています。 まずは、Detailed Monitoringを無効(Basic Monitoring)にしている状態で、インスタンス毎にメトリクスが 選択できます。 Detailed Monitoringを有効にすると、さらに下記のようにグルーピングされたメトリクスを選択することができます。 ○Aggregated Across Instances 全インスタンス(Detailed Monitoringを有効
cloudpackブログ - NagiosのCloudWatchプラグイン(PHP版)でRDSの監視
NagiosのCloudWatchプラグイン(PHP版)を実際に利用の記事でEC2のCPU使用率が監視できるようになったので、今回はRDSの監視をできるようにします。 RDSで監視する項目は、実装の都合上(後述)下記としています。 CPUUtilization DatabaseConnections SwapUsage Nagiosのコマンドは、下記のように設定します。 # RDS CPUUtilization define command { command_name check-cloudwatch-cpu_rds-cloudpack command_line /opt/cloudpack/nagios/check_cloudwatch -f /opt/cloudpack/conf/$HOSTGROUPNAME$/credential.yml -n AWS/RDS -m CPUUtil
cloudpackブログ - NagiosのCloudWatchプラグイン(PHP版)を実際に利用
少し時間が経過してしまいましたが、NagiosのCloudWatchプラグイン(PHP版)で作成した NagiosのCloudWatchプラグインを実際に利用して、EC2のCPU使用率を監視してみました。 はじめに、下記のようにコマンドを定義します。 define command { command_name check-cloudwatch-cpu-cloudpack command_line /opt/cloudpack/nagios/check_cloudwatch -f /opt/cloudpack/conf/$HOSTGROUPNAME$/credential.yml -n AWS/EC2 -m CPUUtilization -s Average -u Percent -d InstanceId -r ap-northeast-1 -w $ARG1$ -c $ARG2$ -v $
cloudpackブログ - NagiosのCloudWatchプラグイン(PHP版)
以前、@j3tm0t0さんが公開されたNagiosのプラグイン、check_cloudwatchとほぼ同様のプラグインをCloudWatchとの通信をPHPで行うものを作成してみました。 (元祖check_cloudwatchはコマンドラインツールを利用しています) 下記のように利用できます。 # ./check_cloudwatch > -c 20 > -w 10 > -f credential.yml > -r ap-northeast-1 > -n AWS/EC2 > -m CPUUtilization > -s Average > -u Percent > -d InstanceId > -v i-xxxxxxxx CloudWatch CRITICAL - AWS/EC2 CPUUtilization Average InstanceId i-xxxxxxxx: 25.092 P
cloudpackブログ - SQS & CloudWatch & Auto Scaling、その後
SQSとCloudWatchとAuto ScalingのようにSQSとAuto Scalingを使って、 複数インスタンスでクロールする仕組みを運用しています。 はじめは、SQSのキューのサイズをCloudWatchに登録のようにCloudWatchのカスタムメトリクスを使って、 SQSのキューのサイズ(メッセージ数)とAuto Scalingの連携を取っていたのですが、 CloudWatchでSQSのメトリクスが取得可能にのように、 SQSのメトリクス自体が標準でサポートされるようになりました。 上記より、現在はAuto Scalingのトリガーとなるメトリクスはカスタムメトリクスではなく、 標準のSQSのメトリクス(ApproximateNumberOfMessagesVisible)を利用するように変更しました。 現状、下記のような仕組みで処理をしています。 SQSにクロールしたい対
cloudpackブログ - SQSのキューのメッセージが処理されなくなったら通知(CloudWatch)
キューのメッセージが0になったときに通知することは、よくやると思いますが、ここでは、キューのメッセージが処理されなくなったときの通知に関して紹介します。 当然、CloudWatchを利用するわけですが、キューのメッセージが処理されなくなった状態の確認は、アプリケーションが受信したメッセージ数を表す下記のNumberOfMessageReceivedを確認することで可能です。 キューのメッセージが処理されなくなった場合は、NumberOfMessageReceivedが「0」になるはずです。 そして、このNumberOfMessageReceivedに対して、下記のようにアラームを作成します。 ここでは値が「0」になったら(メッセージが処理されなくなったら) アラーム状態になるように設定しています。 メールは下記のように、状態が「ALARM」、「OK」、「INSUFFICIENT_DATA」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
