Mackerelを用いた、メトリック化したログに対する監視のご提案 - えいのうにっき
この記事は Mackerel アドベントカレンダー 2019 の25日目の記事です。僭越ながらトリを務めさせていただきます、株式会社はてな の Mackerelチーム・CRE（Customer Reliability Engineer）である a-know です。よろしくお願いします。メリークリスマス。 tl;dr 特定条件に合致するログ出力がどれくらいあったか、という情報を行数としてメトリック化し Mackerel に投稿するメトリックプラグインを作りました これと、以前書いた記事を組み合わせることで、従来までのログ監視 とは違ったログ監視手法を提案します メリークリスマス！ ログの出力状況をメトリック化する 今回このアドベントカレンダー記事を執筆するにあたり、以下のプラグインを書きました。 github.com これは、特定条件に合致するログ出力がどれくらいあったか、という情報を行数と
Mackerel のログ監視で検知された出力行をグラフにプロットする - えいのうにっき
本日、mackerel-agent の v0.64.0 がリリースされました。 github.com これにより、取り込まれたいくつかの Pull Request が v0.64.0 に含まれているわけですが、そのうちの Pass the check monitoring result message to "action" by env という Pull Request により、以下のスクリーンショットのようなことができるようになったので、その実現方法も含めてこの記事で紹介したいと思います。（この Pull Request も私が出したものなので、マッチポンプ感ありますが......。＆ この記事は Mackerelチームに所属する CRE でもある人間がお届けしています。） 検出したログ出力行をグラフにプロットしている様子です 前提・下準備 前提として、mackerel-agent が
Pixelaを支える技術 - えいのうにっき
Pixelaの技術的な話（といっても高度なことは殆どしてないんだけど......）とか、あと今回の個人的な頑張りポイントである利用規約・GDPR対応といったところは、後日別エントリとしてまとめたいな〜と思っています。そのうち書くので、よろしかったらそちらも楽しみにしてやってくださいっ。 commit以外の数値でも草を生やせる、PixelaというAPIサービスを作った！ - えいのうにっき blog.a-know.me などと書いておきつつ、3週間ほど経ってしまった。ということで、今回はこの点に関して書く。あと、過大なタイトルについてはすみません。これ以外もう何も思いつかなかった。 思い当たる限りで、ざっと箇条書きにしていく。この記事に限らないことだけど、なにか間違ってることとか、もっといいやり方あるよ、というところがあれば、ぜひ教えて欲しい！ サーバーサイド GCP（Google Clou
commit以外の数値でも草を生やせる、PixelaというAPIサービスを作った！ - えいのうにっき
作りました！ pixe.la これはなに？ お好きな数値を登録、その登録された数値情報に基づいて、アレのあれっぽくグラフを作れるサービスです！ アレのあれってのは、これのコレ↓っぽいやつです！ ↑commit回数をグラフにした場合のイメージ。 ↑プロダクトのデプロイ回数をグラフにした場合のイメージ。 ↑体重の変動（前日比）をグラフにした場合のイメージ。 どうやって使うの？ Pixela は、サービスのトップページ以外は全部 Web API のみで構成されるサービスです！なので、ユーザー登録からなにから、全部 API でおこないます！ $ curl -X POST https://pixe.la/v1/users -d '{"token":"thisissecret", "username":"a-know", "agreeTermsOfService":"no", "notMinor":"
インフラエンジニア・SREなどの職種関係なく同じグラフを見ると楽しい - えいのうにっき
このエントリは、サーバー監視サービス・Mackerel の中の人であり、Mackerel 大好き人間でもある私・ id:a-know がお届けしています。 Evernote や Dropbox paper など、世の中には様々なメモのためのアプリケーションがあるけれど、僕は個人用のメモをつけるための道具として、 kibela と esa の両方をユースケースに応じて使い分けている。いずれも所属ユーザーは僕一人しかいない、ひとりチームとしての利用なのだけど。 kibela https://kibe.la/ja 日々の生活におけるメモ。日記とか。 日記は2017年3月から毎日書き続けている......。。 esa https://esa.io/ プライベート開発用。 開発関連作業においての副産物として生まれるもののメモやコード片など。 僕の使い方としてはこんなかんじ。どちらも、企業内で情報共有
自分の全ツイートを GitHub Pages で参照できるようにした - えいのうにっき
こちら↓の記事の内容をそのままやった。以前試してみたときには「全ツイートデータのダウンロード」がなぜか出来なくて断念してたのだけど、今日試してみたらあっさりダウンロードできたので。 kwappa.hatenablog.com GitHub Pages として公開もした。→ a-know.github.io/tweets さらにこれを何かの仕組みで自動更新できればカッコイイんだろうけど、「全ツイートデータのダウンロード」がメールを受信する（メールにzipが添付されて送られてくる）方式しかないようなので、それはちょっとめんどくさそう。なので、思い出したときに手動で同期することにする。 モチベーションとしては、「いつだったかツイートした内容を参照したいんだけどな」ということがままあって、そういうときに探しやすいのでは？と思ったことが大きい。ただ、さすがに全ツイートとなるとブラウザ上での検索・参照
サーバーが高負荷状態になったときのプロセス一覧を自動で出力させておく - えいのうにっき
趣味でお世話をしているサーバーインスタンスのうちのひとつが、最近以下のような事象を時折起こしておりまして。 深夜に一時的に高負荷状態に陥る 朝起きてみたらそれに気づく（終息している） さすがに趣味の範疇なので、深夜に飛び起きて対応できるようなアラート通知設定はしておらず、とはいえ起きてからその理由を探ろうとするのだけど、終息したあとに見られるものといったらせいぜい以下のようなことくらい？ モニタリングツール（Mackerel）のその当時のグラフの様子 アプリケーションログを見る /var/log とかに出力されてるログを見る 今回の場合だとCPU使用率とLA（ロードアベレージ）が高騰していたことくらいしかわからずで、そのときにどういうプロセスがリソースを食ってたんだろう、みたいなことは把握することができなかった。 こんなかんじ。diskはちょっとハネてるかな...。。 対象のサーバーには
Go言語で書いた Web アプリケーションの習作をサービス化して公開するところまでやってみた - えいのうにっき
もともと数ヶ月前から、Go言語によるWebアプリケーション開発 を読みながら Go での Webアプリケーション開発の勉強をしていた。 Go言語によるWebアプリケーション開発 作者: Mat Ryer,鵜飼文敏,牧野聡出版社/メーカー: オライリージャパン発売日: 2016/01/22メディア: 大型本この商品を含むブログ (3件) を見る 「実際に動くもの」を、「手を動かして作りながら学ぶ」のが僕は好きで、今回も同様、それを楽しんでやっていたのだけど、思いの外それっぽいものができあがってしまって。これをそのままローカルで動かすだけじゃおもしろくないな、もったいないな、と思ったので、それをサービス化して公開するところまでやってみた。 かんじんのアプリケーションは↓これ。Yukizuri と書いて「ゆきずり」と読む。 https://yukizuri.moshimo.worksyukizu
「障害発生時に即座に収集したいサーバの状態・14項目」を実際に収集してみた - えいのうにっき
僕はインフラエンジニアではないし、そうだったこともないのだけど、いま「インフラエンジニアの教科書２」という本を読んでいる。 インフラエンジニアの教科書2 スキルアップに効く技術と知識 作者: 佐野裕出版社/メーカー: シーアンドアール研究所発売日: 2016/08/26メディア: Kindle版この商品を含むブログを見る Twitter かなにかでこの本の存在を知り、とりあえず買ってみたものの、しばらくの間積読状態になってしまっていた。...のだけど、最近になってようやくちまちまと読んでいる。関係ないけど、kindleで読めるのはほんとに便利だ。 この本の7章「障害対策と障害対応」で、『以下のような項目についてはサーバ障害時に即座に（20秒程度で！）収集できるべき』、とされていた。 メモリの搭載量と使用量 パーティションごとのディスクの使用率と空き容量 CPUの種類とコア数 ディスクのRA
Unixプロセスとリソースの基礎を再確認した - えいのうにっき
前置き 最近、「なるほどUnixプロセス ― Rubyで学ぶUnixの基礎」という本を読んでいる。 tatsu-zine.com 僕の所属している会社・はてなでは「メンター制度」というものがある。はてなに所属する全てのエンジニアに、誰かしら（グレード的に自分より上となるエンジニア）をメンターとしてつける、という制度。メンターとメンティーは月に一度、1on1を実施する。 自分はセールスエンジニアという特殊な職種ではあるが、メンターとしてシスプラ（インフラ）部門のエンジニアの方に付いて頂くことになった。このことは僕にとって、とても有り難く、心強い。 というのも、入社から2ヶ月ちょっと、実際にセールスエンジニアとして業務を進めてみて、インフラ周りの基礎知識・ローレイヤーに関しての基礎知識が強く求められるなぁと...、、というか、それを知っているといないとでは、問題や課題についての理解の仕方も違っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
