SampleAgeLimitというのがmainにマージされたのを観測したのでちょっと歴史を含めてメモしておくという雑記事です。 三行 1) 2.11.0 / 2019-07-09 MaxRetriesが削除された 2) 2.32.0 / 2021-12-09 MaxBackoffが100msから5secに変更 3) xxx / 2024-01-05 SampleAgeLimitが追加されmainにマージされた（デフォルトは無効） 2年おきくらいになにがしか更新がある RemoteWriteがんばり過ぎ問題 プロダクション環境の信頼性を損ねず観測する技術 - Speaker Deck こういうの PrometheusのRemoteWriteはExponential Backoffなリトライをする しかしMaxBackoffに到達するとそこでひたすらRetryを繰り返す WALは2h程度で

この記事はSRE Advent Calendar 2023の4日目の記事です。 qiita.com 3日目は@myu_mxさんのゆるやか成長スタートアップの小さなEnabling SRE的活動でした。 久々のアドカレ参加ですが、少し思いの丈に任せてみようということで経験と主観が強めの記事です。 この辺で語られていたよとかこれは賛同できないというポイントなどもっといい情報があればぜひお知らせください、という感じで雑多に書いて参ります。 TerraformやCloudformationあたりをよく触るのでそのあたりがどうしても頭にありますがなるべく固有の話はしない方向で。 色々書きつつ、基本的には長期的な運用を見越したソフトウェアの運用設計と同じ考えで良いとは思ってます。 最低限のインターフェースを公開し疎結合に設計する、モジュールは交換可能する、ライフサクルを考える、などなど。 ただIaCコ

インフラストリーミングチームの近藤 (@udzura) です。今回は、ミラティブで内製しているオブジェクトストレージサーバ「b3」の紹介記事を書きたいと思います。 今回の記事は、6月にGopher Talkというイベントで発表した「Go製ミドルウェアを実践投入するにあたりやったこと」をベースに、内容を詳細にしたり直近の開発状況に合わせて更新したものです。一部内容はこの発表と重複していますがご了承ください。 オブジェクトストレージサーバを内製した背景 1. 大量オブジェクトの操作や増え続ける転送量に対応したい 2. 一定期間しかファイルの保持をしない 3. オンメモリ/SSD/HDDを組み合わせたチューニングがしたい オブジェクトストレージb3の特徴 S3 互換の基本的なAPIを実装 LSM-Tree index＋WALなDB/マージ操作に対応 I/O 帯域を制限可能 非同期レプリケーション

登壇＆参加記事です 今までのあらすじ（ずっとアラートの話してる気がする） 今回の発表まわりの蛇足 セッション ギークがイオンに飛び込んだ結果がやばい〜Reliabilityと経営〜 LINEスタンプのSREing事例集：大量のスパイクアクセスを捌くためのSREing エンジニアのためのSRE論文への招待 【コミュニティコラボ企画】パネルディスカッション 〜信頼性に関わる、ご近所さんが集まりました〜 ブルームバーグのセントラル・テレメトリー・システムが業務にもたらす価値 開発者とともに作る Site Reliability Engineering 信頼性目標とシステムアーキテクチャー セッション以外 今後について 今までのあらすじ（ずっとアラートの話してる気がする） 2020 dasalog.hatenablog.jp 2022 dasalog.hatenablog.jp 開発者とともに作る

明らかに誤ったことをしたのにそれを認められずに醜態をさらしている、場合によっては傷口を広げて自分を窮地に追い込んでいる人を大量に見てきた結果、「こうはなりたくないな」と思う気持ちがずっとありました。にもかかわらず、数年前に見事に過ちを認められずに、謝罪できずに無様な姿をさらしたことがありました。公の場でやったことではないし、もしかすると謝罪されるべきだった相手は気にしていなかったかもしれませんが、自分から見れば間違いなく無様でした。 こういうことがあって以来、誤りを認める練習をするようになりました。練習といっても、壁に向かって謝罪し続けるというような話ではなく、自分の言ったこと、書いたことが間違っていたとわかったら、何もしなくてもその場はやりすごせそうな小さなことでも即座に「これは誤っていた」と表明するということをやっています。小さな誤りを認められなければ、大きな過ちを犯したときにも認めら

