その広告配信システムは正しく動いているのか？ #TechMarTech x Marketing meetup #5 サイトリライアビリティエンジニアリング https://techxmarketing.connpass.com/event/189979/
メンテナンスウィンドウを使わない - @katzchang.context
6年ほど無停止のサービスを運用してきた私の経験からすると、メンテナンスウィンドウ、つまり計画的メンテナンスに対するアラート発砲を抑制する機能は、使わないほうがうまくいく。仕事の中でも度々メンテナンスウィンドウの話題が出てきたので、個人の見解としてまとめてみたい。 計画的メンテナンスの手順 対外的に無停止だとしても、内部的には停止を伴うメンテナンスをすることがある。たとえば、MySQLを止めることはたまにある。まずは、どのようにメンテナンスを進めていくのかを整理しよう。 内部的な停止を伴うメンテナンスの際は作業に必要な時間とともに、アラートが起こる範囲を予測し、予告しておく。予告の範囲を決めるのは単純で、アラートが届くだろうチャンネルにお知らせしておけばいい。以前のチームではメールとSlackチャンネルを使っていたので、そこに書いていた。準備はこれでいい。 メンテナンス作業が始まる（たとえば
なぜPrometheusを辞めてDatadogを採用したのか - ABEJA Tech Blog
こんにちは。ABEJAのインフラ管理してる村主 @rwle1221 です。 本ブログは Datadog Advent Calendar 2019 の8日目です。 今日は ABEJA Platform というプロダクトで、なぜ Prometheus から Datadog に変えたのか。というお話したいと思います。 一人の方でも採用基準の参考になればと思います。 第一フェーズ：実は元々Datadogを使っていた 実は Prometheus の前は Datadog を使っていました。 なぜ Datadog を使っていたかというと、Za○bix や Na○ios などは古い思想なので使う気になれなかったという単純な理由です。 ただ、 Datadog は $18/host という値段で 当初は数十台だったので数万円ほど発生していました。やはり少し高いなという印象です。 第二フェーズ：Promethe
Amazon CloudWatch、機械学習により異常値（アノマリー）を自動検出できる新機能
ITシステムの運用監視において、通常とは異なる状態、例えば急にトラフィックが跳ね上がる、動作速度が遅くなる、プロセッサの使用率が上がる、ネットワークのレイテンシが大きくなる、などを検知し、警告を発することはもっとも基本的かつ重要な機能です。 しかし、通常の状態にはある程度の幅があります。一体どの程度の範囲を超えたら異常であると判断するのか、閾値の設定は容易ではありません。 閾値を低くすれば、ひんぱんに異常と判断されて警報がいつのまにか軽視されてしまう心配があります。逆に閾値を高くすれば、小さな異常が見過ごされてしまう恐れがあるため、適切な設定には試行錯誤が必要です。 しかも昼と夜、平日と休日では適切な閾値は異なるでしょうし、キャンペーン期間やテレビコマーシャルの投入など特定の期間も閾値は変化するなど、閾値の設定は動的に行う必要もあります。 こうした難しい異常値の検出を機械学習により自動的に
Microservices時代の監視設計 - An Epicurean
前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。 前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。 モノリシック世界観での監視 アプリケーション監視の浸透 Microservices時代の監視設計 開発者自身が監視する どう監視するか メトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ 例: ある認証コンポーネントの監視設計 まとめ モノリシック世界観での監視 Webサービスの構成が
「入門 監視」を読んで見えてきた現状の課題と改善点 - エムスリーテックブログ
こんにちは、エンジニアリンググループ SREチームの高橋(@tshohe1)です。 「入門 監視」という本が各所で話題になっていますが、エムスリーのエンジニアリンググループでも予約購入していました！ www.oreilly.co.jp 監視というSREと非常に親和性の高いテーマの本だったこともあり、多くのSREメンバがこの本に目を通していたようです。 そこでぜひチーム内で感想を共有しようということになり、先日感想共有会が実施されました。 本記事ではそのときに挙がった感想を一部抜粋して公開したいと思います。 モニターリザード 各章の感想 「1章 監視のアンチパターン」について 「第2章 監視のデザインパターン」について 「3章 アラート、オンコール、インシデント管理」について 「5章 ビジネスを監視する」について 「6章 フロントエンド監視」について 「7章 アプリケーション監視」について
モニタリングするためにどんなデータを集めるべきか - アルパカ三銃士
Datadog のブログで公開されている "Monitoring 101: Collecting the right data" を読んだ。本記事は紹介した Datadog のブログ記事を独自に簡略化したものである。もっと詳しく知りたい場合は Datadog の記事を読むと良い。 記事では次の項目を実現するためにどんなデータを収集し分類するかが記載されている。 自動検知によって潜在的な問題に効果的なアラートを受信する。 素早く調査を行いパフォーマンスに関する原因へ到達する。 Metrics メトリクスはある時点のシステムに関連する値を取得する。通常 1 秒間に 1 回もしくは 1 分間に 1 回など時間の経過とともに監視する。 メトリクスを以下の 2 つのとても大切なカテゴリに分けられる。 Work metrics システムのトップレベルでの health 状態を表せられるメトリクスを指す
GoogleとNetflix、カナリアリリース分析ツール「Kayenta」オープンソースで公開。新たにデプロイしたリリースに問題がないかを自動分析
GoogleとNetflix、カナリアリリース分析ツール「Kayenta」オープンソースで公開。新たにデプロイしたリリースに問題がないかを自動分析 GoogleとNetflixは、共同開発したカナリアリリース分析ツールの「Kayenta」をオープンソースで公開した。新規リリースを本番環境に対して小規模にデプロイし、問題がないかを検証する作業を自動化。より迅速で確実な継続的デリバリを実現する。 GoogleやNetflixのようにWebサービスを提供している企業では、そのWebサービスに次々と改良が加えられ、1日に何度も新しいリリースがデプロイされています。 しかし新しいリリースのデプロイはいきなり大規模に行われるわけではありません。リリースされるコードに対しては継続的デリバリのパイプラインの中で一通りの自動テストが行われ、ある程度の品質が保証されているはずです。しかし、それでも新しいリリー
Home
Go beyond crash reporting, error tracking, logging and error monitoring. Get instant and accurate alerts — plus a real-time feed — of all errors, including unhandled exceptions. Our automation-grade grouping uses machine learning to reduce noise and gives you error signals you can trust. A better way to discover errors Instantly see the impact of crashes and errors with metadata — like which custo
サーバ「管理」ツールとしてのMackerelの起源 - ゆううきブログ
この記事は、SaaSのサーバ監視サービスMackerelを起源を遡り、そこから現在の姿に至った経緯をはてな社内のエンジニアに共有するためのものです。 なお、ここに書かれていることは、Mackerel開発チームの公式見解ではありません。 概要 Mackerelは、もともとは2007年ごろに開発されたはてなの社内のサーバ管理ツールであり、動的なインフラストラクチャに対応するために、現在でいうところのInfrastructure As Codeを目指したものです。 そこから2013年にSaaSのサービスとして開発され、コードベースとアーキテクチャは全く新しくなり、監視機能を備え、サーバ「監視」サービスと呼ばれるようになりました。 しかし、はてな社内では、プログラマブルなAPIを備えたサーバ「管理」サービスとして、Mackerelを中心にしたインフラストラクチャを構築しています。 Mackerel
PostgreSQLの内部構造と監視の話 - そーだいなるらくがき帳
Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre
サーバレスアーキテクチャによる時系列データベースの構築と監視 / Serverlessconf Tokyo 2017
サーバレスアーキテクチャによる時系列データベースの構築と監視
次世代監視の大本命！ Prometheus を実運用してみた - Qiita
こんにちは！freeeでインフラゾンビをやっている @sugitak です。ゲームではレベルを上げて物理で殴る派です。 freee ではたまにインフラエンジニアの数が減るのですが、その減ったインフラエンジニアはインフラゾンビへと進化し、社内を闊歩します。インフラゾンビは主に開発チームに所属して、アプリっぽいインフラの仕事をインフラからアプリ側へと持っていきます。デプロイとか、Dockerとか、Jenkinsとかの、いわゆる DevOps 系のところですね。こうすることで開発者は手を出せるものの自由度が増えるし、インフラはより本来のインフラとして純度を上げていける、 so, win-win ってわけです。 さて、そんなわけで監視です。freee Engineers Advent Calendar 2016の9日目の記事として、 Prometheus による監視が最高なのでみんなもっと使おうと
CPU使用率は間違っている | Yakst
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか？プロセッサーがどのくらい忙しいか？違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
時系列データベースに関する基礎知識と時系列データの符号化方式について - クックパッド開発者ブログ
こんにちは。インフラストラクチャー部 SRE グループの吉川 ( @rrreeeyyy ) です。今期オススメのアニメはツインエンジェル BREAK です。 普段の業務並びに趣味の一環として、サーバのモニタリング環境の調査や改善に取り組んでいます。 そこで本稿では、モニタリングのコンポーネントの一つとして外すことが出来ない、時系列データベースの基礎知識に関して紹介します。 そもそも時系列データ・時系列データベースとは？ 時系列データというのは、特定の時間ごとに何らかの値を取得した際の、取得した一連の値を指します。 例えば、以下のようなフォーマットをしたデータなどは時系列データにあたるでしょう。 timestamp1,key,value1 timestamp2,key,value2 timestamp3,key,value3 : 時系列データベースとは、上記のような時系列データの保存・処理に
高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017 - ゆううきブログ
名古屋大学で開催されたIPSJ-ONE2017 で登壇しました。 IPSJ-ONEというのは、情報処理学会の各研究会から選ばれた日本の若手トップ研究者17人が集まり、自身の研究を高校生でもわかるように発表するイベントです。 1000人ぐらい入る講堂で、しかもニコニコ生放送で配信されるというとても大掛かりなイベントです。 ちなみに、昨年は、同じ研究会からの推薦で、 id:matsumoto_r (matsumotory) さんが登壇されています。 IPSJ-ONE 2016で登壇してきた - 確実に時代は変わってきている #ipsjone - 人間とウェブの未来 発表 「高度に発達したシステムの異常は神の怒りと見分けがつかない」という、一見何の話かわからないやばそうな話なんですが、大真面目に話してきました。 スライドを以下に公開しています。ただ、スライドだと何の話をしているかおそらくわからな
AWS X-Ray – 分散アプリケーションの内部を見る | Amazon Web Services
Amazon Web Services ブログ AWS X-Ray – 分散アプリケーションの内部を見る 大統領自由勲章の受賞者であるGrace Hopperが、プログラムからエラーを特定し取り除く作業にデバッグという言葉を与えた最初の人だと思います。 実際にコンピュータから本物のバグ(虫)を見つけたことはないですが、働き初めた頃にアセンブラ言語のデバッグに膨大な時間を費やしました。その当時は、デバッグとはコードを1ステップずつ実行し、各プロセッサのレジスタの中身をステップの前後で比較し、自分の頭の中のモデルと実際に起こっていることが一致しているかを検証するというものでした。これはとてもうんざりするようなものでしたが、バグが残る余地はほとんどなく、自分のコードがどの様に動くかの深い理解も得られるものでもありました。その後、1ステップずつの実行はなくなり、デバック出力(こんにちは、stder
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「監視の目的とは何か？」問いかけよう / Practical Monitoring
User experience monitoring with Datadog Synthetic browser tests
Serverless Status Page system
