さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog
こんにちは、エンジニアリングマネージャーの id:onk です。 Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の id:onishi、CTOの id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。 id:onkが担当する第9回のゲストは、さくらインターネット株式会社の組織内研究所であるさくらインターネット研究所の上級研究員で、SRE （Site Reliability Engineering）の研究者としても活躍する id:y_uuki さんこと、坪内佑樹さんです。 2013年にはてなに新卒でWebオペレーションエンジニアとして入社後、サーバー監視サービス「Mackerel」をはじめとするサービス開発やはてなのインフラ開発・運用にSR
![さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b5961cfe7e9736ef0e88bc0290b1599481d2626/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20240319%2F20240319125826.jpg)
2024年11月、Mackerelのメトリックがオブザーバビリティ標準であるOpenTelemetryに正式対応し、あわせて価格体系を全面的に改定します - Mackerel お知らせ #mackerelio
現在パブリックベータとして提供しているOpenTelemetry対応を2024年11月1日に正式リリースいたします。また、機能に合わせた価格体系の見直し（価格引き上げも含む）を行います。 OpenTelemetry対応と今後のMackerelの開発方針について クラウドネイティブな開発を進めていくと、システム内で何が起きるのかあらかじめ予測して監視・対応しておく、ということが困難になってきます。こういった環境ではシステム内部の状態を把握できるように多角的に観測可能にしておく、可観測性を上げておくことが重要となります。このような環境に対応していくため、Mackerelはメトリックを多次元的に扱うことができる「OpenTelemetry対応」を2024年11月1日に正式リリースします。 OpenTelemetry対応機能は、以下の特徴を持っています。 メタデータを付与した多次元的なメトリックの
Mackerel の OpenTelemetry（ラベル付きメトリック）をオンプレサーバで試した備忘録 - Qiita
動機 今更ながら Mackerel で OpenTelemetry（ラベル付きメトリック）を試したくなったが、探しても Docker + ECR とか K8S とか最近流行りの情報ばかり出てきて、現在の社内サーバの状況には合わなかったため、備忘録としてまず Nginx のラベル付きメトリックを投稿できるところまで書いておく。 サーバ情報 OS : Rocky Linux 8 まぁ使い始めてしまったのでしょうがない Nginx : 1.22.1 Nginx の準備 適当に stub_status を出せる location を用意。 （OpenTelemetry の nginx receiver が http_stub_status を元に投稿するらしいので）
なぜ Mackerel は OpenTelemetry のラベル付きメトリックをサポートするのか - Mackerel お知らせ #mackerelio
現在 Mackerel では、ラベル付きメトリックに対応するための開発を進めています。ラベル付きメトリックは、OpenTelemetry の仕様に準拠した Mackerel の新しい機能の名称であり、クエリを引く際には PromQL を使用できるといった特徴があります。 本日、この「ラベル付きメトリック機能」ベータ版テストの参加募集を開始します。詳細については後述いたしますので、まずはこの機能の背景についてご一読いただければと思います。 OpenTelemetry とは、メトリック・ログ・トレースなどのテレメトリーデータを収集し、任意のバックエンドへエクスポートすることを目指して標準規格を定めたオープンソースのプロジェクトです。詳しくは OpenTelemetry のドキュメントをご覧ください。 opentelemetry.io ホストやサービスのメトリックを収集するために、Mackere
MackerelとGrafana OnCallを連携しました - KAYAC engineers' blog
SREチームの藤原です。今回は監視サービスのMackerelと、障害発生時に担当者へのオンコールを自動化するGrafana OnCallを連携してみた話です。SRE連載 6月号になります。 3行でまとめ MackerelとGrafana OnCallを連携しました MackerelのアラートWebhookをGrafana OnCallのWebhookに変換するproxyをAWS Lambdaで作りました。OSSで公開しています Grafana OnCallの管理はTerraformでやっています はじめに カヤックでは、運用しているサービスの監視のためにMackerelを利用しています。サービスで障害が発生した場合に担当者を呼び出す(オンコール)ためのツールとして、2023年3月までは ryotarai/waker を使用していました。 wakerはもともとクックパッド社で利用されるために
Mackerelを使ったSLI/SLOによるサービス運用の紹介 - Mackerel お知らせ #mackerelio
この記事では、Mackerelを使ったSLI/SLOによるサービス運用を紹介します。 SLI/SLOとは何か SLIの実装 SLOの設定 エラーバジェットとは さらに詳しく知るには MackerelでのSLI/SLO運用 SLI/SLOを策定する 可用性の計測 レイテンシの計測 ダッシュボードで定期的に状況を確認する 式による監視でモニタリングする SLI/SLOを運用と開発に活用するためには まとめ SLI/SLOとは何か SLI(Service Level Indicator)とはユーザーに提供したいサービスのレベル(水準)を計測する指標であり、SLO(Service Level Objective)とはSLIの目標値です。 サービスレベルを適切に定め、その指標(SLI)を実装・計測し、設定した目標値(SLO)を満たしているかどうかを定期的に確認することで、サービスレベルを適切に改善す
RDS移行の影響をひと目で確認できるダッシュボードをMackerelで作成した - Hatena Developer Blog
こんにちは、ブログチームでエンジニアをしている id:Furutsuki です。ブログチームでは長らくEC2上でMySQLを運用していましたが、種々の理由により2021年末から2022年中盤にかけて、このデータベースをAmazon RDSに移行しました。 移行にあたって、新旧のデータベースやサービスの様子を一覧できる“RDS化ダッシュボード”をMackerelで作成しました。チームでは日常的な監視にダッシュボードを活用していますが、個人的にダッシュボードを一から作ったのは初めてだったので、このダッシュボードの配置や狙いについて書いてみようと思います。 RDS化ダッシュボードの全体像 サービスの状態を確認するコーナーの詳細 DBの様子の変遷を確認するコーナーの詳細 皆さんのダッシュボードを教えてください！ RDS化ダッシュボードの全体像 まずはダッシュボード全体をご覧ください。 こうして画像
AWSインテグレーションがCodeBuildに対応しました ほか - Mackerel お知らせ #mackerelio
こんにちは。Mackerelチーム CRE の西山（ id:tukaelu ）です。今回のアップデート内容をお知らせします。 AWSインテグレーションがCodeBuildに対応しました レスポンスタイム監視が有効な外形監視のアラート詳細画面のグラフに閾値の線を表示するように改善しました 一部の画面のURLが変更になりました AWSインテグレーションがCodeBuildに対応しました AWSインテグレーションの対応サービスにAWS CodeBuildを追加しました。 これによりアプリケーションのビルドにかかる所要時間などに対して閾値を設け、抵触する場合にアラート通知することが可能になります。 取得できるメトリックや注意事項など詳細は以下ヘルプを参照ください。 mackerel.io レスポンスタイム監視が有効な外形監視のアラート詳細画面のグラフに閾値の線を表示するように改善しました レスポン
Mackerel エバンジェリスト始めました - そーだいなるらくがき帳
この度、お仕事として公式エバンジェリストをすることになりました。 セミナー講師をやったり、Mackerelの便利な使い方をアウトプットしたりするのが役割です。 MackerelチームにはCREってロールがあるわけですが、その中でも顧客活動のサポートにあたります。 ついにMackerelプラグイン解説シリーズの続編とか出るかもしれません*1。 初回活動 プライベートセミナーをやります。 詳細は下記のページを御覧ください。 日時：2022年2月10日（木） 14:00〜15:00 会場：Zoom Webinar 参加費用：無料 お申し込み：イベントページからお申し込みください はじめてのMackerelクラウド監視入門編（2022年2月10日開催オンラインセミナー） connpassもあるけど、申込みは上記のサイトです。 mackerelio.connpass.com はてなはCREを募集して
mkrコマンド / API でホストのメモを登録できるようにしました ほか - Mackerel お知らせ #mackerelio
こんにちは。Mackerelチーム CRE の三浦（ id:missasan ）です。今回のアップデート内容をお知らせします。 mkrコマンド / API でホストのメモを登録できるようにしました アラートIDを指定してアラート情報を取得できるAPIを公開しました Appleシリコン搭載のMacへmackerel-agentをインストールできるようにしました CentOS Stream 8 を対応環境に追加しました 障害やメンテナンスの情報をカレンダー購読できるようにしました mkrコマンド / API でホストのメモを登録できるようにしました Mackerelでは、ホストに対して任意のメモを残すことができます。 Webコンソールから設定する際は、以下をクリックします。 このホストのメモを mkrコマンド / API から登録できるよう変更しました。 mkrコマンドでは create およ
MackerelでSLI/SLO運用をする際に役立つ機能やツールの紹介 - Mackerel お知らせ #mackerelio
この記事は Mackerel Advent Calendar 2021 の17日目の記事です。 Mackerel SREチームのid:masayoshi です。 今回はAWS ECSとALBで構築したWebアプリケーションを例に、Mackerelを利用したSLI/SLOの設定、運用改善に利用できる機能やツールを紹介したいと思います。 今回紹介する機能やツールの概要図です。 ALB+ECS環境とMackerel まずは、ECSで動いているWebアプリケーションのSLI/SLOを考えていきましょう。 最初から複雑なSLI/SLOを設定、実装するのは難しいため、簡単に取得できるメトリックや監視設定から運用を始めていき、徐々に監視を改善していくことをおすすめします。 ここでは、以下のようなSLI/SLOを設定したと仮定して、メトリックの取得する方法など見ていきましょう。 レイテンシー HTTPレス
CloudWatch Logs Insights を使って Mackerel 上にアプリケーションのメトリック監視環境を手早く構築する - Object.create(null)
この記事は Mackerel Advent Calendar 2021 の 15 日目の記事です. 昨日は id:kazeburo さんの mkr plugin install 時の403 API rate limit exceededエラーを回避する方法 でした. こんにちは id:susisu です. 普段は Mackerel 開発チームでアプリケーションエンジニアをしています. 先日 mackerelio-labs にて cloudwatch-logs-aggregator という Terraform モジュールをひっそりと公開しました. github.com この記事では, このモジュールについてと, これを使って AWS 環境で動作するアプリケーションのメトリックの監視環境を手早く Mackerel 上に構築する方法を紹介します. アプリケーションのメトリックについて (ここでア
mkr plugin install 時の403 API rate limit exceededエラーを回避する方法 - Hateburo: kazeburo hatenablog
この記事はMackerel Advent Calendar 2021の14日目の記事です。 最近、さくらのクラウドの一部のサービスの監視にmackerelを導入し始めました！ そして今年もいくつかのmackerel pluginを作成しています。 ログをメトリクスにするプラグイン github.com インターフェイスごとのエラーや送受信したパケットを可視化するプラグイン github.com 100%上限のCPU使用率グラフ、ロードアベレージをコア数で割ったメトリックを作成するプラグイン github.com そのほか、mackerel-plugin-axslogにも新しい機能が増えています。 この記事は既存のサーバにこれらのmackerel pluginをansibleで導入していった際に出たエラーと回避策のお話です。 mkr plugin install時のrate limitエラー
terraform-provider-mackerel のデバッグ手法 - Qiita
これは Mackerel Advent Calendar 2021 の6日目の記事です。 こんにちは。はてな Mackerel チーム SRE の hayajo です。 昨日は @tatsuru さんによる Apple Silicon MacBook のCPU使用状況をMackerelで可視化する - wtatsuruの技術方面のブログ でした。私も M1 Mac が欲しいですねー。 今日は terrafrom-provider-mackerel のデバッグ手法についてご紹介します。 詳細なログ出力を有効にする terraform 本体やプロバイダの詳細なログを出力してデバッグに役立てます。 ログ出力を有効化するには環境変数 TF_LOG を設定します。
MackerelでSLOとエラーバジェットを運用するためのツール shimesaba - KAYAC engineers' blog
この記事はMackerel Advent Calendar 2021の7日目です。 こんにちは、SREチーム所属の@mashiikeです。 皆様はSLOとエラーバジェットという言葉を聞いたことはありますか？ サービスの信頼性を保証することを目標するSRE（Site Reliability Engineer／Site Reliability Engineering）の領域に携わってる方なら聞いたことがあると思います。 今回は、SLOとエラーバジェットに関して、Mackerelを用いてサービス/サーバー監視をしている際に便利なツールとして shimesaba というものを作った話をします。 github.com はじめに 本題に入る前に、SLIやSLO, エラーバジェットという言葉について触れておきます。 これらの言葉は、ざっくりと説明すると以下のようになります。 SLI(Service Le
Apple Silicon MacBook のCPU使用状況をMackerelで可視化する - wtatsuruの技術方面のブログ
これは Mackerel Advent Calendar 2021 の5日目の記事です。昨日は @sogaoh さんによる [Day.04] Mackerel で かんたん AWS SES の bounce rate 監視 でした。 はじめに 先日、仕事用マシンを Apple Silicon 搭載の MacBook Pro 14インチ (2021) に更新しました。2018年の13インチからの乗り換えだったんですが、快適さに驚いています。リモートワークでビデオ通話を含む多くのツールを同時に動かすことも多いんですが、引っ掛かりを感じることがほとんどなく過ごせています。 今日から M1 MacBook Pro に変えて仕事してるのだけど、ビデオ通話しながら Google Docs を複数開いて miro に絵を描きつつ裏で docker build する、みたいな荒い使い方しても普通に快適に過
[Day.04] Mackerel で かんたん AWS SES の bounce rate 監視
Mackerel Advent Calendar 2021 4日目[1]のエントリです。 メールって水面下でいろいろな苦労があるんですよね。何気なく使われていて、送受信できて当たり前って思われがちですけど。 その水面下の苦労の１つにバウンス率の監視があるかなと思っていて、それを Mackerel でかなり容易にできるのでご紹介します、という記事です。 「おっ、便利そう」と思って軽く実践してみたり、バウンス率を気にしていただければ幸いです。 バウンスとは こちらに大変分かりやすくまとまっていると思います。 バウンス率が高くなると ひどい状況だと、SES でメールが送れなくなっちゃいます。 どうやってバウンス率を可視化するのか Mackerel の AWS インテグレーション - SES を利用するのがオススメです。 全メトリックを指定しても１マイクロホスト[2] 設定画面 インテグレーション
![[Day.04] Mackerel で かんたん AWS SES の bounce rate 監視](https://cdn-ak-scissors.b.st-hatena.com/image/square/345a6e007780e1473ad6e1aa1ecd3aa27655f2d8/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--viT8I9dY--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BDay.04%25255D%252520Mackerel%252520%2525E3%252581%2525A7%252520%2525E3%252581%25258B%2525E3%252582%252593%2525E3%252581%25259F%2525E3%252582%252593%252520AWS%252520SES%252520%2525E3%252581%2525AE%252520bounce%252520rate%252520%2525E7%25259B%2525A3%2525E8%2525A6%252596%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Asogaoh%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2dqeUJ2UUNtOE5IT3JDdTNoNi1MTkhsaWp1ZmVfTlB0ZU9sV1ZxSlE9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
Pubs/Mackerel Ambassador (sogaoh) blogs/RaspberryPiからSpeedtestCLIの結果をMackerelサービスメトリックに投稿する (2)
このエントリは @sogaoh の Mackerel Ambassador としての記事 その４です。 Proof of Mackerel Ambassodor (I use Mackerel since 2019.) 前回 1 は回線速度を定期的に自動で計測する準備として mackerel-agent と公式プラグインを RaspberryPi にインストールするところまでを書きました。 今回はいよいよ Speedtest.net の公式CLI のインストール、そして「定期的に自動で計測」を mackarel-agent との合わせ技で実現する sardine のインストールとプロセス常駐化について話していきます。 > [再掲]インストール時に利用したコード一式 (Ansible Roles)[再掲]インストール時に利用したコード一式 (Ansible Roles) 今回の分は自分で言っ
自宅の回線が時間によってめちゃくちゃ遅くなるのをMackerelとSpeedtest CLIで可視化した | DevelopersIO
結果 こうなりました（結論からさらすスタイル）。 いまの御時世の固定回線で 下り 3Mbps って何ですかね？？？ というのは実は本題ではなくて、このようなグラフを作ることがこの記事の本題です。 背景 状況については冒頭の概要に書いたとおりなのですが、とにかく自宅のネットワーク回線を定期的に測定して可視化することを試みました。 ちなみに我が家は古い賃貸集合住宅で VDSL なので、上限は 100Mbps になります。それでもそこそこ快適で、特に不満もなかったのですが1、今月に入った辺りから急に回線状況の悪い時間帯に出くわすようになってしまいました。 改善策をとるまえにまずは計測、ということで、今回の試みとなったわけです。 仕組み ざっくりいうと、 自宅の Windows PC に Hyper-V で Linux を動作させ その Ubuntu にmackerel-agentを導入し 10
資料 - 導入事例：株式会社ベネッセホールディングス様 - Mackerel（マカレル）: 新世代のサーバー管理・監視サービス
導入事例株式会社ベネッセホールディングス様 監視サービスMackerelを1,000台規模で展開 カスタムメトリックで監視を「育てる」 「アラートが上がれば対処する」監視から、「予兆を事前にキャッチする」監視、「開発・事業部・経営層にも共有できる」監視を作ったサクセスストーリーをご紹介。あるシステム障害にはじまり、チームでの導入、そして1,000台規模のグループ全社導入に至った経緯と共に、成功のキーとなった「育てる監視」の取り組みについてお話いただいています。大規模システムの監視に悩む方はもちろん、規模は問わず監視体制作りを考えている方におすすめです。＜資料：全7ページ＞
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
