ⓘ人気コメント算出アルゴリズムの一部にヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています さっきまでは無かったのでここ１時間～数十分くらいで変更されたのか 「建設的コメント順位付けモデルAPI」ってのはこれか Yahoo!ニュース、不適切コメントへの対策として導入している深層学習を用いた自然言語処理モデル（AI）のAPIを無償提供開始 - ニュース - ヤフー株式会社 Yahoo!ニュース、不適切コメントへの対策として導入している 深層学習を用いた自然言語処理モデル（AI）のAPIを 「NewsPicks」、「攻略大百科」、「ママスタコミュニティ」へ無償提供開始 - ニュース - ヤフー株式会社
このエントリーは、Mackerel Advent Calendar 2020 5日目の記事です。 さて、多くの人が「自分は文章を書くのが遅い」と思っているのではないでしょうか。僕もそう思っていました。 ブログエントリーを書き出すと得てして思っていた以上の時間がかかります。書くことがだいたい決まっているちょいネタのつもりであっても書き出してみたら数時間かかってしまう、大作であれば丸一日潰れてしまったり、しばらく寝かして数日がかりになることも珍しくありません。そして「ああ、自分は文章を書くのがなんて遅いのだ」と嘆いてしまうのです。 そして、見事な大作ブログ記事をバンバン投稿している人を見ると「書くのが速い人は羨ましいなー」と羨望してしまいます。また故栗本薫氏が、一時間に原稿用紙96枚分を書いたなどの伝説を聞くに、圧倒されて唖然としてしまい、やる気を失ってしまいそうになります。 しかし果たして本
FAQサイト、サポート問い合わせをせずとも自分で疑問を解決できて便利ですよね。でも、検索した単語が一件もヒットしないと、ちょっとガッカリしてしまします。そういったガッカリを減らすために、簡単なデータ分析を使ってFAQサイトを継続的に改善する話を書いてみます。 ...というのも、自分が仕事で関わっているMackerelでは最近FAQをリニューアルしたからなのでした。 MackerelのFAQではZendesk Guideを利用していますが、Zendesk Guideは便利なAPIが用意されているので、それと既存のデータ基盤を組み合わせて改善していく形です。 FAQサイト内の検索語を列挙する まず、FAQサイト内でどういった単語が検索されているのかを列挙します。Google Tag Manager経由でFirebase Analyticsにデータを飛ばすと閲覧状況が分かりますが、そのログをBi
エンジニア大好き「推測するな、計測せよ」。これは、Plan 9, UTF-8やGoの作者としても知られる、Rob Pike氏の Rob Pikes's 5 Rules of ProgrammingのRule 3.に由来すると認識している。以下に原文を引用する。 Rule 3. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rob Pike's 5 Rules of Programming 訳すと以下のようになる。 「計測せよ。計測するまでチューニングをするな、そしてそこが支配的じゃないならチューニングするな。」 要は「チューニングする前に計測せよ」という主張で「推測」と言う言葉は出てこない。なの
こんにちは, Mackerel 開発チーム アプリケーションエンジニアの id:susisu です. 現在 Mackerel では, Web コンソール画面の開発に使用しているフレームワークを, これまで使用してきた AngularJS から React へ移行することを中心とした, フロントエンド開発の刷新プロジェクトを行っています. このプロジェクトの立ち上げについては以前 Hatena Engineer Seminar で発表しましたが, そこでは時間の都合もあり, 技術的側面についてはあまり深く掘り下げることは出来ませんでした. ということでこの記事では, より技術的な面にフォーカスしてプロジェクトの内容をご紹介できればと思います. "React化" プロジェクトについて Mackerel の開発は 2014 年ごろから始まりましたが, フロントエンドのフレームワークとしては当初か
こんにちは。MackerelチームにおいてCRE（Customer Reliability Engineer）をしているid:syou6162です。主にカスタマーサクセスを支えるデータ基盤の構築や、データ分析を担当しています。 今回は、壊れにくいデータ基盤を構築するため、Mackerelチームで実践していることを紹介します。 なぜ壊れにくいデータ基盤を構築するのか データ基盤が“壊れている”とはどういうことか 壊れてないだけでなく、壊れたら気付ける 前提とするシステム構成 壊れたことに気付けるよう監視する 1. バッチジョブが失敗したことに気付く 2. 投入されたデータの性質を監視する 3. ビューが壊れてないかを監視する 4. 利用状況を監視する そもそも壊れてない状態を保つ 1. データリネージを元に修正できるようにする 2. 使われていないテーブルやビューは定期的に掃除 おわりに 参
こんにちは。MackerelチームSREのid:heleeenです。 Mackerelでは、2020年10月14日に計画メンテナンスを実施しました。今回は告知ブログに記載の通り、Mackerelが利用しているRedisをAmazon ElastiCache for Redis（以下、ElastiCache）へ移行しました。 本記事では、この10月の計画停止の裏側を紹介します。 どのようにElastiCacheへ移行するか 大半のRedisを無停止で移行 最後はElastiCacheへのオンライン移行を使用 メンテナンスに向けたさまざまな準備 メンテナンス手順書のチーム内レビュー メンテンス実施中の役割分担 なぜタイムキーパーが必要になったのか リモートで停止メンテナンスを実施する方法 検証環境を利用して事前にリハーサルも実施 Redisを安全に効率よく切り替えるために 参照するRedisを
こんにちは、MackerelチームでSREをしている id:heleeen です。 2023年3月に実施したMackerelのメンテナンスでは、データベースをAmazon RDSからAmazon Auroraに移行しました。この記事ではAuroraを選択した背景や、移行で考慮したことについてお伝えします。 データベースのアップグレードを機に検討 Auroraへ移行することによるメリット パフォーマンスの改善 マイナーバージョンアップのダウンタイムが短く サイジングを適切にできリソース活用も効率的に リードレプリカの運用負荷も改善 Auroraのリードレプリカを利用した移行 RDSにAuroraのリードレプリカを作成する リードレプリカの昇格と切り替え 本番のAurora移行に向けて準備したこと 検証環境で移行して課題を確認 本番メンテナンス時のバックアッププランを用意 Mackerelのメ
プロダクトチームにおけるスキル維持の難しさ プロダクトの運用には、さまざまな知識やスキルが必要です。プロダクトに対するドメイン知識や、プロダクトを実装するために用いているプログラミング言語。アプリケーションフレームワークやミドルウェア、インフラなど数え上げればキリがありません。プロダクトを長い期間運用していくためには、これらの知識やスキルをどのようにチーム内にとどめておくか、ということを考えていく必要があります。 これらは、さまざまな要因でチームから失われていきます。改修や機能追加などで頻繁に手が入るところは良いのですが、あまり手が入らない領域は時間とともに記憶から消えていきます。ドキュメンテーションをしっかりすることである程度防げますが、それでも失われる暗黙知は存在します。また、異動や退職などによって人がチームから去ることもあります。異動や退職の際に、ほとんどの現場では引き継ぎが行われる
2008年にサンフランシスコでスタートしたTwilioは、音声電話やSMS（電話番号宛テキストメッセージ）のプログラマブルなCPaaS（Communications Platform as a Service）です。電話の自動発呼やSMSの送受信ができるAPIを提供し、ソフトウェア開発者がさまざまなコミュニケーション手段を自作のプログラムに組み込めるようにします。 こういったクラウドサービスは、一般のエンドユーザーに向けたサービスを展開したい事業者によって利用されるため、多くの開発者に受け入れられなけばなりません。APIを利用して新たなサービスを作り出す開発者と良好な関係を構築し、顧客である事業者それぞれのビジネスを成長させるポイントは何でしょうか？ KDDIウェブコミュニケーションズ（以下、KWC）でTwilioのエバンジェリストとして活動し、赤い芸人とも呼ばれる高橋克己（@_katsu
私事ですが、今月に入った辺りから急に自宅のネットワーク状況が悪化してしまい、時間帯によってはリモート会議もままならない状況になりました。状況打開策を練るため、とりあえず可視化してみます 結果 こうなりました（結論からさらすスタイル）。 いまの御時世の固定回線で 下り 3Mbps って何ですかね？？？ というのは実は本題ではなくて、このようなグラフを作ることがこの記事の本題です。 背景 状況については冒頭の概要に書いたとおりなのですが、とにかく自宅のネットワーク回線を定期的に測定して可視化することを試みました。 ちなみに我が家は古い賃貸集合住宅で VDSL なので、上限は 100Mbps になります。それでもそこそこ快適で、特に不満もなかったのですが1、今月に入った辺りから急に回線状況の悪い時間帯に出くわすようになってしまいました。 改善策をとるまえにまずは計測、ということで、今回の試みとな
エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜 / product discovery accelerated by engineers
こんにちは、エンジニアリングマネージャーの 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
株式会社はてな（代表取締役社長：栗栖義臣／本社所在地：京都市中京区）は、当社が提供するサーバー監視サービス「Mackerel」が、アマゾン ウェブ サービス（以下「AWS」）のパートナー制度「AWS Graviton Ready」に認定されたことをお知らせします。 日本企業のサービスが「AWS Graviton Ready」の認定を受けるのは、当社の「Mackerel」と、このたび同時認定されたビジョナル株式会社の脆弱性管理クラウド「yamory」の2社が初めての事例となります。 ▽「AWS Graviton Ready」について https://aws.amazon.com/jp/ec2/graviton/partners/ 「AWS Graviton Ready」は、AWSのプロセッサである「AWS Graviton プロセッサ（※1）」ベースのインスタンスの採用を容易にし、「AWS
発表タイトル: MackerelにおけるEC2からFargate移行の軌跡とFargateのメリットデメリットについて イベント名: そろそろマネージド、クラウドネイティブで行こう! コンテナサービスへの移行祭り https://pages.awscloud.com/JAPAN-event-OE-20210617-Cloud-native-reg-event.html
この記事ははてなエンジニア Advent Calendar 2023の 12月36日 2024年1月5日の記事です。 developer.hatenastaff.com Mackerel をファイルシステムにしてみましょう。 Mackerel でファイルシステムを監視するのではありません。 Mackerel をファイルシステムにするのです。 じゃん mackerelfs と言います。よろしくおねがいします。 github.com /home/rmatsuoka/mackerel ディレクトリに mackerelfs をマウントしましょう（マウントの方法は後半説明します。）最初は ctl ファイルだけがあります。 $ ls -l total 0 --w--w--w- 1 rmatsuoka rmatsuoka 0 Jul 14 2042 ctl さて Mackerel を操作するときは AP
いつもMackerelをご利用くださりありがとうございます。 おかげさまで、Mackerelは2024年9月17日で10周年を迎えました。 日本製サーバー監視サービス Mackerel の誕生は遡ること11年前の2013年、はてな社内で行われた事業プランコンテストがきっかけでした。*1 2014年9月17日の正式リリースからたくさんの方々にご利用いただいてきたMackerelそして監視・運用の技術を取り巻く潮流は変化し続けており、Mackerelもいま、これまでの「サーバー監視・管理」の領域から「オブザーバビリティ」領域の開発へと、さらなる進化の転換期になっています。 今回は、激しく変わっていく世の中でもMackerel が変わらず大切にしている「エンジニアを”ワクワク”させること」を支え、Mackerel のプロダクト開発をリードしてきた歴代のプロダクトマネージャーから、10周年を迎えた
株式会社はてな（代表取締役社長：栗栖義臣／本社所在地：京都市中京区）は、本日2024年6月14日開催の取締役会決議のもと、株式会社Vaxila Labs（代表取締役社長：杉中宏亮／本社所在地：東京都新宿区）が運営する「Vaxila（ヴァキシラ）」の事業譲渡契約を締結したことをお知らせします。 １．事業譲受の理由 当社は、『「知る」「つながる」「表現する」で新しい体験を提供し、人の生活を豊かにする』という理念のもとUGCサービス事業を展開しており、長年培ってきたサーバーの運用実績やノウハウをもとに提供している「Mackerel（マカレル）」は、その先進性を評価する多くの大手企業をはじめ、様々な企業で採用されています。 本年4月に発表した通り、当社はMackerelを従来型の「リソース監視」のためのサービスから、複雑化するシステムに対応できる「オブザーバビリティ」向上に貢献するサービスに進化さ
システムプラットフォームチームで SRE をしている id:masayoshi です。 今年もISUCON14の開催が決定しましたね！ isucon.net ISUCONとはLINEヤフー株式会社が運営窓口となって開催している、お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです ISUCONは、世の中に実際にありそうなWebサービスを題材に、明確なボトルネックがあるコードかつ全体のコード量もすぐ読める量なので、パフォーマンスチューニングの練習にはもってこいです。 適切なパフォーマンスチューニングをするためには、まず計測してシステム上のどこにボトルネックが存在してパフォーマンスが悪化しているのかを把握する必要があります。 このように、どこで、何が起こり、パフォーマンス上の問題やエラーがおこっているのかを把握できる能力を Observabili
はてなには、開発合宿というイベントがあります。有志で集ったメンバーが普段の開発から離れ、テーマを決めて集中して取り組むイベントです。 今回、私（id:dekokun）、id:Krouton、id:ne-sachirouの3人からなるチームで、はてなが提供するサーバー管理・監視サービスMackerelに必須であるmackerel-agentというプログラムを題材に、Rustでの再実装を試みました。 mackerel-agentは、監視対象のホストにインストールし、ホストの情報（メトリックやメタデータ）を集めてMackerelに送るプログラムで、Go言語で実装されています。なお、今回はあくまでRustの知見を得る材料として選択したもので、今後の実装を置き換えようとしているわけではありません。 Rustでmackerel-agentを再実装する狙い なぜRustなのか なぜmackerel-ag
この記事はBASE Advent Calendar 2020の5日目の記事です。 SRE Groupのngswです。 Eコマースプラットフォーム「BASE」における障害発生時に、社内関係者に連絡網に基づいて電話発信するシステムを構築しました。 このエントリでは、その導入までの経緯と具体的な当該システムの説明をします。 TL;DR 「BASE」で問題が発生した際に意思決定者に電話発信する周知システムを構築した 「導入前に考えたこと」をまず主題として書いた 参考URL記事のまま手順であるが、それでも導入時に詰まった事柄など落ち穂拾い的に追記した 謝辞 Twilio FunctionsとStudioを使って連続架電を行う - Qiita 大変わかりやすい記事であり、ほぼすべてを参考にさせていただいた。このQiita記事がなければ短期間で実現することは不可能であったと考える 導入に至る経緯 07月
MackerelチームCREの吉田(id:syou6162)です。今日はリモートワークで便利なMackerelの機能を紹介しようと思います。 今見ているグラフをSlackに投稿 & チームメンバーに共有する 物理的に同じ部屋で開発 / 運用をしている場合、大きな画面にMackerelのダッシュボードを映しているという方も多いのではないでしょうか(WILLER様の事例)。同じ画面を見ながらグラフを見ると議論が捗る一方、リモートワークでGoogle MeetやZoomを使うなどやり方を変える必要がありますし、メンバーの自宅の回線状況によっては、画面そのものを共有をするのも帯域的に難しい場合もあるかと思います。 そういったときに是非利用して欲しいのがグラフの共有機能です。一番お手軽なのは「グラフを通知チャンネルに投稿する」機能です。グラフの画面にあるカメラのボタンをポチっと押すだけで、グラフを簡
こんにちは、Mackerel チーム SRE の id:heleeen です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の4月号で、先月分は id:taxintt さんのサービスの一般公開前からSLI/SLOと向き合うです。 今回は、先日 Mackerel チームで行った障害対応演習で実施した内容と、どのような学びを得たかについて紹介します。 本番障害はできればなくしたいものですが、すべての障害を完全になくし可用性を100%にするのはとても困難です。そのため、障害が発生したときの影響範囲を小さくする仕組みを導入したり、ロールバックを素早く行えるようにしておくなど、影響を抑えるための取り組みが必要になります。 Mackerel では、その一環として、障害対応時のオペレーションの確認やバックアップからの復旧が行えるかの検証などの起きてしまった障害を素早く収束させたり、
こんにちは！Mackerelチーム CRE の井上（id:a-know）です。 先日はMackerel初のオンラインセミナーの開催をお知らせしましたが、 mackerelio.connpass.com それと似た新しい取り組みとして、「あなたの会社のオンライン社内勉強会に、Mackerel CRE がお邪魔します！」というものを開始します！無償です！ この取り組みについて、以下にその内容をご紹介します。 そもそも "CRE" って、どんな人？ CREとは Customer Reliability Engineer の略称で、はてな のCREは「お客様に寄り添い、お客様が抱える真の課題にフォーカスし、その課題を技術を軸としてお客様と共に解決を図る」ことをミッションに掲げ、日頃の活動をおこなっています。 はてなの CRE チームは、私も含め、エンジニアリングのバックグラウンドを持つメンバーで構
この記事は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
こんにちは！Mackerel CREチームでカスタマーサクセスマネージャー（CSM）をやっているid:chizniiです。 Mackerel は2024年9月17日で正式リリースから10周年を迎えます。今後はオブザーバビリティ分野にも力を入れ、始めやすくて奥深いオブザーバビリティプラットフォームとして進化していきます。これからのMackerelがどのように変わっていくのか、何を目指していくのかについてぜひお伝えしたいと考え、2024年10月22日（火）に、オブザーバビリティをテーマとした技術イベントを開催する運びとなりました。 mackerelio.connpass.com イベントの開催を記念して、今回は新しくMackerelで利用できるようになった、分散トレーシングサービス Vaxila(ヴァキシラ)について、開発を行っている Mackerel チームエンジニアの id:mrasu、i
はてなで働くエンジニアにアンケートシリーズ第25回は、MackerelチームのCRE、id:kmutoに話を聞きました。 「一番の下手くそでいよう」という本の一節から異なる環境へ CREチームの「Engineer」成分が強化されてきている カスタマーサクセスとしてお客さまとの商談に臨み、技術的な挑戦をする 「学び、考え、育つ」ことが常に期待される環境 「一番の下手くそでいよう」という本の一節から異なる環境へ ── Q1. はてなidとその由来を教えてください はてなidは kmuto です。 大学の研究室配属時のUNIX（SunOS）アカウント発行ルールが「名1文字＋姓」だったため、「Kenshi Muto」→「kmuto」となりました。以来、どこでもこの文字列を使っています。 はてなidとして取得したのは比較的最近のことなので、他の人が使っていなかったのは幸運でした。呼ばれるときには、k
こんにちは、ブログチームでエンジニアをしている id:Furutsuki です。ブログチームでは長らくEC2上でMySQLを運用していましたが、種々の理由により2021年末から2022年中盤にかけて、このデータベースをAmazon RDSに移行しました。 移行にあたって、新旧のデータベースやサービスの様子を一覧できる“RDS化ダッシュボード”をMackerelで作成しました。チームでは日常的な監視にダッシュボードを活用していますが、個人的にダッシュボードを一から作ったのは初めてだったので、このダッシュボードの配置や狙いについて書いてみようと思います。 RDS化ダッシュボードの全体像 サービスの状態を確認するコーナーの詳細 DBの様子の変遷を確認するコーナーの詳細 皆さんのダッシュボードを教えてください！ RDS化ダッシュボードの全体像 まずはダッシュボード全体をご覧ください。 こうして画像
とあるAPIに対するアクセスが、 回数 時間 1833 time:27/Oct/2020:21:32:25 1657 time:27/Oct/2020:21:32:26 1616 time:27/Oct/2020:21:32:27 2584 time:27/Oct/2020:21:32:28 14958 time:27/Oct/2020:21:32:29 6619 time:27/Oct/2020:21:32:30 1725 time:27/Oct/2020:21:32:31 1796 time:27/Oct/2020:21:32:32 1713 time:27/Oct/2020:21:32:33 1932 time:27/Oct/2020:21:32:34 1797 time:27/Oct/2020:21:32:35 1841 time:27/Oct/2020:21:32:36 という感
いつもMackerelをご利用いただきありがとうございます。Mackerelプロデューサーのid:wtatsuruです。 この記事では、今後Mackerelが開発するアプリケーションパフォーマンスモニタリングの開発予定と使い方について紹介いたします。 アプリケーションパフォーマンスモニタリングの開発と今後の予定 Mackerel APMに込めた思い Mackerelのトレーシング機能の利用方法 使ってみた感想やフィードバックをお聞かせください！ 2/13（木）わかった気になる分散トレーシング - OpenTelemetryでトレーシングに入門するハンズオン！ アプリケーションパフォーマンスモニタリングの開発と今後の予定 Mackerelは、2025年前半にアプリケーションパフォーマンスモニタリング（APM）の機能をリリースします。APM機能は、アプリケーションの挙動に注目して性能やエラーの
こんにちは。MackerelチームCREの id:tukaelu です。 Mackerelでは、テクニカルサポート／カスタマーサポートをCRE（Customer Reliability Engineer）が担当しており、ユーザーからのさまざまな問い合わせに対応しています。 本記事では、Mackerelのようなエンジニア向けのSaaSにおいて、サポート業務の改善をどのように進めたか、その裏側をご紹介します。 サポート業務が抱えていた4つの課題 Zendeskへの移行と体制の変更 新しいサービスレベルの指標も計測 テクニカルサポート業務の専任 エフォートレスなサポート体験を提供する ユーザーの困りごとをFAQに落とし込んでいく 適切なタイミングでFAQをサジェストする セルフサービス化を評価する指標を設計する 最後に サポート業務が抱えていた4つの課題 私は2019年5月に入社し、同月からサポ
クラスメソッドが提供するAWS監視サービス（監視オプション）。2018年にリニューアルした際に、その基盤としてはてな社のMackerelを新たに採用しました。なぜこれまで使っていたOSS実装から離れてSaaSに乗り換えたのか？ なぜMackerelだったのか？ 当時を知る担当者が赤裸々にお話します。 …
この度、お仕事として公式エバンジェリストをすることになりました。 セミナー講師をやったり、Mackerelの便利な使い方をアウトプットしたりするのが役割です。 MackerelチームにはCREってロールがあるわけですが、その中でも顧客活動のサポートにあたります。 ついにMackerelプラグイン解説シリーズの続編とか出るかもしれません*1。 初回活動 プライベートセミナーをやります。 詳細は下記のページを御覧ください。 日時：2022年2月10日（木） 14:00〜15:00 会場：Zoom Webinar 参加費用：無料 お申し込み：イベントページからお申し込みください はじめてのMackerelクラウド監視入門編（2022年2月10日開催オンラインセミナー） connpassもあるけど、申込みは上記のサイトです。 mackerelio.connpass.com はてなはCREを募集して
カヤックSREの池田です。今回は、カヤックのプロダクトの一つ『Tonamel』で導入したエラーバジェット算出ツール shimesabaの話をします。 shimesabaとは？ github.com shimesabaは監視サービスであるMackerelを用いて、エラーバジェットを計算しサービスメトリックとして投稿することでSLI/SLOの運用を助けるツールです。 このツールを用いることで、以下のようなグラフが得られます。 この図の上部は、エラーバジェットの使用率=信頼性の損失率の推移を表すグラフになっています。 この図の下部は、エラーバジェットをいつ？どのくらい？損失したのかを表すグラフになっています。 一言で、エラーバジェットと言ってもいくつかの計算方法が存在します。 今のところshimesabaでは、Rolling windowのコンプライアンス期間で、Windows-based SL
こんにちは。 Mackerel SRE チームの id:heleeen です 先日、Terraform Registry に Mackerel 用の Terraform Provider を公開しました。 これによって Terraform で監視設定など各種設定を管理することができます。 mackerelio-labs/mackerel | Terraform Registry Terraform Provider Mackerel 公開にあたって Mackerel の Terraform Provider はこれまで公式に公開していなかったのですが、以前から作成、公開されていた @xcezx さん、 @kjm さんにご協力いただき公開することができました。 公開にあたりご対応いただきました @xcezx さん、 @kjm さんにはこの場で改めて感謝を申し上げます。 mackereilo-
現在パブリックベータとして提供しているOpenTelemetry対応を2024年11月1日に正式リリースいたします。また、機能に合わせた価格体系の見直し（価格引き上げも含む）を行います。 OpenTelemetry対応と今後のMackerelの開発方針について クラウドネイティブな開発を進めていくと、システム内で何が起きるのかあらかじめ予測して監視・対応しておく、ということが困難になってきます。こういった環境ではシステム内部の状態を把握できるように多角的に観測可能にしておく、可観測性を上げておくことが重要となります。このような環境に対応していくため、Mackerelはメトリックを多次元的に扱うことができる「OpenTelemetry対応」を2024年11月1日に正式リリースします。 OpenTelemetry対応機能は、以下の特徴を持っています。 メタデータを付与した多次元的なメトリックの
こんにちは。Mackerel開発チームエンジニアのid:arthur-1です。Mackerel Meetup #14 Tokyoの案内はご覧いただけましたでしょうか。 mackerel.io 4年ぶりとなる開催に向けて、本ブログでは「Mackerel Meetup復活記念連載」と題し、当日のMeetupをさらにお楽しみいただけるようなトピックをみなさまに共有いたします。 これまでもCREより定期的にMackerelの新機能などをご紹介しておりますが、本連載ではMackerelに携わる様々な職種のメンバーから、Mackerelの実践的活用方法、技術インサイド情報、そしてMackerelへの熱い思いをお届けします。 今回のMeetupでは、Mackerelチーフエンジニアのid:onkより「次世代Mackerelのアーキテクチャ」と題した発表を行います。すでに多くの方に興味を持っていただけてい
このエントリはMackerel Advent Calendar 2021の3日目の記事です。 最初にお断りしておくと、この話は4年以上前の昔話であり、私は既にMackerelチーム、はてな社から離れています。なので、ここで書くミッション・ビジョン・バリュー(MVV)はあくまで当時のものであり、今は別の形になっているでしょう。ですので、ここで書く話はただの昔話です。現在のMackerelに変に影響を与えたくはないと思っていることを予め書いておきます。 以前MVVの話を友人とした時に興味深く聞いてもらい、ユニークだとも言ってもらえたことがあったので、それらを決める過程の話や、浸透させようとした方法を書いてみるのも誰かの参考になるかもしれないと思い、これを書いています。 プロダクトマネージャー就任とMVV 私はMackerelのプロダクトマネージャーになった最初の頃に、MVVの策定に取り組みまし
はてなには、開発合宿というイベントがあります。 有志で集ったメンバーが普段の開発から離れ、テーマを決めて集中して取り組むイベントです。 2022年6月にも、私（id:dekokun）id:hayajo_77 id:masayosu id:yajimasanの4人からなるチームで開発合宿を行いました。 今回は、はてなが提供するサーバー管理・監視サービスMackerelによるコンテナ監視で必須になるmackerel-container-agentというプログラムを題材に、Kubernetesのadmission webhookを作ってみました。 mackerel-container-agentでadmission webhookを作る狙い 合宿の準備: Kubebuilderをもくもくと自習 1日目午前: Pod作成時にwebhookが動く 1日目午後: mackerel-container-
この記事では、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)を満たしているかどうかを定期的に確認することで、サービスレベルを適切に改善す
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く