特徴的な損失関数(Loss Functions)についてそのアイディアとPyTorchの実装を紹介。
明日使えるかもしれないLoss Functionsのアイディアと実装
特徴的な損失関数(Loss Functions)についてそのアイディアとPyTorchの実装を紹介。
DatadogでECS Fargate TaskのCPU利用率が100%を超えて表示されていたので調べてみた - Classi開発者ブログ
こんにちは。開発本部の遠藤です。 ClassiではAmazon ECSをアプリケーション実行環境として利用しています。 ECSの各種メトリクスをDatadogを使ってモニタリングしながら、日々安定稼働しているかどうかをチェックしています。 そのうちの一つの重要なメトリクスとして、ECSのFargate TaskのCPU利用率が過度に高まっていないか、があるのですが、ある時期、CPU利用率が100%を超えてしまっていて「一体なにが起きてるんだ？？」と疑問を持ちました。 今回はそれについて深堀りしてみたので、ニッチなトピックですが紹介したいと思います。 ECS Fargate TaskのCPU利用率が100%を超えて表示されている こちらが実際にCPU利用率が100%を超えてしまったときのグラフです。 Datadogのメトリクスは ecs.fargate.cpu.percent です。なお、c
「Datadog入れてみたらAWSの料金が爆発した話」@ゆるSRE勉強会 #1
ゆるSRE勉強会 #1 でお話しさせて頂いたLTの資料です！ https://yuru-sre.connpass.com/event/292063/
オブザーバビリティにはお金がかかる - 株式会社ヘンリー エンジニアブログ
tl;dr オブザーバビリティにはあなたの直感よりもお金がかかるかもしれない。でもそれはアジリティを上げるために必要なコストである。同時にオブザーバビリティ関連ベンダーには、それらをリーズナブルに提供してもらうことを期待します。 オブザーバビリティ・エンジニアリング輪読会 8月からVPoEになりました。id:Songmuです。 社内の勉強会で輪読形式でオブザーバービリティ・エンジニアリングを読んでいます。毎週30分、参加者の中から発表者を割り当て、1~2章を読み進めるスタイルです。 ちなみに、ヘンリーではActive Book Dialogue(ADB)というフォーマットも取り入れて輪読会が運営されています。社内で同時並行で数本走っており、先日、CEOの逆瀬川が書いたソフトウェア見積もりに関する輪読会も同様の形式で実施しています。 発表者は、事前に社内のNotionにその章のアウトラインや
監視からオブザーバビリティへ〜オブザーバビリティの成熟度/From Monitoring to Observability - Maturity of Observability
2023/5/23開催「オブザーバビリティ最前線 〜 事例LTから学ぶ、オブザーバビリティの成熟度〜」
分散トレーシングとOpenTelemetryのススメ / Getting started distributed tracing and OpenTelemetry
OCHaCafe Season7 の LT 資料です。 https://ochacafe.connpass.com/event/282817/
Kubernetes の Probe の仕組みと考慮点
Kubernetes 1.26 時点の話で、以降のマイナーバージョンで改善されている可能性があります。 Kubernetes には、ワークロードの正常性を確認するための Probe という仕組みがあり、Liveness / Readiness / Startup Probe が用意されています。kubelet (Kubernetes のノード上で動作するエージェント) は、ワークロードに対して TCP Socket / HTTP GET / gRPC / Exec の中から指定されたチェックを定期的に実行します。 それぞれの Probe の特性を理解して使い分けないとサービスに影響することがあります。本記事では、Probe の仕組みと考慮すべき点について紹介します。 Probe の仕組み Exec と TCP Socket / HTTP GET / gRPC の Probe の仕組みは異な
今日から分散トレーシングに対応しないといけなくなった人のための opentelemetry-go 入門 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。SRE/データストアチーム の飯塚です。 私たちのチームではデータベースを代理で操作したり情報を取得したりするサービスをいくつか作り、それをプロダクトチームが利用できるように gRPC 経由で提供しています。ところで、ある日突然「分散トレーシングを活用していくことになったので、あなたのチームのサービスも対応させてください」とお願いされたらどうすればよいでしょうか？私はこれまでにいろいろなカンファレンスで分散トレーシングや OpenTelemetry についての講演を聞いていたので、理念は理解した、便利そうだ、導入してみたい、と思ったことは何度かありました。しかし実際に導入しようとして SDK のドキュメントを開いてみると、理解しなければいけない（ように見える）概念や、使い方をマスターしないといけない（ように見える）API の数に圧倒されてしまい、後回しにしてしまっていました。
Kubeletを監視する方法
本文の内容は、2022年11月23日にVICTOR HERNANDOが投稿したブログ（https://sysdig.com/blog/how-to-monitor-kubelet/)を元に日本語に翻訳・再構成した内容となっております。 Kubernetesを本番環境で運用する場合、Kubeletの監視は欠かせません。Kubeletは、Kubernetesクラスター内の非常に重要なサービスです。 このKubernetesコンポーネントは、Podで定義されたコンテナが実行され、健全であることを保証する役割を担っています。スケジューラがPodを実行するノードを指定するとすぐに、Kubeletはその割り当てを受け、Podとそのワークロードを実行します。 Kubernetes Kubeletで問題に直面した場合、できるだけ早く対処して問題を解決することが本当に重要で、そうしないとKubernetes
Istio、サイドカーパターンを不要にする「Ambient Service Mesh」機能をメインブランチに統合、正式な機能へ
Istioは、サービスメッシュを実現する新たな仕組みとして試験的に開発していた「Ambient Service Mesh」をメインブランチに統合し、正式な機能として組み込んで行く方針であることを発表しました。 現在のIstioは、各サービス（≒KubenetesのPod）ごとにプロキシを配置し、サービス間のネットワークをプロキシ経由で構成することによってサービスメッシュを構築しています。これによりサービス間の通信のトラフィックコントロール、暗号化、可観測性（オブザーバビリティ）などの機能が実現されるわけです。 この仕組みは、サービスの隣にプロキシを配置することから、「サイドカー」パターンなどと呼ばれています。 しかしPodごとにサイドカーをデプロイする必要があるため、これにかかる手間やリソースの消費が課題でした。 eBPFを用いたサイドカーフリーなCiliumへ注目が集まる そうした中で最
ArgoCDからDatadogに送るログを削減するテクニックと、苦労したこと - LIVESENSE ENGINEER BLOG
はじめに ArgoCDを構成するコンポーネントについて ArgoCDのログ量問題に直面した背景 ロギングライブラリが複数あることによる苦労 ログレベルを調整した結果 おわりに はじめに インフラストラクチャーグループの @mom0tomo です。普段はマッハバイトのクラウド移行に取り組んだり、コーポレートサイトのCSS/JSと格闘したりしています。最近、少しずつ転職会議のKubernetes運用にも関わるようになりました。 転職会議では、KubernetesクラスターへのCI/CDツールとしてArgoCDを利用しています。 made.livesense.co.jp ArgoCDにはGUIがあるためアプリケーション開発者も親しみやすいなど利点が多いのですが、デフォルトで出力されるログが多く、必要以上にログデータを生成してしまうと言う問題がありました。とくにDatadogのようなログ分析ツール
Prometheusでのさまざまな監視データ取得法 | さくらのナレッジ
Prometheusでは、Prometheus Serverが監視対象にアクセスしてデータを収集するアーキテクチャを採用している。このデータ収集のためのアクセス先（エンドポイント）は「exporter」と呼ばれており、さまざまなソフトウェアやハードウェア向けのものが提供されている。今回はこのexporterについて、独自のデータ取得方法なども含めて紹介する。 公式exporterとサードパーティによるexporter Prometheusのアーキテクチャは前々回の記事で詳しく紹介しているが、Prometheus Serverが監視対象にアクセスしてデータを収集するような構成（Pull型アーキテクチャ）となっている（図1）。このようなアーキテクチャにおいては、監視対象ごとにPrometheus Serverにデータを渡すためのexporterを用意する必要がある。 図1 Prometheus
個人的AWS ログ管理のベースライン - mazyu36の日記
AWSのログ管理についてはいくつか考えるポイントがあると思います。 どのログを保存するか。 CloudWatch Logs（以下CW Logsと記載）とS3のどちらに保存するか、もしくは両方に保存するか などなど。 システムの特性によるところも多いかと思いますが、自分の中でのログ管理のベースラインが定まりつつあるので、頭の整理がてらまとめます。 自分の中での大まかな方針としては以下です。 S3に保存できるものは基本S3に保存する。 以下の場合は、CW Logsに保存する。必要に応じてS3に転送する。 アラームを出したい場合 さっとCW Logs Insightでログを確認したい場合 CW Logs に出さざるを得ない場合 全体像としては以下になります。 なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要など
[書籍レポート] 「オブザーバビリティ・エンジニアリング」はパワーワード満載の「『入門 監視』の次に読むべき本」だった | DevelopersIO
自分の関わるアプリケーションやインフラのモニタリングに困っている？ オーケイ、冒頭からアクセル全開の力強いワードにあふれたこの一冊を紹介するぜ！ はじめに 今年(2023年)の1月末に発売されたこちらの本、もう読まれたという方も多いのではないでしょうか！（挨拶 本記事は、まだ読まれていない、買ってもいないという方に向けて、「紹介しなきゃ」という謎の強い使命感をもって書かれています。 というのも、実は本記事の執筆者（ぼくです）は、300ページを越えるこの本のまだ半分ほどしか読むことが出来ていません。。！ *1 それでもこの本を紹介するモチベーションは十分です。なにしろ、この本は冒頭から、もっといえば「まえがき」の段階から、パワーワードにあふれた一冊だからです。引用してみましょう。 “（「オブザーバビリティ」という）用語が注目されるようになると、ある種の隣接性を共有する別の用語と互換的に使われ
![[書籍レポート] 「オブザーバビリティ・エンジニアリング」はパワーワード満載の「『入門 監視』の次に読むべき本」だった | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/e557ded8e0ecef2f687c73d647f86e0ce3cffd0b/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F02%2F202302-report-observability-engineering-eyecatch.jpg)
AWS監視アラート 事始め - mazyu36の日記
はじめに 入門監視をはじめ一般的な監視に関するプラクティスは出回っているものの、AWSで具体的に何を監視するか？そのとっかかりについてはあまり出回っていないような気がします。 AWSの監視ってみんな何監視してるんすか…っていうぐらい実例あまり見つからないな。門外不出？— mazyu36 (@mazyu36) 2023年2月14日 どこまで監視するかは基本的にシステムの特性によると思います。一方でAWSのサービスごとにシステムによらずよく監視で使う項目というのもあるかと思います。 今回は過去の経験をもとに、最低限この辺りは監視することが多いかなというものをまとめてみます。全体像としては以下になります。 最低限これは監視しないとダメでしょ、とかこれは不要でしょ、などなどあるかと思います。そういうのがあればぜひコメントいただきたいです。 はじめに 「監視」について 前提 1-1. Webサービス
推薦システムの実績をLookerでモニタリングする - ZOZO TECH BLOG
はじめに こんにちは。ML・データ部/推薦基盤ブロックの佐藤（@rayuron）です。私たちは、ZOZOTOWNのパーソナライズを実現する機械学習を用いた推薦システムを開発・運用しています。また、推薦システムの実績を定常的に確認するためのシステムも開発しています。本記事では、Lookerを用いて推薦システムの実績をモニタリングするシステムの改善に取り組んだ件についてご紹介します。 はじめに 改善の背景と課題 背景 課題 課題解決のために 要件1. 指標異常時の自動アラート 要件2. サマリの定期配信 要件3. 上記2つをSlack通知できること ダッシュボードの候補の比較 要件を満たすための設計 要件の実現方法 開発環境と本番環境 実装 ディレクトリ構成 ダッシュボード ダッシュボード構築の流れ 配信実績に関して 推薦結果に関して GitHub Actions 1. 指標異常時の自動アラー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バクラクのAI-OCRを支える精度モニタリング -モニタリングドリブンの改善-
全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
PostgreSQL Architecture And Performance Monitoring
Integrate Kubecost with Datadog