Azureダッシュボードを使って監視センター(っぽいもの)を作る
この記事は日本最大級の青少年団体のイベントアプリを開発・運用した話の中の監視部分に関する記事です。 はじめに Azureはとても便利です。それはスケーラブルなリソースを使いたい時に使いたいだけ使えるというのもそうですが、そのリソースを監視する環境もいい感じに構築できるという意味でもあります。 今回はAzureのダッシュボードにApplication Insightsのグラフなどの情報を使用してグラフィカルな監視センターっぽいものを構築する方法をご紹介します。もっといい方法があれば教えてください。 ↓実際に運用した監視センター（っぽいもの） 簡単な原理 ダッシュボードに表示したい情報をピン留めしてそのダッシュボードを常時表示しておけばいいだけです。 問題 しかし上記には問題があります。 セキュリティ 常時ダッシュボードを表示しておいてはリソースがいじり放題です。 問題解決のためのポイント こ
モニタリングツールの十分類とポートフォリオ - Qiita
はじめに さて、みなさんは監視ツールは何を使っていますか？ Zabbixですか？ Prometheusですか？ あるいはDatadogでしょうか？ Mackerelとかを使ってる人もいらっしゃると思います。 それとは別にNew RelicやDynatrace、InstanaのようなAPMを使ってる人も多いと思います。他にも分散トレースとしてOpenZipkinやJaegerを使うこともありますよね。あるいはこれらに加えてログ分析としてKibanaを入れてるケースもあるでしょうし、アラート管理にPagerDutyを入れてることもありますよね。 では、それらのツールの使い分けはどうされていますか？ それぞれが単機能なら話は簡単ですが多くのツールは色々な機能をもっており「似たようなツールをすでに入れてますよね？」どれか一つ例えばPrometheusだけあれば大丈夫でしょうか不十分でしょうか？ と
Terraform で Newrelic の通知設定をする - Qiita
世の中にまるで 3rd party 資料がなかったので書いておく。 参考文献 Provider: New Relic - Terraform GitHub - terraform-providers/terraform-provider-newrelic: Terraform New Relic provider REST API calls for New Relic Alerts New Relic API Explorer Provider (api_key) の設定 New Relic には API Key が３種類ある: REST API Key: Account Settings > API Keys から作成 User API Key: Account Settings > Users and Roles > User > (例: sonots) > API Keys から作
AWS CloudTrail - Qiita
1.AWS CloudTrailとは？ 「いつ誰が何をしたのか」を記録しておいてくれるサービスです。 2.特徴 デフォルトでOnになっている。 90日間保存できる。（90日以上保存させる場合は、S3に保存させるようにする。） S3の保存先はS3でバージョンニングを有効にするか、クロスアカウントなどを利用することを検討する。 5分おきに作成される。 3.イベント履歴 「イベント履歴」をクリックしてみましょう。 CloudTrail はデフォルトで有効になっているため、今まで行ってきた「サインイン」や「IAM ユーザーの作成」などもすべてイベントとして記録されています。 このようにCloudTrail では何も設定しなくても、デフォルトで過去90日間のイベントが無料で記録されています。 今後もし「消した覚えがないのにサーバが跡形もなく消え去っている！」というようなことがあったら、先ずCloud
衝撃！！サーバ監視ツールの値段を徹底分析 〜Datadog, CloudWatch, Mackerel, MetricFire〜 - Qiita
衝撃！！サーバ監視ツールの値段を徹底分析 〜Datadog, CloudWatch, Mackerel, MetricFire〜CloudWatch監視MackerelDatadogMetricFire サーバ監視と言っても、色々なツールがあるのは事実です。機能面で比較しようとしても、結局、名の知られている監視ツールでは、視覚化、アラート、API、インテグレーションなど、そこまで大きな差はなく、どれも素晴らしい機能を保持しています。 結局、導入を決定するにあたり、最終的に気になるところは値段ではあると思うのですが、今回の記事では、MetricFireの顧客の平均データ量である150,000メトリック（約800ホスト）を基準とした場合、Datadog, CloudWatch, Mackerel, MetricFireのそれぞれの監視ツールで一体どれくらいの価格の差が生まれるのかを検証していき
DatadogとNew Relicを比較してみる - Qiita
What's ? サービスのシステム移行に伴って監視SaaSの選定を改めて行うために、監視SaaS界隈でトップを争うdatadogとnew relicの比較しました 監視対象はAWS EC2やECSなので、AWSに特化して比較しています [余談] Qiita::Teamに書いていたのですが、大部分が公開してもいいような内容だったので公開します 公式サポートしているAWSサービス EC2周りは両方のSaaSでサポートしています LambdaとFargateの一部に関して、New Relicの公式ドキュメントに説明がありませんでした(自分の調査不足だったら申し訳ない) DatadogのFargateに関するドキュメントでは具体例が記載されていたりして、コンテナ周りのサービスに力を入れているのかなぁなんて思ったりもしました AWS Datadog New Relic
Dockerコンテナのメトリクス監視してますか？ - Qiita
どうも僕です。タイトルどおりです。 Dockerコンテナのメトリクス監視してますか？？？ 本番環境ならDataDogとかそのへんで監視していてもローカル環境のやつ確認してないこと多くないですか？ ※ 僕はしてないです。dd-agentローカルにも入れれば終わりじゃんって話なんですが、なんかあれじゃないですか。。。 監視してなかったお陰で、高負荷時に突然死する原因を調査したい場合に、無事頭を抱えました。(原因はメモリ枯渇してた) そこで、コンテナ名, コンテナID, CPU, MEM, NET RX/TX, IO R/W, PIDS 情報が見れたらいいのになーを調べてたらさくっと見れることに気づいたので記事にまとめておきます。 やりたかったのはこういうやつです。 本家の付随機能を利用する コンテナのリソース使用状況をライブで流し続ける 使い方
Kubernetes のメトリクスを Prometheus を使って監視する - Qiita
また, Prometheus 自体は監視対象の Kubernetes クラスタ上に構築するものとします. Prometheus の構築 始めに Kubernetes クラスタ上に Prometheus を構築します. $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/service.yml $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/deployment.yml $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/k
ruby on railsでShoryukenを使うときにGod(神様)を使って監視をする - Qiita
aws: access_key_id: "hogehoge" secret_access_key: "hogehoge" region: "ap-northeast-1" concurrency: 25 delay: 5 queues: - ["sqs_queue", 1] RAILS_ROOT = File.expand_path(File.dirname(__FILE__) + '/../') God.watch do |w| w.name = "shoryuken" w.env = { 'RAILS_ROOT' => "#{RAILS_ROOT}", 'RAILS_ENV' => "development" } w.start = "cd #{RAILS_ROOT} && bundle exec shoryuken -R -C ./config/shoryuken.yml -L ./
Google Cloud MonitoringでCompute Engineインスタンスを監視する - Qiita
Google Compute Engine のインスタンスの監視をどうするかはサーバ管理者の悩みのタネだと思います。 sensuを入れたりMackerelを入れたりDataDogを試してみたり…選択肢は色々あると思うんですが、今ならGoogle Cloud Monitoringがオススメです！！！ Google Cloud Platform 運用管理 - Cloud Monitoring 編 というブログエントリに非常によくまとまっていますが、僕の方でもいくつか補足しながら解説したいと思います。 できること CPU Usage, Memory Usage, Disk Usage, Disk I/O, Network Traffic, Open TCP Connections, Processes などの基本的なシステム情報の監視 プロセスの死活監視 エンドポイントにHTTPリクエストを送っ
はじめてのCloudWatch（AWS） 〜カスタムメトリクスを作って無料枠でいろいろ監視する〜 - Qiita
EC2のサーバ監視にCloudWatchを初めて使ってみました。 カスタムメトリクスを作って、CPU使用率、HttpStatus、Memory使用率、LoadAverageの監視を行うようにしたので、手順をまとめておきます。 CloudWatchは無料枠で10メトリクス、10アラームまで設定できるとのことなので嬉しいですね。 以下、公式サイトより引用 無料利用枠* Amazon CloudWatch は無料で始めることができます。アプリケーションの多くは、これらの無料利用枠内で利用できるはずです。 Amazon EBS ボリューム、Elastic Load Balancers、Amazon RDS DB インスタンスのすべてのメトリックス同様、Amazon EC2 インスタンスの基本モニタリングのメトリックス（5分間隔）は無料でご利用いただけます。 新規および既存のお客様は、10メトリック
S3のアクセス状況を可視化してみる - Qiita
きっかけ 先月CloudFrontのアクセス数などはCloudWatchで見れるようになりました。 しかしS3のアクセス状況はそのようなMetricsがなく、ログを解析するしかありません。 アクセス規模が小さくてEMRを持ち出すほど大げさではない場合、lambdaで処理すれば楽に可視化まで持って行けるのではないかと考えました。 実装 lambda2cw ログファイルがPUTされた時にフックして、ログを解析してCloudWatchのカスタムメトリクスとしてPutMericDataを行います。 想定としては、bucket内のlogs/ から始まるキーがログファイルとなります。 デモ 負荷を発生 適当にabで負荷をかけます。 $ while [ 1 ] ; do ( ab -c 4 -n $(echo $[ $RANDOM % 100 ]) http://lambda2cw.s3-us-west
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Prometheus + Grafana を Mac 上で docker-compose で起動 - Qiita
Raspberry Pi を Mackerel で監視する - Qiita
https://qiita.com/la_luna_azul/items/505ca441b8c8e6a87aaa