次世代デジタル保険を支える監視・通知の技術
監視・通知の仕組みの全体像また、弊社では Terraform を用いて IaC ( Infrastructure as Code ) を実現して、各AWSアカウント環境の状態をコードで一元管理していますが、 Datadog の監視項目も Provider が用意されているため、Terraform で管理をすることが可能です。現状はすべての Datadog の監視項目がコード化されているわけではないですが、こちらは随時対応を行っていきたいと思っています。 外形監視外形監視は、WebサイトやAPIエンドポイントが正常に動作していることを、定期的に特定のURLに対して問い合わせをして、期待されたステータスコードや要素を返すことを監視することを目的とします。 弊社では Datadog の Synthetic Monitoring という機能を利用して監視を行っていますが、この機能の特徴としては W
書籍「Webエンジニアのための監視システム実装ガイド」発売！
システム監視の入門書籍を書きました わたしが執筆したWebエンジニアのための監視システム実装ガイドが2020/3/24に発売されますました。 予約受付中です。 物理書籍・Kindle共に販売中です。 PDF版なら検索もできちゃいます。 ※このエントリを書いている時点でまだ表紙がfixしていませんが、黒バックにウミガメ写真になる予定です 運用監視の会社でCTOとして勤続12年の知見を詰め込んだ、システム監視について幅広く取り扱った実践的な入門書です。 読者の方に体系的な知識と価値基準を獲得してもらえるよう努めました。 監視テクノロジの歴史や特徴、監視システムの基本動作と動作方式ごとの特徴、時系列データベース、DevOpsやSREなどのWebシステム運用の文化、SLO、SLI、Availability、Observability、自己修復システム、Chaos Engineering、監視方式の
Webサーバ周辺、これだけおさえれば、落ちても大丈夫？
さて、この記事に興味を持った皆さんの多くはサーバ運用に携わっていることかと思います。顧客や社外向けのシステムや、社内向けの業務サーバを構築、運用されている皆さんにとって、導入したシステムの稼働状況はいうまでもなく重大事で、システムがちゃんと動いているかが気になって夜もぐっすり寝られないことがあるかもしれません。 そこでシステム監視ツールを導入して、サーバの稼働状況を監視し、障害が発生したときに迅速な対処を図ろうということになるかと思います。この連載では、システム障害時の迅速・的確な対応を第一義とした、システムの具体的な監視のための手法について解説していきます。 監視設計とは システムを監視するには、監視の設計をすることが必要です。システムを構築するに当たっては、最初に設計を行うのと同じように、監視を行うためにも監視システムの設計をしましょう（監視を行うのも“システム”なのだから当たり前のこ
無料で使えるプロキシ/ロードバランサのOSS 比較18選 | OSSのデージーネット
プロキシサーバとは プロキシとは、クライアントとサーバの間に中継サーバとして配置するサーバのことです。プロキシは、クライアントから見た場合、サーバのように振る舞い、サーバから見た場合、クライアントのように振る舞います。クライアントアプリケーションは、プロキシへ通信を行い、プロキシはそのリクエストを受信し、受信したリクエストを本来送られるべきサーバへ転送するかのように送信します。サーバは、リクエストを送信してきたプロキシへ応答を返します。プロキシは応答に対応したクライアントに対して、応答を送信します。 プロキシサーバの種類 プロキシは、通信を中継するため通信内容をログに残したり、検査したり、書き換えたりといった処理が可能です。そのため、様々なプロトコルに対応した汎用的なプロキシと、アプリケーション（プロトコル）毎に特化した処理を行うソフトウェアがあります。 なお、Webプロキシは、HTTPプ
ウチの監視システムの変遷について書く | Ore no homepage
今、リアルタイムでは休暇中でフランクフルト経由ベルリン行きの飛行機の中にいる。暇すぎる。うちの会社、ってかトレタの監視系の変遷について書く。でも絵を描く気力はないので文字のみ。 今の状況です ルフトハンザは日本線は軽食の時間に ONIGIRI が出てくるので結構好きな航空会社です。休暇中なのにラップトップ持ってくのはプロ社畜の証。まあ今会社で裏側見てるのが俺しかいないので、エエ…。しかし世の中ホント便利に便利になってる。空の上でもインターネットができる。言い方を変えると空の上でもアラートが届くっていう…。飛行機の中は暇すぎるけどさすがに仕事はしたくないね。というかこの旅行中は仕事を忘れたい。 2014/10以前 俺が入社する前。 コア機能：Engineyard(OS: gentoo)。 プロセス異常監視、閾値監視など：monit エラートラッキング、レスポンスタイム、SQL：NewReli
PagerDutyを導入して障害対応の体制と運用ルールを確立しました - LCL Engineers' Blog
Webエンジニアの古賀です。LCLでは、障害対応の強化の一つとして多機能な通知機能を持つPagerDutyを導入しました。 組織的な対応シフト・フローが組めるようになり、精神的にとても安心できるようになったので紹介させていただきます。 pagerduty.digitalstacks.net 導入前の課題 LCLでは、Mackerelを利用して各サーバの監視しており、障害が発生するとチャットでエンジニアへTO(メンション）で通知をしていました。 この運用方法では、以下のような問題がありました。 全エンジニアへの通知のため、早めに気づくエンジニアが固定の担当になりがち TO（メンション）の重要度が高く、通常のやりとりで使いづらい 通知は一度しかこないため、他のチャットで埋もれてしまい見逃す可能性がある チャットでの障害通知では限界が見えてきて、何かいいサービスはないか検討していたところPage
モンストとサーバ運用体制
「夏だ！飲もうぜ！Game Day ～ビッグタイトルの裏側～」で発表した、スライド資料です。 https://idcf.doorkeeper.jp/events/63167
目指せ！落ちない高可用性サーバ、ハードウェアの選び方 - Qiita
10年以上金融機関で働いているインフラエンジニアの落ちないサーバにするための考察です。 ハードウェアの専門家ではないので、正確ではないかもしれません。 今までの経験からの個人的考え方になります。 私たちオンプレ重視のインフラエンジニアは、 クラウドサービスではできない高可用性サーバを導入したり、 複数台構成で１台故障しても問題ない構成のサーバはコスト重視するなど、 システムに最適なサーバを導入しようとしています。 高可用性サーバを追求する目的 ■アプリに影響を与えないように Active/Standby構成にしていて、インフラ的にはダウンタイムが数秒だとしても、 アプリによっては復旧に時間がかかったり、問題ないことの確認にも時間がかかってしまいます。 また、正しくサーバが落ちればアプリが問題ないとしても、 サーバが中途半端な状態のままになってしまい、なんだかおかしいということもあります。
監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
「業務マニュアル」と「操作マニュアル」の違い - 設計者の発言
「ユーザマニュアル」という言い方があるが、業務システム開発の文脈でこの表現は使わないほうがいい。「ユーザマニュアルを作りなさい」では、「操作マニュアルを作りなさい」なのか「業務マニュアルを作りなさい」なのか判然としないからだ。いずれも重要な設計要素ではあるが、内容も目的も異なっている。 まず「操作マニュアル」とは、パネルやページの操作方法を説明したものだ。たとえば「パネルＡが表示されたなら、ボタンＢを押してください。するとデータが一覧されるので、一覧のいずれかを選択状態にしてエンターキーを押せば、続くパネルＣが表示されます」といった説明は「操作マニュアル」にありそうな記述だ。文章だけでなく、関連するスクリーンショットを伴うことが多い。 いっぽう「業務マニュアル」とは、文字通り「個々の業務の説明書」のことである。ここで言う「業務」とは、「受注登録業務」や「出荷指示業務」や「実棚報告業務」とい
システム運用をエンジニアリングしよう
先日、あるシステム子会社の幹部の話を聞いて、少し驚いた。それは、「自分たちの仕事の内容が親会社になかなか伝わらない。だからITIL（Information Technology Infrastructure Library）を導入した」と言うのだ。つまり、親会社に示す成果の形が「ITIL」だったのである。 ITILは、ITサービス管理や運用プロセスのベストプラクティスであり、運用現場を変える一つの手段にすぎない。ところがこの幹部は、その手段を自分たちの成果として伝えたという。筆者はそれを聞いて何かが違うと思った。しかし、その幹部が言いたいことは、運用の成果を説明しにくい一方で、「場当たり的な運用」「何をやっているのか自分たちも分からない」という状況から脱却したい思いもあったようだ。 かつて混沌とした開発現場が乗り越えてきた課題 気になって、他の運用担当者にも話を聞くと「場当たり的な運用」「
システム運用管理は“汚れ仕事”か？
最近筆者は、情報システムの運用管理に携わるエンジニアに取材する機会が多い。その中で、「運用は汚れ仕事だから・・・」という言葉を聞くことがある。取材後の雑談などで冗談半分にそういう話が出てくるのだが、運用の現場にそういう意識があるのは確かだろう。 しかし筆者は、「運用は決して汚れ仕事ではない」と断言したい。そして運用の仕事は、今後ますます重要度を増すと考えている。 利用部門からの問い合わせで現場に駆け付け、担当者から「早く動かしてくれ」と文句を言われながら、トラブルの発生したPCやサーバーに向かう──。重大な障害が発生したら、それが夜中であろうが呼び出され、夜を徹して復旧作業に当たる──。運用担当者の仕事というと、こうした状況を思い浮かべる人は多いだろう。 「システムは問題なく動くのが当たり前」と考える利用部門の視点で見れば、運用担当者が知恵を絞って安定稼働を実現していても、あまり感謝される
ファーストサーバの手順の問題点 - きしだのHatena
えらいことなってますが。 正規手順と今回の現象の説明などを含めた中間報告が出されています。 http://support.fsv.jp/info/nw20120625_01.html ここで、正規手順で、途中でオペレーションミスがあったときに復旧できない状態になってしまう可能性があることがわかります。 具体的には「原因3：メンテナンス仕様」のこの部分。 脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用する この時点でこの更新プログラムに不具合があった場合には、リストアできなくなることになるわけです。そして今回はそれがおきたようです。 より安全な手順であれば、バックアップ側にパッチをあてている間は正常系がバックアップのバックアップということになるはず*1ですが、どこにもバックアップがない状態になってしまったわけです。 手順１
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バックアップとアーカイブの違い―アーカイブならではの課題と対策 | 情報資産管理マガジン
本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita
「監視の目的とは何か？」問いかけよう / Practical Monitoring
運用に自動化を求めるのは間違っているだろうか
2015-05-23 クラウドの運用になって インフラエンジニアは何が変わるのか?
ニイヨンサンロクゴ
ファーストサーバーの事故についてちょっと具体的に想像してみました
