実例で学ぶモニタリング定例のすゝめ | CyberAgent Developers Blog
この記事はCyberAgent Developers Advent Calendar 2021 11日目の記事です。 みゆっきこと山中勇成(@toriimiyukki)です。普段は、ABEMAで動画配信基盤の開発運用を担当しています。 直近では、配信システムの大規模刷新プロジェクトなどを担当しており、こちらの模様はCA BASE NEXTの発表からアーカイブを閲覧可能です。 ABEMAでは、24時間365日のリニア型配信やVOD配信など、昼夜を問わず落とすことができないミッションクリティカルなサービスを運用しています。サービスを支えるマイクロサービスは、配信分野に限っても20サービスを超えています。 既にPrometheusなど、各種モニタリングソリューションでの監視やアラーティングなども行っていますが、この記事では、あえて手動監視を定期的に行う、モニタリング定例を勧めたいと思います。 な
CloudNativeな決済サービスの開発と2年間の歩み #sf_A4
Spring Fest 2020 CloudNativeな決済サービスの開発と2年間の歩み SBペイメントサービスではSpringとTanzu Application Serviceを使用して、決済システムを運用、開発しております。 以前SpringFest2018で登壇した際は、プロダクション環境で稼働するまでのストーリーをご紹介しましたが、今回はその後の運用や開発についてお伝えしたいと思っています。 本セッションでは導入の背景や、Spring Boot/Cloudを利用したアーキテクチャの説明、CI/CDやロギング・モニタリング、高レジリエンスへの取り組み内容を改めてご紹介します。 またプラットフォームの導入が開発や運用にどのような効果をもたらしたのか、プロダクションでの運用を安定化させるために行ってきた施策や、運用/開発する中で発生した事象とその対処についてもご紹介する予定です。 #
Kuberntes Monitoring 入門 - Speaker Deck
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
Prometheusで収集したメトリクスを使ってCloud Monitoringのダッシュボードを作成する - A Day In The Life
Prometheus で収集した GKE アプリケーションのメトリクスを GCP の Cloud Monitoring(旧Stackdriver Monitoring) にエクスポートして Cloud Monitoring のダッシュボードを作成する方法を紹介します。Prometheus といえば Grafana を使ってダッシュボードを作成することが多いですが GCP 環境では Cloud Monitoring に一元化して監視できたほうが何かと便利です。あえて Grafana を使わず Cloud Monitoring でメトリクスを可視化します。 以下の記事で GKE 上に構築した Redis のメトリクスを Prometheus を使って収集しました。この環境を利用して Prometheus から Cloud Monitoring にメトリクスをエクスポートする方法を紹介します。
GKEをCloud MonitoringとPrometheusでちゃんと監視する - Koichi Ishida blog
目次 Kubernetesの監視は大変 Cloud Monitoringだけで監視はできないか Cloud MonitoringでGKEをちゃんと監視するにはどうしたらいいか どのように実現したか インストール方法 PrometheusとStackdriver Prometheus sidecar Blackbox nodeExporter Prometheusの値をただCloud Monitoringに送るだけでは物足りない Cloud Monitoringでどのように監視できるか 既存のKubernetes Engineダッシュボード Prometheusのデータとともに作成されたダッシュボード 複数環境でダッシュボードをどのように同期するか アラートの設定 まとめ ここ2週間くらい10XでGKEの監視を整えています。2年前にタベリーで監視を整えたときよりだいぶいい感じに作れたのでどの
Microservices時代の監視設計 - An Epicurean
前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。 前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。 モノリシック世界観での監視 アプリケーション監視の浸透 Microservices時代の監視設計 開発者自身が監視する どう監視するか メトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ 例: ある認証コンポーネントの監視設計 まとめ モノリシック世界観での監視 Webサービスの構成が
Peter Bourgon · Metrics, tracing, and logging
2017 02 21 Today I had the good fortune of attending the 2017 Distributed Tracing Summit, with lots of rad folks from orgs like AWS/X-Ray, OpenZipkin, OpenTracing, Instana, Datadog, Librato, and many others I regret that I’m forgetting. At one point the discussion took a turn toward project scope and definitions. Should a tracing system also manage logging? What indeed is logging, when viewed thro
モニタリングするためにどんなデータを集めるべきか - アルパカ三銃士
Datadog のブログで公開されている "Monitoring 101: Collecting the right data" を読んだ。本記事は紹介した Datadog のブログ記事を独自に簡略化したものである。もっと詳しく知りたい場合は Datadog の記事を読むと良い。 記事では次の項目を実現するためにどんなデータを収集し分類するかが記載されている。 自動検知によって潜在的な問題に効果的なアラートを受信する。 素早く調査を行いパフォーマンスに関する原因へ到達する。 Metrics メトリクスはある時点のシステムに関連する値を取得する。通常 1 秒間に 1 回もしくは 1 分間に 1 回など時間の経過とともに監視する。 メトリクスを以下の 2 つのとても大切なカテゴリに分けられる。 Work metrics システムのトップレベルでの health 状態を表せられるメトリクスを指す
go tool traceでgoroutineの実行状況を可視化する - ( ꒪⌓꒪) ゆるよろ日記
こんにちわ。しいたけです。今日はgoroutineの実行状況をいいかんじに可視化するツールの話です。 goのプロファイリングツールと言えば、 runtime/pprof や net/http/pprof ですよね。これらの使い方はググればすぐに出てくるのですが、 詳細なtraceを取得して可視化できる runtime/trace については、日本語の情報が殆ど無いので書いてみましいたけ。 runtime/trace はgoroutineの実行状況やsystem callのイベント、Heapやnetworkの状況をこんな感じに可視化してくれるので便利です。 これは自作のクローラーを動かしている際のtraceを可視化したもので、横軸がタイムラインになっており、上段に Heapの使用状況やgoroutineとos threadの数が, 下段はnetworkやProccesor(GOMAXPROC
サーバーが高負荷状態になったときのプロセス一覧を自動で出力させておく - えいのうにっき
趣味でお世話をしているサーバーインスタンスのうちのひとつが、最近以下のような事象を時折起こしておりまして。 深夜に一時的に高負荷状態に陥る 朝起きてみたらそれに気づく（終息している） さすがに趣味の範疇なので、深夜に飛び起きて対応できるようなアラート通知設定はしておらず、とはいえ起きてからその理由を探ろうとするのだけど、終息したあとに見られるものといったらせいぜい以下のようなことくらい？ モニタリングツール（Mackerel）のその当時のグラフの様子 アプリケーションログを見る /var/log とかに出力されてるログを見る 今回の場合だとCPU使用率とLA（ロードアベレージ）が高騰していたことくらいしかわからずで、そのときにどういうプロセスがリソースを食ってたんだろう、みたいなことは把握することができなかった。 こんなかんじ。diskはちょっとハネてるかな...。。 対象のサーバーには
Web サービスの信頼性と運用の自動化について / iot40-rrreeeyyy
第40回インターネットと運用技術研究発表会の招待講演で『Web サービスの信頼性と運用の自動化について』というタイトルで発表しました。
Mackerel（マカレル）導入事例 GMOペパボ様： 情報を集約してインフラの競争力を高める！ プライベートクラウドへの移行に合わせてGMOペパボが、Mackerelを大規模導入 - Mackerel（マカレル）: 新世代のサーバー管理・監視サービス
Mackerel導入事例 GMOペパボ様 情報を集約してインフラの競争力を高める！ プライベートクラウドへの移行に合わせて GMOペパボが、Mackerelを大規模導入 http://pepabo.com/ 株式会社はてなサービス開発本部ディレクター兼チーフエンジニア松木雅幸 株式会社はてなサービス開発本部プロデューサー杉山広通 GMOペパボ執行役員CTO栗林健太郎さん GMOペパボ技術部 技術基盤チーム柴田博志さん GMOペパボ技術部 インフラグループ高谷雄貴さん インタビュー星暁雄（ITジャーナリスト） 記事公開日： 2016年2月2日 · 所属はインタビュー当時のものです インフラ基盤などの監視に500台弱を導入 自己紹介をお願いします。まず、はてな側から。 杉山 2015年9月からMackerelのプロデューサーをしています。前職は製造系SIで、サーバーやネットワークなど数千台規模
dstatの万能感がハンパない - （ひ）メモ
サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47
監視システムをSensuに刷新した | Ore no homepage
データベースが落ち着いているので、その間に別のことに着手。 チームの監視システムがmonっつー超レガシーシステム。知っている人もいるかもしれないが、monはperl製のシンプルな監視システム。古くからあるものなんだけど「mon perl」で検索すると「もしかして: man perl」とgoogle様にも何だっけソレ？と言われてしまうかわいそうな奴(「mon monitoring tool」だとちゃんと出てくる)。なのでまあこの際だから俺が葬り去ってやる。導入したSensuのバージョンは0.12.6。GW前くらいから運用しているが今んとこ問題ない。まだ運用期間短いね。 割と長文になっちまったので、目次をば。 0. sensu概要 1. なぜsensu？ 2. インストール 3. コンフィグの配置 4. プラグインについて 5. API 6. デバッグ 7. 今後の展望 0. sensu概要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://paperboy-all.github.io/docs/nagios/learning.html
Real-Time Web App Performance Monitoring : New Relic