1.1　Grafanaとの出会いと活用

　”ログがつづら折りになって、いよいよ原因に近づいたと思う頃、大量のアラームが監視の画面を赤く染めながら、すさまじい早さで私を追ってきた。”

1.1.1　はじめに

　Grafanaは一言で言うなら、”最高の可視化フロントエンドツール”です。

　近年、オブザーバビリティ(可観測性)という言葉がサーバー運用の概念として取り入れられています。私はオブザーバビリティを向上させていく上で、Grafanaは非常に強力なツールだと考えています。

　オブザーバビリティは、システムの状態をデータで見える化することですが、Grafanaは様々なシステムが持っているデータをグラフなどで可視化し、集約します。その機能は、オブザーバビリティを向上させる上で非常に有効です。

　私の部署の運用チームでは、オブザーバビリティという概念が出てくる前から、パフォーマンスやログの可視化に取り組んできました。ログを可視化することで、システムが処理しているサービスの状態を把握することに取り組み、ログ調査に伴う手作業の苦痛と属人化の予防、システムの見える化を推進することができると考えたからです。

　その試みを大きく推進するきっかけになったのがGrafanaです。Grafanaが導入されることで、運用現場では、ログを確認するオペレーション、システムの正常性確認のオペレーションが大きく変わりました。

　※私の部署では、ログやシステムの見える化を昔から”可視化”と呼んでいて、今も”オブザーバビリティ”という言葉は馴染んでいません。この文章中でも、私の部署が取り組んだ試みは”オブザーバビリティ”という言葉ではなく、”可視化”という言葉で表現していきたいと思います。

　この章では、私がお伝えできる最も具体的な実例として、私の部署のシステム運用がどう変わっていったかをお伝えしたいと思います。

　※Grafanaの一般的な説明はWikipediaに譲ります！

1.1.2　Zabbixのカスタムグラフとスクリーンが辛い…

　私がGrafanaを使い始めたのは、たしか5年ほど前、バージョン3の頃でした。当時はまだ、オブザーバビリティという言葉はまだ流行っておらず、ELKスタックによるログ分析が流行り始めた頃でした。

　その頃、ELKスタックと比較されるものとして名前を聞いたのが、Grafanaでした。OSSでフリーで使用できるソフト、データソースを時系列のグラフとして描画するソフト程度の情報でした。そして、それをどう有効利用するのかの情報はあまりなかったように思います。

　当時は、監視ソフトのPrometheus（Grafanaの事例でよく使われます）もまだ出ておらず、ELKスタックにはKibanaが専門の分析ソフトとしてあり、Grafanaはどう使うかというところから調べ始めました。

　そうして調べていく中で、プラグインによってデータソースにZabbixが取れる情報を見つけ、OSの性能メトリクス（CPU利用率やメモリー使用率）のグラフ化を効率化できそうだと導入を始めました。

　当時、Zabbixのバージョン2系を使用しており、複数サーバーの性能メトリクスをカスタムグラフとスクリーン機能でまとめるのが非常に苦痛でした。表示したいデータを選択して、ホストを選択してというポチポチを繰り返す必要がありました。多数のホストや、複数の性能メトリクスをまとめようとすると、延々とポチポチ操作の苦行をすることになります。そんなところに、Grafanaが現れました。

　※Zabbix2.2の公式¹から画像を持ってきました。

　こんな感じの画面でホスト選んでアイテム選んでのポチポチを繰り返すのは、腕が痛くなるし無理だなーと諦めました。

　楽な手段はないかといろいろ探していたところ、GrafanaとZabbixの連携を紹介したサイトで、Zabbixのホストやアイテムの指定を正規表現で行っている画像を見つけました。ポチポチしないでも、正規表現でメトリクスを指定し、グラフ化する。

　これは、Zabbixのスクリーン機能でグラフをまとめるのが、バカバカしくなるほど快適でした。

　データソースにZabbixをとり、管理しているサーバーのOSの性能メトリクスをすべてGrafanaでグラフにしました。

　ただ、これだけでは、性能メトリクスのグラフが大量にできただけでした。

　※GrafanaVer8の画像ですが、以下の特徴が出ています。

　・GroupとHostが正規表現で設定できる