こちらを最近読んで takumif.hatenablog.com 一年前の記事ですがめちゃよくまっていてすばらしいですね。 当時子が産まれるちょい前くらいのタイミングで男性育児系の記事いくつか読んだのだけどこれ読んでなかったなと思ったら時期が微妙にずれていたのでした。 育児中、だいたい手が空かないのでぴよログのalexa連携はめちゃ良いですね、皆使うと良いと思う。実装してくれたぴよログの人ありがとう。 ということで、最近育児記事みたいなのも増えてきましたが自分も覚えてるうちに少しは書いておこうという気持ちで、サンプル1/1程度のなにかをざっと書いてみましたなやつです。 どんな状態だったか 最初の子 育休期間は4ヶ月弱 夏生まれ 生まれてから一ヶ月ちょいまで妻の母が泊まりでサポートに来てくれていた 我が家の場合 基本的な役割分担 自分と妻が交代で子のお世話 妻の母が家事サポート 実際は家事以

Intro 最近はGoでApiサーバーを作っています。早いうちからコードをdev環境にデプロイして、みんなでワイワイそれを叩いてフロントを開発しているのですが、いかんせん開発中なのでバグがあります。 そうるるとpodにログを見に行って、500エラーを返している箇所付近のログを探すのですが、そもそも詳細な値をログに落としていなかったり、ログ中のどの行がどのリクエストに対応しているのか分からず、調査は難航します。 そこで、traceを取ってみることにしました。 traceは主に処理時間の内訳や呼び出しの依存関係を示してくれますが、スパンのコンテキストにいろんな値を保持しておき、それをエラーログと結びつけることでデバッグに便利に使えます。また、自身でtraceやlogの記録・可視化を行う環境を構築することは面倒ですが、GrafanaCloudの無料枠を使うとこれが快適に行えるので今回はこれを活用

インフラのいわほり（egmc）です。 eBPFを利用したプロダクトとしてはCiliumなどがcloud nativeな文脈として盛り上がっていますが、一方でBCC Toolsやbpftaceは、システム内部のかゆいところに手が届くソリューションとして身近な課題解決にカジュアルに役立つツールとして提供されています。 これらのツールは実際に便利ではあるものの現実世界での事例をそれほど見かけないというのもあり、「こんな感じで役に立った」という事例をカジュアルに紹介していくのもコミュニティにとって有用ではないか、ということで今回はOSのバージョンアップに関連して発生した問題の調査にbpftraceが役立ったというお話をご紹介したいと思います。 環境 Ubuntu 20.04.6 LTS bpftrace v0.9.4 発生した事象 GREEのクラウド環境で利用しているシステムのアラートの配送を行う

サマリ Linuxにおいて使用メモリの情報はだいたい/proc/meminfoの情報から計算されるが、計算式にゆらぎがあって異なるツールやSaaSエージェントを使うと結果が異なることがあるので故あって調べた ダッシュボードの表示とfree(1)の結果が異なるなど 2023現在使用メモリはだいたいMemTotal-MemAvailableということでOK free(1)などprocps依存なコマンドもMemTotal-MemAvailableをUsedとして扱うようになる 稀に計算式が異なるケースもあるのでおかしいな、と思うことがあれば一応まだ気にしたほうがよいことがあるかもしれない ツールをまたぐ時は特に 各種SaaSやツールの状況 procps v4.0.1からMemTotal - MemAvailable、それ以前はMemTotal - MemFree - Buffers - Cach

