前記事 AWS ECS Fargate Autoscaling の実戦的な基礎知識 の続きというか派生的なところで、こんな監視項目がこんな理由でえぇんちゃうん、という基礎知識的なお話です。 当ブログでは『監視よければ全てヨシ！』という格言を推していますので、監視の仕込みをサボっている人は今からでも頑張っていきましょう。 はじめに もともと書くつもりでいた本タイトルは、公式からこのドキュメントが出たことで、ゴミ箱行きかと思いました。 推奨アラーム – Amazon CloudWatch > Amazon ECS んが、まぁ所詮はドキュメントということで、ここではもう少し実戦に寄り添う形でまとめていければと思います。 あったら嬉しい監視項目をカテゴリごとに整理しつつ、その理由やら補足情報によって、楽しく監視できるようにしていきたいところです。合わせて読みたいところとしては、この辺もどうぞ。 ミ
はじめに Hi 👋 この記事では SQS を介して Lambda を呼び出す非同期処理の一連の流れを Datadog で可視化する方法を紹介します。 Datadog の提供している Tracer や Lambda Extension Layer については前提知識として解説していきます。 やりかた Python アプリから呼び出す場合は dd-trace-py を使うことで自動計装で Python アプリ -> SQS -> Lambda をトレースすることができます。これは dd-trace-py が SQS を呼び出すクライアントライブラリである botocore の自動計装をサポートしているためです。 では PHP アプリや Go アプリの場合はどうでしょう。実際 PHP で SQS を呼び出す aws/aws-sdk-php は dd-trace-php の自動計装対象ではないで
初めて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
New — File Release for Amazon FSx for Lustre Amazon FSx for Lustre provides fully managed shared storage with the scalability and high performance of the open-source Lustre file systems to support your Linux-based workloads. FSx for Lustre is for workloads where storage speed and throughput matter. This is because FSx for Lustre helps you avoid storage bottlenecks, increase utilization of compute
Image from Datadog はじめに こんにちは。エンジニアのみかみです。DevOpsを推進するための、ビルドツール、CI、監視系の設計や管理ツールの作成を担当しています。インフラエンジニアっぽいですが、実際はチーム内の困ったを拾うキャッチャーで、よろず相談屋をやっています。 さて、今回は監視についてのお話です。 最近、安価で柔軟に使えるクラウドサービスが提供され、新規サービスの開発が容易になりました。 しかし、サービスをリリースしたものの、ある程度サービスが認知されてくると突然システムが故障したり、予期せぬ不具合が突然発生し困ったことはないでしょうか？ サービスの稼働率を100％保証することは技術的に難しく、サーバー稼働率99.9％を保証しているサービスが多いですが、この数字でも年に9時間は停止する計算になります。100%の動作保証が難しいのならば、何時停止したとしても、すぐに
渡辺です。 現在の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アカウントを
・2年で月間10億PVを支えるまで成長した ZenClerkの運用上の工夫を紹介 ・AWSのTipsとあるある話の共有
http://www.lauradhamilton.com/system-administration-at-netflix 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 メディカル分野のアナリティクスサービスを提供しているAdditiveAnalyticsのFounderのLaura Diane Hamiltonが、先日のNetflixのJeremy Edbergのプレゼン（110枚のスライド）をまとめてくれています。かなりの数になったNetflixのオープンソースのプロジェクトの全容がわかるので助かります。 Application Availability Hystrix: サーキットブレーカーのような役割を果たすことで、障害の雪崩現象を食い止め、分散システムの障害耐性を担保。 The Simi
追記 リポジトリの名前を以下の通りに変えたのと初回のみ Alarm 設定が出来るようにしてみた。 cloudwatch-agent 上記をインスタンス上におく Chef の Cookbook も後からアップする予定。 何番煎じ？ か解らないくらいだが必要に迫られてインスタンスリソースをCloudWatch のカスタムメトリクスを投げるスクリプト書いた。 ググると Java 版の CLI ツールを使った例は良くみるのであえて Python 版のコマンドラインツールを利用することにした。 おソース github inokappa/resource2cloudwatch リソースと言っても 以下が取ってカスタムメトリクスに送る。 CPU 使用率 Load Average メモリ使用量（メガ） Root パーティションのディスク使用量（メガ） こんな感じ なんで CloudWatch なの？ なん
AWSを使っていると、Cloudwatchの情報を外部に取り出したくなるのが人情だと思います。 しかし、Cloudwatchの情報取得に関しては、Javaで書かれた「Amazon CloudWatch Command Line Tool」の情報やAPIを叩くツールを自作するような情報が多く、比較的新しいPython版 AWS CLIでの取得方法の情報はあまり見かけません。 AWS CLIは、旧来のツールで必要なJavaのインストールの必要がなく、また、１つのツールを導入するだけで、Cloudwatchを含む、すべてのAWSのサービスが操作可能というメリットがあり、比較的手軽に使うことができます。そのため、できればこちらで済ませたいところ。 ただ、AWS CLIでのCloudwatchは、いくつか癖があり、実際に使えるようになるまでハマったので、使い方をまとめておきたいと思います。 AWS
March 21, 2013 ELBのCloudWatchにあるメトリクスをZABBIXで取得するためにfluentdを利用しました。 これでELBのアラートの設定もZABBIXで行えるので、通知の一元化が行えます。 もちろんZABBIXでグラフにすることもできます。 fluent-plugin-zabbix fluent-plugin-cloudwatch この2つのfluentdプラグインを使います。 td-agent.conf <source> type cloudwatch tag cloudwatch aws_key_id YOUR_AWS_KEY_ID aws_sec_key YOUR_AWS_SECRET/KE cw_endpoint monitoring.ap-northeast-1.amazonaws.com namespace AWS/ELB metric_name H
今っぽい感じのSaaS型監視サービス NewRelicを Amazon Linuxに入れてみる。( Newvem とか Server DensityとかPingdomとかもある） New Relic は、エージェントを監視対象ノードに入れておく点は Zabbix等と変わらないが、監視サーバを構築しないですぐに(無料で)始められる、という点がメリット。 監視対象サーバが少ないシステムだと、監視サーバのコスト・運用負荷がデメリットになるので、CloudWatchを補助する目的で、CloudWatchで取れない Load Average, free memory, Disk UsageといったOS内部の情報をカジュアルに一元管理するのに向いている。 特徴を説明したページはこちら。 Server Monitoring Application Monitoring Real User Monitor
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