　・item欄は選択できる項目がプルダウン表示

1.1.3　ログの可視化を行う！

　次に取り組んだのが、ログの件数のグラフ化でした。私の部署のシステム運用では、グラフ化を可視化と呼んでいました。アプリケーションのログの件数をグラフにし、可視化する。今から見れば重要な機能なのですが、当時は今ほど重要視されていませんでした。

　その理由は、当時使用していた社内ツールの使いづらさにありました。当時、使用していたのはRRDツール²を中心にしたもので、以下のような手間のかかるものでした。

　１．サーバー側でRRDツールで取得できる様式のファイルをシェルスクリプトで生成

　２．RRDツールで取り込み

　３．RRDツールのグラフを運用部門のWEBページにURL貼り付け

　こんな感じのグラフができるのですが、数値の縦軸も横軸もわかりづらい、各ホストをまとめるグラフも作りづらい、多数のデータを一気に読み込ませて欠損が発生したりと、運用ツールの主役になれない課題が複数ありました。

　これをZabbix+Grafanaに置き換えました。RRDツール向けのファイルを、ZabbixSenderコマンドで読み込める様式に変更し、Zabbixに取り込みました。

　毎分cronでスクリプトを動かし、ZabbixSenderコマンドでログ件数を格納するようにしてあるだけです。もちろん、まったくの労力ゼロでできたわけではありませんが、まあ、たいした手間ではありませんでした。

　※次章で紹介しますが、ZabbixSenderコマンドはかなり便利です。

　Zabbixに取り込んだことで、Grafanaでグラフとして可視化できるようになりました。Grafanaによって、見た目とグラフの作成しやすさが向上したことで、ログの可視化を確認することが、運用チーム内で徐々に普及し始めました。

　※当時の画像が残っていないので、GrafanaVer8での画像です。

1.1.4　ログの可視化が変えたもの

　当時、最も重要視されていたサービスの状態確認の手段は、端末試験やシミュレーターによる擬似リクエストでした。ログは可視化してあるものは参考にするが、基本はログインしてコマンドで集計するものという扱いでした。

　ただ、この運用には課題がありました。

　端末試験やシミュレーターが失敗しても、それが端末やシミュレーターの問題かどうかわからないことがあったのです。

　また、端末試験やシミュレーターは、あくまで１リクエストの試験でしかないので、どのくらいのユーザーやリクエストに問題が起きているのかもわかりませんでした。

　ユーザーやリクエストの影響規模や、リクエスト全体が正常な傾向にあることは、サーバーにログインして、ログを集計して確認していました。

　これは非常に時間がかかるオペレーションでした。手作業だったり、シェルスクリプトで頑張っていました。

　また、時間がかかるのももちろんですが、オペレーションがログの内容に通じた有識者に属人化する課題もありました。

　影響規模、復旧判断に求められる時間的要求を満たすことは難しい状況でした。

　そこで、さきほど述べたように、ログの可視化にGrafanaを利用しました。Zabbixにアプリケーションの成功ログの件数を格納し、それをGrafanaで可視化しました。

　アプリケーションのログを可視化すると、どんな変化が起きるのでしょうか？

　端末試験やシミュレーターよりも、ログの可視化をまず確認するようになりました。可視化された成功ログのグラフを見れば、サービスへの影響がどの程度あるのかが一目瞭然だったからです。

　※当時の画像が残っていないので、GrafanaVer8での画像です。

　02:00に急にトラフィックが急落していることがわかります。

　システム運用にとって、サービス影響が”ある”こと、”ない”ことを明確に確認できるのは、とても大きなことでした。さきほど述べたように、端末試験やシミュレーターは1回のリクエストに過ぎず、信用度に欠けます。手動でのログ集計はオペレーションのためのナレッジが属人化しやすく、また、コマンドミスもありえます。

　私は、夜中にオンコールを受けたときに不安でした。端末試験やシミュレーターの結果で判断したとき、自分の判断の根拠が脆弱で不安でした。そういった不安が、ログを可視化することで大きく軽減されました。

　可視化されたログを見れば一発ですし、可視化された結果は、自分以外の有識者も同じ判断をするに違いないという安心感がありました。

