本エントリはMackerel Advent Calendar 2017の23日目の記事です。 自宅の無線LANの利用状況をMackerelで監視するようにしたところ、予想以上にキモい仕組みができました。たとえば、家族の誰か（正確には誰かのスマートフォン）が外出するとSlackに通知を飛ばすことができます。 同じことをしている人は多くないと思うので、その知見を紹介します。 システム概要 まずは我が家のネットワーク構成を紹介します。 インターネットに接続しているブロードバンドルータがあり、無線経由でスマートフォンやPCがぶら下がっているような、ごく普通のネットワーク構成です。唯一変わっている点は、ブロードバンドルータ上でLinuxおよびMackerelエージェントが動いていることでしょう。 このルータの詳細は本稿では省きますが*1、ザックリ言うとRaspberry Pi 3を無線LANアクセス

今日は「Redash Advent Calendar 2017」21日目の記事として，小ネタだけど，Redash で提供されているモニタリング用のメトリクスを紹介したいと思う．会社で Redash の活用が普及してくると，Redash の障害がビジネス的な影響に繋がる場合もあったりして（依存度が高すぎるのかもしれないけど），ツールとは言え，適切にモニタリングをしてあげる必要があると感じることが多い．Redash Ops も重要． qiita.com プロビジョニング 会社で運用中の Redash は AWS の AMI から起動しているけど，以下の3点だけは Chef でプロビジョニングを行っている．今回紹介するモニタリングの話に関係するのは Zabbix Agent の部分となる． /opt/redash/.env の配布 Zabbix Agent のインストールと監視スクリプトの配布（

upgradeが動かない 一度稼働を始めるとなかなかバージョンアップできなくなるので、本番稼働前に執筆時点の最新となる3.0.0b3134にバージョンアップしようとしました。 そこでupgrade以下コマンドで上げてみようとしたところ… $ sudo /opt/redash/current/bin/upgrade Starting Redash upgrade: Found version: 3.0.0 Current version: 2.0.0+b2990 * Before doing an upgrade, please make sure you have a backup. * If you have any issues, please refer to the troubleshooting section in the upgrade guide: https://reda

この記事は Redash Advent Calendar 2017 1日目の記事です。 qiita.com Query Resultsデータソースとは v3.0.0 で追加されるデータソースで、文字通り「クエリの実行結果」をデータソースとして扱うことができるものです。 有料版ではすでに存在していたものがv.3.0.0でOSSになったようで、有料版での使用例は、過去にGunosyさんの記事でも紹介されています。 data.gunosy.io この記事では、Query Resultsデータソースの利用例を環境構築からクエリ実行までの手順とあわせて紹介します。 環境構築 Redashの環境構築はDockerを利用することが推奨されているので、Dockerを使って環境構築をしますが、Query Resultsデータソースの動作を確認するため、Redash標準のセットアップ手順に加えて、MySQL、

まえがき ClowdWatchはAmazonの各サービスの負荷状況（CPU使用率、IO使用量など…）などの情報を取得して表示するサービスです。 おおむね1分間隔ごとに取得できるので、急激な変化が生じて居ない時の負荷確認や記録には便利なのですが、ある欠点が一つあります。 欠点、それは… 過去の記録を鮮明に保存できないことです 取得当時は1分間隔で保存されていた記録も、2週間経つと5分間隔でしか取得できなくなり、さらに2ヶ月経つと1時間ごと1 でしか取得できなくなります。負荷が高い状態の実績値や、万一の障害が発生した時の状況を思い出して振り返られるようにするためには、やはり1分間隔で永続化したいですね。 そこで、その保存用に今アツい（？）BigQueryを使ってみたいと思います。とりあえずBigQueryに入れておけば格安でデータの保存、クエリ等を使っての検索が出来ますし、データの送信もコマン

Mercari Advent Calendar 2017 の14日目は SRE チームの @masartz がお送りします。 前提 メルカリのSREチームでは当番体制を敷いており、平日は他のチームメンバーが出社するまで自宅待機しています。 出社したメンバーは当番にその旨を連絡します。こんな感じです。 とはいえ、時には連絡を忘れてしまう事もあります。人間だもの。 そんな時には当番が自宅に張り付きになってしまいます。 人間なので忘れることは仕方ないです。 人間が頑張らずに解決できると良いので、今回のお話です。 狙うところとしては、 出社したら勝手に当番に連絡される です。 それぞれ分解して実現方法を検討します。 「連絡される」の解決方法 これは今まで出社した人がSlackでmentionしていたのと同じようにSlackで良さそう、Slackへの自動通知はbotがよく使用されている昨今では特に難

New Relic Advent Calendar 2017 8日目。New Relic APM のエラー分析の新機能のご紹介。 みんな New Relic APM のエラー分析機能使ってる? いつも皆使っている機能なんだろうかと思ってはいる。うちとかだとエラー管理は別サービスを使っているし。(エラーが発行されたタイミングで Slack に通知してほしかったりするけど、New Relic のエラー管理ではそれはできないので） なんだけど、今回紹介する新機能の エラープロファイル (2017年9月ころリリース)は、New Relic ならではの機能となっている。何がならではかっていると、エラー以外のパフォーマンスやトランザクションデータを持っているってことを活用した機能になっているってとこ。エラー管理に特化したサービスにはそれはできないからね。 どういうものかって言うと、昨今 New Rel

New Relic Advent Calendar 2017 ５日目。 New Relic APM のアラート設定についての記事。ここ一年でユーザーのアラート設定が楽になったり、New Relic が用意している以外の項目もアラート条件に設定できるようになったので、それらを紹介します。 去年書いた「新アラートサービス: New Relic Alerts と今後予定されているアラートの新機能について」のアップグレード版。去年の記事では、その時点で利用可能であったアラートについての最新情報をお伝えした。読んでいない方は、是非、本記事の前にご覧いただければ、この記事の理解も増すかもしれない。 前回記事で、今後追加される機能として「NRQL アラート」「ベースラインアラート」「アラート条件: Web transactions percentiles の追加」と書いたので、今回はこのうちの「ベースラ