こんにちは、@ueokandeです。早速ですが、皆さんが運用しているサービスには、SLO (Service-level objective: サービスレベル目標) がありますか？アラートの監視項目はどのように設定して、基準値をどのように決めていますか？ 社外とのコミュニケーションだけでなく、社内向けのSLOを決めておくことで、サービスの健康状態を知るための手がかりや、普段の開発・運用タスクの優先度を決める上での指標にもなります。 またSLOがあると、サービスを監視するアラートに、理にかなった閾値を設定できます。 この記事ではAWS版kintoneの、SLOとアラートを設定するまでの記録について紹介します。 cybozu.com版kintoneのSLOとアラート 国内のcybozu.comで運用しているkintoneにも、もちろんSLOやアラートはあります。 しかし現状のSLOはkinton
システムの保守・運用を行うインフラエンジニアにとって、障害対応は最も責任のある仕事のひとつであり、障害の監視や通知に関するツールは「PagerDuty」や「Zabbix」が有名です。そうした障害対応を助けてくれるツールとして、Netflixが無料のオープンソースソフトウェア「Dispatch」を公開しました。 Introducing Dispatch - Netflix TechBlog https://netflixtechblog.com/introducing-dispatch-da4b8a2a8072 About - Dispatch https://hawkins.gitbook.io/dispatch/ Netflix Dispatch - Reviews, Pros & Cons | Companies using Netflix Dispatch https://stack
TL;DR 監視はユーザーにサービスを提供できているかを観測するための行為 SLI/SLOを定めて、SLOを守れるようにモニタリングする ダッシュボードは定常的に表示しておくものと障害時に活用するものを作ると良い アラートはレベル分けして人間が対応しなければならないものだけ人間へ通知する 監視とは サービスを健全に動作させ続けるために監視を行います。 「健全に動作している」の定義はサービスによって異なり、ユーザーにWebページを見せることができることだったり、バッチが正常に終了することだったりします。 最終的にユーザーに正常にサービスを提供できていることを観測するために行うことに変わりはありません。 さてユーザーにサービスを提供するために何を監視しましょうか？ クラウド前提であれば個人的にリソースベース（CPU/Memory）より、 SLI/SLOをベース に監視する事が望ましいと考えてい
※ この記事は SRE Advent Calendar 16日目の記事です。 皆さんこんにちは。エムスリーという会社でSREをしている高橋です。 早いもので、今年ももう終わりですね... ！ そこで本記事ではエムスリーのSREチームがこの1年の間に実施してきたSLO設定及びSLO超過監視活動を反省とともにご紹介していきたいと思います！！ エムスリーにおけるSREチームの成り立ち かつてはSREがインフラチーム配下のポジションとして存在しているような状況でしたが、肩書は違えど作業内容はほとんど同じだったので、2018年7月からインフラチームがまるっとSREチームへと改称されました。 www.m3tech.blog SLI/SLO設定/監視 SREとしての活動を考えたときに、まずはサービスレベル目標（SLO）を決めてサービスの品質を改善していきたいと思いました。そこで、まずはサービスレベル指標
こんにちは、エンジニアリンググループ SREチームの高橋(@tshohe1)です。 「入門 監視」という本が各所で話題になっていますが、エムスリーのエンジニアリンググループでも予約購入していました！ www.oreilly.co.jp 監視というSREと非常に親和性の高いテーマの本だったこともあり、多くのSREメンバがこの本に目を通していたようです。 そこでぜひチーム内で感想を共有しようということになり、先日感想共有会が実施されました。 本記事ではそのときに挙がった感想を一部抜粋して公開したいと思います。 モニターリザード 各章の感想 「1章 監視のアンチパターン」について 「第2章 監視のデザインパターン」について 「3章 アラート、オンコール、インシデント管理」について 「5章 ビジネスを監視する」について 「6章 フロントエンド監視」について 「7章 アプリケーション監視」について
はじめに こんにちは、Stackdriver担当者です。本記事は完全に個人の意見です。（念押し） GCP的に担当製品がわかりやすいのでStackdriverの担当と書いてますが、仕事での担当領域的には「オブザーバビリティ (Observability、可観測性)」 です。この「オブザーバビリティ」という言葉が近年SREの文脈で語られることが増え、また今年に入って「入門 監視 ("Practical Monitoring" の日本語訳)」が刊行されたことで、日本でもより多く耳にするようになりました。 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム 発売日: 2017/08/12メディア: 単行本（ソフトカバー） 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julian発売日: 2019/01/17メディア:
Co-authored by Ryan McDowell, fellow Googler and data analysis ninja Visualize GCP Billing using BigQuery and Data StudioOne of the most common questions we get from customers is “how can I see what I’m spending over time” and, up until recently, your only option was the Billing tab in your Google Cloud Console. But now, by combining Google Cloud’s billing-export-to-BigQuery functionality with Goo
Mackerelチームのエンジニアのid:itchynyです。 「mackerel-agentを入れるとloadavgが7時間ごとに上昇する」 先日、このような問い合わせを複数のお客さまから受けました。私も実験してみたところ、確かに再現しました。EC2 t2.microにmackerel-agentを入れて簡単なログ監視とプロセス監視を設定し、数日放置しました。 確かに、約7時間ごとにloadavgが上昇しています。この周期のcronの設定はしておらず、またmackerel-agent内部でも7時間ごとに行う処理はありません。しかし、プラグインを多く入れるほどloadavgのピーク値も上がります。 本エントリーでは、この現象の原因について説明します。 loadavgが上昇する原因を調べるには、まずloadavg自体がどう計算されているかを知る必要があります。 まずは、Linuxがloada
こんにちは。zozoフロントエンド部の大平です。さだまさし好きが昂じて社内では「さださん」と呼ばれています。 計測してますか？ 皆さん計測していますか？ 何かを改善しようとした場合、パフォーマンスを数値化し、その内容をもとに改善案を考えて行動することが、基本的な取り組み方になります。 そして、いかに現状を測定可能な状態にし数値化可能な指標を設定するか、という事が取り組みの第一歩になります。ダイエットや体質改善でもそうですし、英語など語学学習でもそうだと思います。 ということで、計測はとても大事です。 私事ですが、私は最近さだまさしさんのファンが集うコミュニティに参加しています。古くからのファンの方々はさだまさしさんのデビュー時からずっと追っかけている猛者も多く、私みたいな若輩者の青二才は圧倒的な「さだ力」の不足を感じる毎日です。 最近、コミュニティの中で「楽曲検定」というサイトが流行しまし
1.稼働プロセスのindex番号を調べる ●稼働しているプロセスの名前で判断できる場合 HOST-RESOURCES-MIB::hrSWRunName この値を見ると、稼働しているプロセス名の一覧が取得できる。 例1：HOST-RESOURCES-MIB::hrSWRunName.4861 = STRING: "ntpd" ntpdのプロセスが稼働していることがわかる。 この時、indexの番号(4861)が重要なので記録。 ●稼働しているプロセスのパラメータ値で判断できる場合 同じ名前のプロセス名が複数稼働しているが、起動プロセスのパラメータ値が異なっているような場合は下記のようにindex番号を取得する。 HOST-RESOURCES-MIB::hrSWRunParameters 例2：HOST-RESOURCES-MIB::hrSWRunParameters.6419 = STRIN
この記事は、Mackerel Advent Calendar 2017の19日目の記事です。 前日は fullsat_ さんによる Lambdaを使ってMackerelのアラートをRedmineのチケットにする でした。 ウェブシステムの障害発生時に、どのコンポーネントの処理が滞っているかをざっくり知りたいことがあります。 そこで、ウェブシステムは待ち行列の集合体であることに着目し、各コンポーネント状態を把握するダッシュボードを最近作成しています。 待ち行列については、自分もそれほど詳しいわけではありませんが、待ち行列システムをみるとざっと把握できます。 簡単な例として、安定した系であれば、リトルの法則により、平均待ち行列数Lは、平均到着率λと平均待ち時間Wの積に等しいことがわかっています。 リトルの法則とキャパシティプランニング - ゆううきメモ これらのパラメータをウェブシステムでよく
サーバレスアーキテクチャによる時系列データベースの構築と監視
インフラの反田 (@mtanda) です。 GREEでは、多くのサービスをAWS環境で運用しており、それらサービスのモニタリングシステムとしてPrometheusを利用しています。 Prometheusを導入してから約2年がたち、1台のPrometheusで数百台規模のインスタンスをモニタリングするなかで、さまざまな問題に直面しました。 それら問題の原因を分析し、設定や利用の仕方を改善することで、ある程度安定して運用できるようになりました。 これらの知見が少しでもお役に立てばと思い、ここで共有いたします。 なお、対象とするPrometheusのバージョンは1.xです。Prometheus 2.0では、これら問題のほぼ全てに対して改善されています。そのため、2.0でどういった点が改善されているかを知るためにも有用だと思います。 Prometheusのストレージ実装の基礎知識 Promethe
って話を明日のPHPカンファレンスでする予定でした。 PHPカンファレンス、私用のため私の登壇をキャンセルします。楽しみにされてた皆様、大変申し訳ありません。当日登壇予定だった内容はブログに細かく詳細まで記載して公開します。この度は皆様、ご迷惑をおかけします。 #phpcon2017 https://t.co/qgHogswYeI— そーだい@初代ALF (@soudai1025) 2017年10月6日 ここにあるとおり、雨の影響により、子供の運動会が延期になり、PHPカンファレンスと被ってしまいました。そこで色々悩んでいたところ、スタッフの方が気を利かせて連絡を先にくださり、キャンセルさせていただくことにしました。正直年に1度のお祭ですし、会いたい人も沢山いるイベントですから断腸の思いでした。しかも僕は今年各地のPHPカンファレンスに出れなかったので会えていないPHPerの方が多く居ます
はじめに 初めまして、下記の記事にて紹介がありました インフラエンジニアの榎戸です。 golangを使って開発したWebAPIを1年半運用して改善してきたことー月間20億PVのマンガサービス開発の裏側 場数を踏んできたのかは分かりませんが 笑 23歳エンジニア歴は２年と浅めです。 まだまだ未熟なエンジニアですが 今回はPrometheus + Grafana について紹介させて頂きます。 内容については下記となります。 Prometheus導入の経緯 Prometheus概要 Prometheusでの監視構成 次回お知らせ それでは始めていきます。 Prometheus導入の経緯 まずPrometheusを導入した経緯について少しだけ触れたいと思います。 弊社では月間20億PVのマンガサービスやそれと並行して走っているマンガサービス、また動画配信サービスや、アプリゲームの配信なども行なって
こんにちはCTOの馬場です。 弊社では業種柄、サーバごとのCPU利用率などたくさんの時系列メトリックデータを持っています。 以前はこの収集・閲覧にcactiを利用していましたが、最近はgrafana + graphiteを利用しています。 (ちなみにこれらは全て自社製OSS監視エージェントのhappo経由で収集されます) 今回はこのデータの活用例として弊社で実装している解析・レポーティングについて簡単に紹介します。 できること 全体としては月次レポートを作るしくみです。 月次レポートを自動生成 月次レポートに、前月の実績値が閾値超過しているグラフを掲載 月次レポートに、前月の実績値からの予測値が1ヶ月以内に閾値超過するグラフを掲載 下2つは今回作ったgraphdというアプリケーションで実現しています。 ※オレンジが閾値、赤が予測 動作概要 ハートビーツでは HTTPS(HTTP)+JSON
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