　現在、障害が起きるたびに、私はGrafanaで可視化したログを最初に確認しています。もちろん、端末試験もシミュレーターもログ調査も今でも行いますが、それらはあくまで補足的な詳細調査で、障害時の初動はGrafanaの確認です。

　Grafanaでアプリケーションログを可視化することで、サービス・システムの状態がデータとして明示され、それを根拠に判断できるようになります。これを運用チームの仕組みとしてできるようになったとき、私はチームとして運用する実感と、それによる安心を得ることができました。

　“Dashboard anything. Observe everything. Query, visualize, alert on, and understand your data no matter where it’s stored. With Grafana you can create, explore and share all of your data through beautiful, flexible dashboards.”

　“すべてをダッシュボードに、すべてを観測できるものに”

　Grafanaを開発している”Grafana Labs”の説明です。

　ログは数値化し可視化することで、初めてデータとして活用できます。ここ数年、オブザーバビリティという概念が運用チームで重要になってきています。データを元にした判断が、オブザーバビリティの目的のひとつです。

　私はGrafanaを”最高の可視化フロントエンドツール”だと考えています。ELKスタックやDatadogや、各クラウドの監視サービスもありますが、システム運用の現場でオブザーバビリティを実現するツールとしては、GrafanaがNo1のツールだと考えています。

　私の運用チームは、Grafanaでオブザーバビリティに取り組むことができるようになり、運用が変わりました。

　私の章では、これからGrafanaでオブザーバビリティを推進していく上での特徴やメリットをお伝えしていきたいと思います。

1.2　優秀な点その一：豊富なデータソースと統合表示

　“リリースまえの機能のリリースノードに眼ざめながら、熱い「期待」の感覚をもとめて、辛い夢の気分の残っている意識を手さぐりする。”

1.2.1　バックエンドの製品の選択肢が多いというメリット

　Grafanaは標準機能として以下のバックエンドを公式サポート³しています。

　AWS、Azure、GCPの監視サービス、Elasticsearch、Prometheusといったツールとしてメジャーどころが押さえられており、GraphiteやInfluxDB、MySQLやPsotgreSQLも入っています。

　これだけでもかなり守備範囲が広いといえるでしょう。

　Grafanaにはさらに、コミュニティーで提供されているプラグイン⁴があります。さきほどご紹介した事例のZabbixは、コミュニティーのプラグインです。

　※Zabbixを公式サポートしてくれればいいのに！と思います。

　Grafanaが出しているプラグインやエンタープライズ版のみのプラグインにも、多数の製品があります。Cassandra、Bigquery、Datadog、OracleDB、Splunkといった製品のプラグインもあります。

　今後も新しい製品が出てくる度に追随して、増えていくことでしょう。

　※DatadogやSplunkなどは面白そうだと思っていますが、エンタープライズ版で有料なのがなかなか手を出しにくいですね

1.2.2　複数のデータソースを組み合わせると…

　Grafanaは複数のデータソースをひとつのパネル、ひとつのダッシュボードにまとめることができます。

　これらは実運用の場では、以下のメリットをもたらします。

　・同じシステムに使用している複数のデータソースを同じダッシュボードにまとめる

　　─例：ログ検索にElasticsearch、監視にZabbixを使用

　・（別のツールを使用している）関わりにある複数のシステムの情報をまとめる

　　─例：システムAはZabbixを使用、関連システムBはPromethuesを使用

　ひとつのシステムの中で、ログはElasticsearchに保存し、ZabbixでCPU使用率を取得しているシステムもあれば、あるシステムはAWS上のCloudwatchに統計情報を保存していたりもするでしょう。システム運用の現場では、構築された時期や設計思想で様々なデータソースがあります。

　そういった差分を、Grafanaはフロントエンドとして吸収してひとつのパネル、ダッシュボードにすることができます。

　“バラバラなシステム環境のデータをフロントエンドでひとつに統合できること“は、システム運用の現場では非常に大きなメリットです。

　多くの監視ツールは、そのツールで取得したものしかビジュアライズできません。つまり、システム環境を統一しないと大きな効果を出せません。標準化を徹底し、統一することに苦難を伴っていないシステム環境であれば、問題もなく、よいでしょう。

