~スタートアップの人たちに捧ぐ~ 監視再入門 in AWShttps://aws-startup-community.connpass.com/event/241721/ 2022/05/10(火) 19:30 〜 21:30 「スタートアップ事例祭り 〜監視・モニタリング・セキュリティ編〜」
[速報] 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)
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環境 とりあえずこれを見てほしい。 これが絶対にだめと言いたいわけではないです。 一時的な検証環境だったり、とにかくスピード重視でサービスをデリバリーさせる必要があったり、サービスの提供者側が何ら責任を負わない・障害時のビジネスインパクトが無い（そんな状況あるのか？）という前提があったり、状況次第ではこれで十分な時もあると思います。 しかし、一般的な業務システムやサービスの場合にはいろんな意味で不十分でしょう。 では、このような環境をどのように育てていくとよいでしょうか。 この記事では、そんな育てかたの一例を紹介していきたいと思います。 なお、本記事はくっそ長いです。 ちなみに、最終的にはこうなります。 文字が小さすぎて読めない！ ちょっとそこのハ○キルーペ貸してくれーｗ
AWSでAZ障害が起きたのでなるべく影響を受けない構成の考えを書いておく - なんかかきたい
AZ障害は受け入れるしかないクラウド時代のインフラ ただの日記。 今日の昼、AWSを利用している人たちは大変だったところもあると思う。 AZの一つが丸々機能しなくなる大きなAWSの障害があり、AWSを利用して運用されていたサービスは多かれ少なかれ影響を受けることになった。 完全に雰囲気で書いてしまうが、今回のAZ障害で影響を受けたサービスは思ったより多かったように感じる。 というのもAWSではアベイラビリティーゾーンの障害は発生するものと考え、本番運用するのであれば、マルチAZ構成を取るのがベストプラクティスとされているので、 マルチAZ構成を取っていれば影響なんてないんじゃないの普通、と思ってしまうと思う。 インフラ屋さんでもそう思ってしまうし、インフラ屋さん以外ならなおさらなんで重くなるのかわからないと思う。 幸い自分の運用しているサービスでは影響が軽微だったので、完全に想像にはなって
AWS chatbot (チャットボット) で コストアラートをSlack通知 - Tech Blog
はじめに エンジニアのウエです。Timers inc.では、ビジネス部門の一人として 配送・印刷・決済に関わる施策立案・業務改善を推進しています。また開発チームのプロダクトマネージャとして、顧客対応チームのマネージャとして、様々な役割でサービスに関わっています。 BizDevOps を通じた 効率化や改善に関わり、とても充実した日々を送っています。 今回の記事では、AWS Chatbot (チャットボット) を Slackへのコストアラート通知に利用した例を記載します。 前提 CloudWatch の Billing を利用するため、あくまでも概算です。 事前準備 ブラウザで Slack に bot用アカウントでログインします。 通知に利用する SNS トピック作成( us-east-1 )します。 手順 AWS chatbot から Client を作成します。 通知先として Slack
【社内資料公開】AWSトラブルシューティングページまとめ／より早い原因把握のために心がけること | DevelopersIO
はじめに こんにちは植木和樹です。オンプレで10年近くサーバーの保守運用をやっていた経験からいいますと、AWSの障害発生率は非常に低くて驚きます。数百台規模のサーバーを扱ってますと、毎日どこかでのサーバーでディスク、CPUファン、メモリーパリティエラーなんかの故障が起きていて日々対応に駆けまわってた覚えがあります。 さてAWSの障害発生率が低いといってもゼロというわけではありません。仮に0.1%だとしても1000日つまり3年運用していれば1回くらい障害に遭遇するものです。0.01%だったとしてもサーバーが1万台あれば1日1回なにかしらのトラブルに遭遇しても不思議ではありません。 トラブルに遭遇すると、当然サービスや処理に影響をきたしてしまうわけで早期の暫定処置と、その後に恒久的な対策が求められます。その時に重要なのは早く正しく原因を特定することです。トラブルシューティング力が重要です。 A
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
