~スタートアップの人たちに捧ぐ~ 監視再入門 in AWShttps://aws-startup-community.connpass.com/event/241721/ 2022/05/10(火) 19:30 〜 21:30 「スタートアップ事例祭り 〜監視・モニタリング・セキュリティ編〜」
Fargateの運用 ～デプロイ自動化や監視等～
初めてFargateを触ったので、運用保守の観点で構築時に設定しておいた方が良いポイントをまとめました。 デプロイの自動化と書いているのにデプロイの話薄めになってしまいました…。 こちらはJAWS-UG朝会 #28で発表したものになります。
入門監視やSRE本に学ぶ障害対応フォーメーション - An Epicurean
システム障害が起こったときにどういう体制で望むか、エンジニア個人が障害に直面した時にどのような役割を受け持つのが良いのか。組織によって色々なパターンはあるでしょう。しかし、幸いにも「入門 監視」やSRE本に書かれている4つの役割分担が浸透しているので、それをベースに考えるのがファーストステップとしては良いのではないでしょうか。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム オライリージャパンAmazon ただ、小さな組織では障害時に4人もすぐに揃わない場合もあるでしょうし、そもそも4人もスタッフがいない、と言う場合もあるでしょう。そういった場合にもどうすればいいのか考えていきます。 役割分担の基本 「入門 監視」に
[速報] CloudWatchの監視メトリクスをKinesis経由でストリーム送信可能な新機能「CloudWatch Metric Streams」が登場しました！ | DevelopersIO
Amazon CloudWatch に新しい機能、Metric Stream が登場しました！ いままでCloudWatchのメトリクスデータを、New RelicやDatadogのような外部のSaaSから参照しようと思ったら、定期的にAPIでポーリングするしかありませんでした。そのため、（この公式Blogにも書いてますが）メトリクスの種類によっては5〜10分程度の遅延が発生することになってました。 今回の機能で、CloudWatch側で更新されると同時にSaaS側へもpushされることになるため、同じタイミングで参照できるようになります。これはうれしいですね！ CloudWatch Metric Streamで出来ること 要は、CloudWatch MetricのデータをKinesis Data Firehoseに流し込むことができる機能です。 Firehose はストリームデータをS3
![[速報] CloudWatchの監視メトリクスをKinesis経由でストリーム送信可能な新機能「CloudWatch Metric Streams」が登場しました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/2cd56545af48138769ce47d03f22d7baac20b923/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-cloudwatch.png)
「RDSのトラブル発生に備えて！やっておくべき設定・監視」登壇資料 #jawsug #jawsdays #jawsdays2021 #jawsdays2021_B | DevelopersIO
おはこんばんちは！オペレーション部のもっさん@福岡オフィスです。 2021/03/20 に開催された JAWS DAYS 2021 -re:Connect- で、「RDSのトラブル発生に備えて！やっておくべき設定・監視」というテーマで登壇しました。 セッション資料 セッションの補足・解説 本セッションの目的 RDS に触れ始めたばかりの方や、これから RDS を学んでいく予定の方へ向けて、RDS の監視・ログ設定機能の概要を知っていただくことを目的としています。 また、知った機能を手軽に試すことができるよう、ざっくりとした設定手順や、設定時の注意点を簡単にまとめています。 お伝えしたかったこと 今回お話しした監視・ログ設定は、有効化を DB インスタンスに適用した段階からデータを記録します。設定が適用された以前のデータは、遡って取得することができません。 AWS 基盤側の監視機構が RDS
Dockerで動かして学ぶモニタリングの基礎 - Progate Tech Blog
はじめまして、Progateの村山です。 本記事はProgateAdventCalendarの2日目の記事です。 普段はSREチームでProgateの開発や運用を支える仕事をしております。Progateには今年の7月に入社しました。前職はElixirやk8sなどを使ったWebアプリケーションの開発や運用をしていました。ProgateにElixirのコースを作るのがちょっとした野望です。 本稿ではサービスや開発のモニタリングについて紹介しようと思います。 モニタリングとは モニタリングは日本語で監視と言い、主にサービスの障害検知や可用性向上のために利用されています。ここで紹介するモニタリングは大きく2種類に分類したいと思います。 1つ目は死活監視するためのモニタリングで、サービスやアプリケーションの可用性監視し、必要に応じてフェイルオーバーさせたりアラートを飛ばして開発者へと共有します。 2
3〜4時間でAWSの監視系のサービス一気に学べたらコスパ良いと思いませんか | DevelopersIO
突然ですが、以下の機能がそれぞれどういうものか すべて ご存知でしょうか？ CloudWatch ServiceLens X-Ray CloudWatch Contributor Insights CloudWatch Synthetics CloudWatch Container Insights CloudWatch Logs Insights CloudWatch メトリクス Metric Math 検索式 カスタムメトリクス CloudWatch ダッシュボード CloudWatch 異常検出（Anomaly Detection） CloudWatch 埋め込みメトリックフォーマット CloudWatch アラーム 異常検出に基づいたアラーム 複合アラーム 私はわからなかったですね。ここ 1〜2年のCloudWatch系のアップデート量は凄まじいなと個人的には思っていて、Cloud
冴えないAWS環境の育てかた α | DevelopersIO
中山です ソリューションアーキテクトとして、AWS環境の利活用をお手伝いするお仕事をしています。 まれによく見るAWS環境 とりあえずこれを見てほしい。 これが絶対にだめと言いたいわけではないです。 一時的な検証環境だったり、とにかくスピード重視でサービスをデリバリーさせる必要があったり、サービスの提供者側が何ら責任を負わない・障害時のビジネスインパクトが無い（そんな状況あるのか？）という前提があったり、状況次第ではこれで十分な時もあると思います。 しかし、一般的な業務システムやサービスの場合にはいろんな意味で不十分でしょう。 では、このような環境をどのように育てていくとよいでしょうか。 この記事では、そんな育てかたの一例を紹介していきたいと思います。 なお、本記事はくっそ長いです。 ちなみに、最終的にはこうなります。 文字が小さすぎて読めない！ ちょっとそこのハ○キルーペ貸してくれーｗ
その後のgolangと(Dockerと)OOM — KaoriYa
前の記事:golangとDockerとOOM を書いた後で Go側の事情に変化があったため、 あの記事に書かれた方法は現実的な選択肢ではなくなってしまいました。 この記事では私が使っているGo 1.14以降でのOOM対策と、 どうしてそうせざるを得なかったのか解説をお届けします。 TL;DR Goの64ビット版はVSZの最小要求量が大幅に拡大した (500MB超) 前の記事で紹介した方法が現実的ではなくなった VSZの制限をRSSに転用する=最低でも500MBのRSSを設定することになる 代わりに自プロセスのRSSを監視して閾値を超えたらアポトーシスするようにした RSS取得用のkoron-go/phymemパッケージを作成した Background あの記事を書いた翌月末にGo 1.14がリリースされました。 その変更点の中に以下の記述があります。 The page allocator
死活監視、ロギング、メトリクス――Kubernetesと監視の話
第1回～第4回で、Amazon Web Services（AWS）が提供するマネージドKubernetesサービス「Amazon Elastic Kubernetes Service（EKS）」を用いた「Kubernetes」環境の構築や、Kubernetesを利用したアプリケーションの公開までを解説しました。この2つの能力があれば、ITサービスを通じてユーザーに価値を提供することができます。パン屋さんで例えるとパン（アプリケーション）を店頭で並べられるようになった（公開）といったところでしょうか。 パンを焼いて店頭に並べる一連の作業は、もちろん1回で終わるものではなく、毎日繰り返すものです。毎日繰り返すには、パンを焼くための道具や機械に不具合がないように定期的に点検して、機械が不調になったときはすぐに修理したり、一時的に代用できるものをあらかじめ準備しておいたりするなどの対策が必要です。
ECSとGoで構築したシステムにDatadogを導入する | おそらくはそれさえも平凡な日々
追記: GoのアプリケーションをOpenMetricsを使ってObservableにする方法については別エントリを書きました。 → https://songmu.jp/riji/entry/2020-05-18-go-openmetrics.html ECSとGoで運用しているシステムに対するDatadogの日本語知見があまり無さそうだったので書いてみる。ちなみに以下の環境です。 ECS on EC2 (not Fargate) アプリケーションコンテナのネットワークモードはbridgeモード 動的ポートマッピングも利用 背景として3月にNature Remoのインフラアーキテクチャ改善をしていて、その前にもうちょっと監視を整えたほうが良いな、ということでDatadogを導入したのがある。テストがないとリファクタリングできないように、監視がないとアーキテクチャのアップデートもやりづらいとい
書籍「Webエンジニアのための監視システム実装ガイド」発売！
システム監視の入門書籍を書きました わたしが執筆したWebエンジニアのための監視システム実装ガイドが2020/3/24に発売されますました。 予約受付中です。 物理書籍・Kindle共に販売中です。 PDF版なら検索もできちゃいます。 ※このエントリを書いている時点でまだ表紙がfixしていませんが、黒バックにウミガメ写真になる予定です 運用監視の会社でCTOとして勤続12年の知見を詰め込んだ、システム監視について幅広く取り扱った実践的な入門書です。 読者の方に体系的な知識と価値基準を獲得してもらえるよう努めました。 監視テクノロジの歴史や特徴、監視システムの基本動作と動作方式ごとの特徴、時系列データベース、DevOpsやSREなどのWebシステム運用の文化、SLO、SLI、Availability、Observability、自己修復システム、Chaos Engineering、監視方式の
我々は Kubernetes の何を監視すればいいのか？ / CloudNative Days Kansai 2019
我々は Kubernetes の何を監視すればいいのか？ / CloudNative Days Kansai 2019
「入門 監視」を読んでからの取り組みを紹介します - WILLGATE TECH BLOG
「入門 監視」を読んだ フロントエンド監視 なぜフロントエンド監視が必要なのか どうやってフロントエンド監視をしているのか Runbookを作ろう なぜRunbookが必要なのか Runbookをどう使っていくか 監視の民主化 勉強会開催 今後 こんにちは！インフラチームの小林です。 今回はインフラチームが現在取り組んでいる、運用環境の改善施策を紹介します。 「入門 監視」を読んだ 2019年01月 に「入門 監視」という本が O'Reilly Japanから出版されました。 www.oreilly.co.jp 『システムをどう監視したらよいのか』『監視の仕組みをどう作ったらよいのか』について紹介している本です。 実践したい事、反省する事だらけですが、フロントエンド監視とRunbook作成から始めています。 フロントエンド監視 なぜフロントエンド監視が必要なのか Webサイトの表示スピード
AWSでAZ障害が起きたのでなるべく影響を受けない構成の考えを書いておく - なんかかきたい
AZ障害は受け入れるしかないクラウド時代のインフラ ただの日記。 今日の昼、AWSを利用している人たちは大変だったところもあると思う。 AZの一つが丸々機能しなくなる大きなAWSの障害があり、AWSを利用して運用されていたサービスは多かれ少なかれ影響を受けることになった。 完全に雰囲気で書いてしまうが、今回のAZ障害で影響を受けたサービスは思ったより多かったように感じる。 というのもAWSではアベイラビリティーゾーンの障害は発生するものと考え、本番運用するのであれば、マルチAZ構成を取るのがベストプラクティスとされているので、 マルチAZ構成を取っていれば影響なんてないんじゃないの普通、と思ってしまうと思う。 インフラ屋さんでもそう思ってしまうし、インフラ屋さん以外ならなおさらなんで重くなるのかわからないと思う。 幸い自分の運用しているサービスでは影響が軽微だったので、完全に想像にはなって
我々は Kubernetes の何を監視すればいいのか？
freee では仮想マシンのインフラ監視に Mackerel を使っていますが、Kubernetes を使っているところは前例にとらわれずゼロベースで見直そうとしています。現状は Elastic Stack と Mackerel のハイブリット構成になっています。 Elastic Stack による Kubernetes モニタリングシステムの紹介 - freee Developers Blog どの SaaS を使うかを決める前に、そもそも Kubernetes の何を監視すればいいのか？ というところから考え直しています。宣言的なマニフェストにより Kubernetes が自律的にあるべき状態を保ってくれるのであれば、これまでの監視とは異なってくるはずです。 監視の観点として、ここでは通知レベルを用いて次の 3 つに分類します。 None: メトリクスは収集するが通知しない Notic
AWS chatbot (チャットボット) で コストアラートをSlack通知 - Tech Blog
はじめに エンジニアのウエです。Timers inc.では、ビジネス部門の一人として 配送・印刷・決済に関わる施策立案・業務改善を推進しています。また開発チームのプロダクトマネージャとして、顧客対応チームのマネージャとして、様々な役割でサービスに関わっています。 BizDevOps を通じた 効率化や改善に関わり、とても充実した日々を送っています。 今回の記事では、AWS Chatbot (チャットボット) を Slackへのコストアラート通知に利用した例を記載します。 前提 CloudWatch の Billing を利用するため、あくまでも概算です。 事前準備 ブラウザで Slack に bot用アカウントでログインします。 通知に利用する SNS トピック作成( us-east-1 )します。 手順 AWS chatbot から Client を作成します。 通知先として Slack
クラウド世代の OSS 監視システム「Prometheus」 Meetup でがっつり話を聞いてきた #prometheustokyo | DevelopersIO
6/3 渋谷で行われた Prometheus Tokyo Meetup #2 をレポートします。 Prometheus といえば「クラウドネイティブ」というキーワードの中で語られることの多いインフラ監視・モニタリングソリューションですが、本ミートアップではクックパッド社やヤフー社の事例など、 Prometheus ヘビーユーザの方々により特徴や活用事例が語られる、非常に興味深いものでした。 Prometheus Tokyo Meetup #2 - connpass Prometheus Tokyo Meetup #2 - 資料一覧 - connpass なお、本ミートアップはサイバーエージェント殿協力の下、渋谷の Abema Towers にて行われました。 動画 Prometheus Tokyo Meetup #2 - YouTube 入門 Prometheus スピーカー : Kazu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
監視とは何か ～監視エンジニアのスキルと成長～
Security by builders - セキュリティ監視をクラウドで「つくる」 / Security by builders