高木　2年前だから、まだワクチンもなくて、医者も治し方を知らないし、世の中がてんてこ舞いになってた時期だよ。よりによってそんな時に罹るなんて……。今なら助かって帰ってくる人も多いだろ。そう考えると、余計なこと言うようだけど、もし志村があと1週間でもコロナに罹るのが遅かったら、きっと助かってたよ。もっと病院の体制も整っていてさ、違った結果になったと思うんだよな。 加藤　まあな。でもあいつだって罹りたくて罹ったわけじゃないからさ。不可抗力だよ。 高木　不可抗力だなんて、一言じゃ言えないよ。あんな早い時期に罹って、やっぱバカだよ。 加藤　いや、言えるんだよ。罹ったのは仕方ない。あの頃は、無理だったんだよ。 高木　そうかな。 加藤　長さん（いかりや長介）が死んで18年だろ。あっという間だよな。こんなこと言うとなんだけどさ、志村がいないとコントはできないけど、長さんがいなくても、不思議と4人だけでも

登壇＆参加エントリです。 ややエモよりになる予定。 当日の体験については他の登壇者の皆様とも少しお話したんですが、完全に馬場さんのエントリに書かれている点と同じ感想であり（事前収録は当日落ち着けてよい、参加者としてのZoom Event体験はかなり良かった、ブースの仕様はやや残念ではあったが個人的にはそれでも楽しめた）、まあ同じことを書いてもということで発表まわりや個別の参加体験の方を書いていきます。 登壇について プロダクション環境の信頼性を損ねず観測する技術というタイトルで登壇させて頂きました。 6/9時点でまだスライドのみですが、ぼちぼちアーカイブの方も上がってくるかなと思います。 www.youtube.com 前回2020の登壇から2年、SRE NEXTが開催されたら何はともあれproposalは出したいと考えていたので募集の段階でネタを考えました。 ネタは2本考え、1つは長期運

1987年東京出身。会社員。ハンバーグやカレーやチキンライスなどが好物なので、舌が子供すぎやしないかと心配になるときがある。だがコーヒーはブラックでも飲める。動画インタビュー 前の記事：土曜のお便り 〜家族の一員としての椅子 不満はないがトキメキもない うちには4歳の子どもがいて、朝保育園に連れていき、そのあと家に帰って家事と仕事をして夕方迎えに行く、というスケジュールを繰り返している。 そして数日に一回、近所のスーパーに買い物に行くというルーティンがある。ご飯の材料と、歯磨き粉とかラップとかを買う。 特別な予定が入らない限りはこの繰り返しである。いつものスーパーはいつ行ってもいつものスーパーである。不満はないがトキメキもない。 突然どこか遠くへ行ってしまいたい ならば、通勤中に反対のホームに来た特急電車に飛び乗るように、突然どこか遠くに行ってしまえばいい。 会社だったらその特急の中で上司

インフラ・ストリーミングチームの近藤 (id:udzura) です。 ミラティブのインフラ運用では、監視・自動化などさまざまなツールにGo言語を利用しています。ツールはコマンドラインツールとして提供して、バージョンごとにリリースを作成して各環境にデプロイしています。リリースの作成にはGitHubのRelease機能を利用しています。 今回は、GitHub Releaseの作成をGoogle Cloud Build（以下、単にCloud Build）で自動化したことについて、実装内容と効果を書いていきます。 なぜ Cloud Build を採用したか ミラティブの開発はGitHub Enterprise Cloudを利用しています。対応するCI/CDのサービスとしてはGitHub ActionsやCircleCIなど*1数多くありますが、ミラティブにおいてはGCPの利用箇所が多く、既存GCP

オンコールアラートを設定しようと考えた際に考慮すべき点を自分なりにアンチパターンとしてまとめたなにかです。 ホワイトボックスモニタリングにより得られたメトリクス、ログなどからアラーティングを行う、または併用する環境を想定しています、ブラックボックスモニタリングによるアラート、SLOベースのアラートのみでうまく運用されているサービスにはあてはまらないと考えてます。 参考書籍は色々あり、最後に記載していますが提示されてるプラクティス通りではないものもあります 。自組織、システムにあった設計をしましょう。 システムの監視がまったくありませんみたいな状況であればまずはサービスのURLに対する外形監視からはじめましょう。 言葉の定義 アンチパターン サービスに対する外形監視が設定されていない アラートを受け取って直ちに何かアクションを行う必要がない アラートに対応するrunbookが存在しない 自動