　しかし、監視ツールがバラバラなシステムを取り扱うのであれば、Grafanaの複数の製品をバックエンドに取れるという特徴は、複数のシステムの差分を受け入れて、ダッシュボードにまとめます。バックエンドは、Grafanaに対応している製品でありさえすればよいのです。

　バラバラなツールのデータを無理にまとめる必要がなく、今のままのシステム構成でダッシュボードをまとめるという、非常に融通の利く運用ができるのです。これがGrafanaの優秀な点のその一です。

1.3　優秀な点その二：データ基盤がなくても始められる

　“ある夜間作業明けの朝、必死で目を覚ましてログの集計をした時、これはもうぐずぐずしてはいられない、と思ってしまったのだ。”

1.3.1　Grafanaは自分自身でデータを持たない

　Grafanaは前章で述べたように、豊富なデータソースをバックエンドに取ることができます。また、パネル毎に別のデータソースにすることもできますし、同じパネルの中で複数のデータソースを使うこともできます（値の複合はできませんが）。

　Grafanaは、データを持っていません。バックエンドのデータをWEB画面上で描画するのみです。ビジュアライズ機能を備えたプロキシです。

　自分自身はデータを持たず、複数のデータソースを参照するだけのプロキシ。これは、Grafanaを始める上で、特別にスペックの高いシステム環境が不要なことを意味します。自分自身ではデータを持たないので、巨大なディスク容量を持たなくていいですし、あくまでプロキシなので、Grafana自身の要求性能は高くありません。

　並みのスペックのサーバーに、とりあえずインストール⁵してみたレベルの取り組みから始めることができます。

1.3.2　大規模データ基盤がなくてもいい

　データソースについて、各システムに分散したものを、Grafana上でまとめて参照することができるので、データソースに統合されたデータ基盤がなくても始めることができます。巨大な容量のストレージを準備し、そこにログを流し込む設計をするといった、大きな計画を立てる必要がないのです。

　とりあえずのありものの構成で、Grafanaのデータソースとして連携可能なサーバーがあればOKです。Grafanaをインストールし、データソースに連携してみる。それを時系列グラフで可視化してみるというところから始められるのです。そして、ありのもののデータに対する、時系列グラフでも十分に便利で、価値を実感できます。

　データ基盤のような大規模設備がなくても、可視化の取り組みを始めることができる。これが、Grafanaの優秀な点のその二です。

1.4　優秀な点その三：オンデマンドなグラフ作成

　“ぼくは時々、世界中の携帯電話という携帯電話は、みんな検証テストをするエンジニアたちの机の上かなんかにのってるんじゃないかと思うことがある。”

1.4.1　思いついたときに簡単グラフ作成

　Grafanaは、データを可視化したパネルをひとつのダッシュボードにまとめます。この作成が非常に簡単なことも、特徴のひとつです。

　ダッシュボードを作成し、そこにデータを表示するパネルを配置していくだけです。パネルは大きさや位置を、ドラッグ＆ドロップで自由に変更できます。また、パネルを区切る「列」でパネルを整理することもできます。

　作成したパネルは編集画面で、データソースを選択するだけで表示されます。表示や数値の処理で様々なオプションがあり、見やすくしたりするためのカスタマイズができます。気になるデータがあったら、その場でパネルを追加して、可視化してみましょう。ダッシュボードもパネルもコピー可能で、試行錯誤しながら作成できます。

　実際に使ってもらうとわかると思いますが、グラフの作成しやすさ、こだわりを追加するためのオプション、いずれの面でも非常に優れています。前提は、データを持っているバックエンドがデータソースとして登録されていることだけです。

　このダッシュボード作成の簡単さが、チームに可視化への取り組みを拡大します。学習コストが低く、敷居がとても低いのです。新人や後発のメンバーでも簡単に取り組めるというのは、チームで取り組む上で大きなメリットになります。その点で、Grafanaはチームにとても展開しやすいツールです。

　また、簡単に作成できるということは、作成にかかる所要時間が短いということです。時間のかかる準備もなく、WEB画面上で思いついたときにオンデマンドで設定できるのです。思いついたときに、すぐに設定することができる。これがGrafanaの優秀な点のその三です。