はてなブックマーク

Grafanaのダッシュボード表現とGrafonnet Jsonnet、Grafonnetのセットアップ Grizzlyを使う Grizzlyのセットアップ Grizzlyを使ってJSON/形式でダッシュボードを作成する Grizzlyを使ってGrafonnetでダッシュボード管理を作成する まとめ ・・・と一旦まとめた後の雑多な補足 参考 先日、というかもう3ヶ月も経ってしまいましたが Grafana Meetup Japan #1 - connpass にてLTをさせて頂きました。 趣味のダッシュボード開発というテーマで、あわせてGrafanaのダッシュボードをコードで管理するソリューションの1つとして Grizzly GitHub - grafana/grizzly: A utility for managing Jsonnet dashboards against the Graf

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

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

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

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

タイトルままということで。 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も一本なのであっちこっち移動したりスポンサー的な何かがあったりはしないのでここに集中

最近プロダクション環境での諸々の調査に使いたいというモチベーションで BPF Performance Tools (Book) 読み進めつつ、提供されているbcc-toolsを試したりbpftraceでlibほげほげの関数パラメータを抜いたりしていた、のだがUSDTを使用したトレースはうまく動かせず悶々としていた。 正直USDTはパッケージ入れておけばいきなりproductionでさくっと使える、という感じでもなく当初の目的からはやや外れているのだが、機構があるのに動かせないというのはなんとももどかしいので、諸々試行錯誤してとりあえず動いた、というころまでの記録を残しておく。対象はphpで。 なぜphpなのかというと、プライベート的にもお仕事的にも馴染みがありワンチャン使える可能性もあるのでは・・という期待と、ツールを試す過程で標準パッケージのphpで $ tplist-bpfcc -l

前回prometheus+grafanaを導入してNASのモニタリングも開始してみた、の続きで dasalog.hatenablog.jp 雑に起動していたQNAP NAS上のnode_exporterをNAS再起動時に自動起動するようにする小ネタ。 やること 雑いinitスクリプト書く /etc/config/qpkg.confに設定を追加して自動起動する これだけでOK。 環境はQNAP TS-220(QTS 4.3.3.0299) 以下順に 雑いinitスクリプト書く /etc/init.d以下のスクリプトを眺めつつ、こちら QNAP TS-469Lをmackerelを使ってモニタリングする | misty-magic.h でmackerel-agentをQNAP上で起動されてる事例を参考に、というか割と流用させて頂きつつとりあえずstop、startだけ出来るスクリプトを用意。 他