You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
こんにちは。SRE部の塩崎です。七味唐辛子の粉末を7種類に分類するという趣味を発展させて、おっとっとを新口動物と旧口動物に分類するという趣味を最近発明しました。 BigQueryは非常にパワフルなData WareHouse(DWH) SaaSであり、大容量のデータを一瞬で分析できます。しかし、課金額がスキャンしたデータ量に比例するという特徴があるため、意図せずに大量のデータをスキャンしてしまい大金を溶かしてしまうことを懸念する人もいます。 qiita.com そのため、課金額が大きすぎるクエリを発見した際にSlackへ通知する仕組みを作りました。GCP Organization内の全プロジェクトで実行されたBigQueryの監査ログをリアルタイムにチェックすることによってこの仕組みは実現されています。本記事では作成したシステムを紹介します。 なお、本記事は以下のQiita記事に着想を得た
こんにちは、@ueokandeです。早速ですが、皆さんが運用しているサービスには、SLO (Service-level objective: サービスレベル目標) がありますか？アラートの監視項目はどのように設定して、基準値をどのように決めていますか？ 社外とのコミュニケーションだけでなく、社内向けのSLOを決めておくことで、サービスの健康状態を知るための手がかりや、普段の開発・運用タスクの優先度を決める上での指標にもなります。 またSLOがあると、サービスを監視するアラートに、理にかなった閾値を設定できます。 この記事ではAWS版kintoneの、SLOとアラートを設定するまでの記録について紹介します。 cybozu.com版kintoneのSLOとアラート 国内のcybozu.comで運用しているkintoneにも、もちろんSLOやアラートはあります。 しかし現状のSLOはkinton
JJUG CCC 2019 Fallで話した時のスライドです。
[SRE]原文 An Incident Command Training Handbook – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-06-24 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1966日前 Twitterで報告済み 編集 私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。 以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。
- The document discusses monitoring AWS resources using Amazon CloudWatch. It covers collecting metrics and logs from EC2 instances, ELB, RDS, and other services and visualizing the data in CloudWatch. - Key services mentioned include CloudWatch Metrics to collect CPU, memory, disk and network utilization from EC2 instances, CloudWatch Logs to collect logs, and integrating monitoring with services
TL;DR 監視はユーザーにサービスを提供できているかを観測するための行為 SLI/SLOを定めて、SLOを守れるようにモニタリングする ダッシュボードは定常的に表示しておくものと障害時に活用するものを作ると良い アラートはレベル分けして人間が対応しなければならないものだけ人間へ通知する 監視とは サービスを健全に動作させ続けるために監視を行います。 「健全に動作している」の定義はサービスによって異なり、ユーザーにWebページを見せることができることだったり、バッチが正常に終了することだったりします。 最終的にユーザーに正常にサービスを提供できていることを観測するために行うことに変わりはありません。 さてユーザーにサービスを提供するために何を監視しましょうか？ クラウド前提であれば個人的にリソースベース（CPU/Memory）より、 SLI/SLOをベース に監視する事が望ましいと考えてい
freee では仮想マシンのインフラ監視に Mackerel を使っていますが、Kubernetes を使っているところは前例にとらわれずゼロベースで見直そうとしています。現状は Elastic Stack と Mackerel のハイブリット構成になっています。 Elastic Stack による Kubernetes モニタリングシステムの紹介 - freee Developers Blog どの SaaS を使うかを決める前に、そもそも Kubernetes の何を監視すればいいのか？ というところから考え直しています。宣言的なマニフェストにより Kubernetes が自律的にあるべき状態を保ってくれるのであれば、これまでの監視とは異なってくるはずです。 監視の観点として、ここでは通知レベルを用いて次の 3 つに分類します。 None: メトリクスは収集するが通知しない Notic
こんにちは。メルペイでバックエンドソフトウェアエンジニアをしている id:koemu です。 バッチプログラムのお話、今回は運用・監視についてお話したいと思います。当社はすべての業務が24時間行われていますので、システムがオンラインのときに動作するバッチプログラムについてのみ議論します。 過去の記事はこちらにあります。 運用に備えて バッチプログラムの運用について、「プリモーテム」「実行管理」そして「ログ管理」の3点について述べていきます。 プリモーテム ポストモーテムという言葉を聞いたことがある方はいらっしゃるかと思います。ポストモーテムとは、GoogleのSRE本の15章*1によれば、障害などの失敗を振り返り、今後に活かすプロセスの総称と捉えることができます。 さて、プリモーテム(プリモータム)とは何でしょうか。この言葉は、私が最近読んだThe Manager’s Path*2*3で使
前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。 前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。 モノリシック世界観での監視 アプリケーション監視の浸透 Microservices時代の監視設計 開発者自身が監視する どう監視するか メトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ 例: ある認証コンポーネントの監視設計 まとめ モノリシック世界観での監視 Webサービスの構成が
Chapter3: Alerting on What Matters 監視データを精査し収集出来ていると仮定して、それらから何をAlertすべきかに話は進んでいきます。 アラートが狼少年と化している担当者の方には是非一緒に見ていただきたい章となっています。 Automated alerts are essential to monitoring. They allow you to spot problems anywhere in your infrastructure, so that you can rapidly identify their causes and minimize service degradation and disruption. But alerts aren’t always as effective as they could be. In partic
こんにちは！待ちに待った2月です。 何を待っていたか？ フットボールネーション（１３） (ビッグコミックス)やブルーピリオド（４） (アフタヌーンコミックス)、BLUE GIANT SUPREME（７） (ビッグコミックススペシャル)が発売される月ということになります。 嬉しい〜！の金城(@o0h_)です。 さて。 (ほぼ)ちょうど1ヵ月前に出た「入門 監視」は、いろいろな方面で話題になりました。 既に色々な書評やまとめが出回っていて、反響の大きさが感じられますね！ www.oreilly.co.jp 弊社でも、会社の書籍購入補助を利用して即予約 & 入手をしました。 この本からは非常に多くの学びや示唆を得られたと感じています。 先日、その内容・感じたことを、社内LT会で共有しました。 発表内容を踏まえつつ、読後に自分なりに考えさせられたことをまとめてみたいと思います。 ただしスライドに含
最近、監視やモニタリング熱が自分の中で高まってきてます。 その一環で先月"Prometheus Up & Running"を購入しました。 Prometheus: Up & Running: Infrastructure and Application Performance Monitoring 作者: Brian Brazil出版社/メーカー: O'Reilly Media発売日: 2018/07/28メディア: ペーパーバックこの商品を含むブログを見る 少し前にようやく届いたので読んでいってます。 今回は読書のメモとして調べたサイトなどを残しておきます。 Prometheus Up & Runningに出てくるUSEメソッド/REDメソッド とりあえずPrometheus Up & Runningのchapter3まで読みました。 chapter3ではREDメソッドとUSEメソッドと
今、巷で話題の「入門 監視」を、翻訳のレビューに協力された id:hayajo_77 さんからいただきました。ありがとうございます！！！ コーヒー☕️❤️とクッキー🍪❤️と、入門・監視👁 pic.twitter.com/yanG9XFhVQ— a-know | Daisuke Inoue (@a_know) 2019年1月14日 仕事柄（サーバー監視SaaS・Mackerelの中の人をやっています）、サーバー・インフラの監視ということについて考えている時間は業界平均よりは（おそらく）長く、かといって、「誰よりも詳しいか？」「投げかけられた問いに対して迷うことなく答えられるか？」というと、まだまだそれには程遠く......。そんな、迷い悩む日々に現れたこの本は、間違いなく、今後僕と僕の周りを照らしてくれるものになるだろう、という確信を持たせてくれる一冊でした。"監視に携わる可能性のある人
No one is an island. Learnings from fostering a developers community.
鳴子とは AWS監視のコスト・運用負荷を軽減 “鳴子 NARUKO”とは、数多くのクラウドサービス提供やプロジェクトの実績から生まれたAWS運用自動化ツールです。 自動監視することにより、AWS環境を快適に運用することが可能になります。 尚、 「AWS運用担当者の負担を軽減したい」 「AWSを利用する企業のコストカットにつなげたい」 「AWSのメリットを最大限に利用して欲しい」 との理由から、自社開発である“鳴子 NARUKO”をOSSにて公開することに致しました。 ”鳴子 NARUKO”が、一人でも多くの方に利用されることにより、AWSユーザーと企業のAWS運用コストカット、運用負荷の軽減につながることを願っています。 鳴子は穀物を野鳥の食害から守るため、鳥を追い払う目的で使われてきた音を出す道具。 AWS上の障害をいち早く察知し、警報をならし対応をすることから、鳴子 NARUKOと命名
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