こんにちは、インフラの小林です。 GCP環境の監視基盤が一段落し実績も積めてきたので、アーキテクチャについて簡単に紹介します。この記事ではメトリックに焦点を当てています。Prometheusを用いたGCP監視基盤を検討している方や、Managed Prometheusを検討している方の参考になれば幸いです。 アーキテクチャ 比較のためにAWS EKS環境と合わせて紹介します。 AWS (EKS) AWS EKS環境では、監視用EC2インスタンスがあり、k8s Cluster内にはExporterのみが存在します。 k8s Cluster外部からkubernetes_sd_configを用いたService Discoveryを行い、メトリックを回収します。AWS環境はプロダクトによってVM, コンテナの利用がまちまちなため、両ケースに対応できるよう監視インスタンスはコンテナではなくVMとし

先日書かれた、こちらの記事を見まして。 クラスタ化された Payara Server のアップグレード - notepad ちょっと気になったのは、こちらの部分。 Case 1 : Shoal を使用していない場合 Payara は GlassFish から引き継いだ Shoal を使用しなくても、Hazelcast のみでクラスタリングが可能です。その場合はおそらく、すべてのノードが DAS となっているはずで、通常のアップグレードをすべてのノードに対して実施すればよいことになります。ノードの接続・切断は Hazelcast が自動的に行うため考慮する必要はありません。 http://www.coppermine.jp/docs/notepad/2017/12/how-to-update-clustered-payara-server.html 確かにそのとおりだと思うのですが、個人的に

タイトルままということで。 github.com goでゼロからexporterを書こう、sysloadの実装を今更ながら把握しておこうというモチベーションのもとsysloadをprometheusのexporterとして実装してみました。 dashboard image Dashboardも公開しているの動かして見るぜーという方はこちらもどうぞ。 クエリみて頂ければわかりますが、設計上sysloadの値は単純なgaugeなので既存のノード用ダッシュボードに組み込むのも簡単だとおもいます。 grafana.com sysload is 何 labs.gree.jp 詳細はこちらの記事とgithubレポジトリを参照頂ければとおもいます。 もともとLoad Averageの不具合を起因としてサーバ負荷（システムリソースのsaturation）を0-100で表す指標として開発されたものです。 単

今年はDay1のみリアタイ参戦したのでいくつかセッションのメモを。 内容は全部見ればわかるやろ程度ではあるもののまあポインタ程度の情報でもないよりは良いのではということで感想交えて雑に書いてみようという感じのやつです。 動画はすでに上がっていて個別のセッションはYouTube字幕もすでについていてセッションだけをみるならそちらがよい、QA含めてみるためにはDay1,2それぞれ全部入りの動画をみればおっけーという感じ。ただしDay1のeBPF for Windowsは若干音声まわりのトラブルがあったのでセッション個別はそちらを参照する方がおすすめです。 全体的な雰囲気とか所感とか eBPF Summit自体は初回からオンライン開催、事前収録+リアルタイムQAスタイルでコミュニケーションはslack、trackも一本なのであっちこっち移動したりスポンサー的な何かがあったりはしないのでここに集中

この問題を解決するため、もともとのコードベースであるところのモノリスもコンテナ化してKubernetesに乗せることにしました。ツールセットの統一をすることでよりシンプルな体系ができ、プラットフォームチームも一つの環境向けの改善に注力できるようになります。 プロジェクトの流れ PoC 計画についてあたため始めた際にちょうどよくUSチーム内でのハッカソンイベントがあったため、それに合わせて試しにKubernetesで動かすデモを発表しました。デモで見せる部分はごく限られたものだったため3人で3日くらい集中して開発したところ動くものができあがりました。 デモの評判は上々でEM、CTOに説明し実際にプロジェクトとしてすすめられることになりました。 現状分析 プロジェクト始動後、まず実施することは現状分析とどう移行するかの設計です。ここでのどの程度システムを把握できるかが計画の精度を決めます。しか