Skip to content

Commit f0e3f13

Browse files
authored
Merge pull request #1672 from future-architect/feature
「Grafana Meetup Japan #6|どうする?Grafanaする!」に登壇しました
2 parents 8dcbd82 + 5e5f02a commit f0e3f13

File tree

4 files changed

+152
-0
lines changed

4 files changed

+152
-0
lines changed
Lines changed: 152 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,152 @@
1+
---
2+
title: "「Grafana Meetup Japan #6|どうする?Grafanaする!」に登壇しました"
3+
date: 2025/09/10 00:00:00
4+
postid: a
5+
tag:
6+
- Grafana
7+
- Grafana Alloy
8+
- 登壇レポート
9+
category:
10+
- DevOps
11+
thumbnail: /images/2025/20250910a/thumbnail.png
12+
author: 伊藤太斉
13+
lede: "9/2に開催された「Grafana Meetup Japan #6|どうする?Grafanaする!」にGrafana Alloyのconfig運用というテーマでLT登壇してきたので、参加レポートも含めて記事にします。"
14+
---
15+
16+
こんにちは。TIGの伊藤です。
17+
18+
9/2に開催された「[Grafana Meetup Japan #6|どうする?Grafanaする!](https://grafana-meetup-japan.connpass.com/event/362953/)」にLTで登壇してきたので、参加レポートも含めて記事にします。当日の[YouTube](https://www.youtube.com/watch?v=IQnWiOQHoM8)もアーカイブ公開されているのでそちらと合わせて読んでいただけると幸いです。
19+
20+
<img src="/images/2025/20250910a/gfarana_meetup_6.png" alt="gfarana_meetup_6.png" width="660" height="371" loading="lazy">
21+
22+
## 自身のLT: Grafana Alloyのconfig運用
23+
24+
今回、私が登壇したネタになります。資料は以下です。
25+
26+
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/2d59638e59f04898857ce369ed20ba87" title="Grafana Meetup Japan Vol. 6" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
27+
28+
### Grafana Alloyの利用経緯
29+
30+
私が今所属しているチームでは、従来EC2で動かしていたアプリケーションをECS on Fargateで稼働するようにリアーキを実施しました。また、合わせて利用していた監視やジョブについても再選定の対象とし、コンテナとの相性、今後の展開性も含めてGrafanaを利用しました。
31+
32+
その時、コンテナから様々なメトリクスデータを収集する時に利用するツールとしてGrafanaと合わせてAlloyを選定しました。
33+
34+
### Alloyの導入の時に考えたこと
35+
36+
AlloyはHCL(HashiCorp Configuration Language)に近い記法で書くことができ、個人的には馴染みが良かったのですが、実際の環境や運用を考えてみると
37+
38+
- アプリケーション
39+
- Java
40+
- Go
41+
- ミドルウェア
42+
- 稼働環境
43+
- EC2(VM)
44+
- ECS on Fargate(コンテナ)
45+
- 環境面
46+
- 本番
47+
- ステージング
48+
- 開発
49+
50+
と様々な要因で統合は厳しいと判断しました。
51+
52+
しかし、なるべく省力化を図るために、以下の2つを検討し、実践しました。
53+
54+
### 環境変数で吸収
55+
56+
Alloyには`sys.env`という形で環境変数の値を取得できるライブラリがあります。
57+
58+
- https://grafana.com/docs/alloy/latest/reference/stdlib/sys/
59+
60+
このライブラリを以下の形で使うと、環境変数の値が取得でき、例示している (`LOKI_PUSH_URL`に向けて)ような収集したデータのプッシュ先を変えることができます。
61+
62+
```hcl
63+
loki.write "loki_destination" {
64+
endpoint {
65+
url = sys.env("LOKI_PUSH_URL")
66+
}
67+
}
68+
```
69+
70+
### 起動時にファイルを取得する方法
71+
72+
環境変数で環境面に対応することはできましたが、もう一つ、Alloyが収集する対象のアプリ、ミドルに対しての適用です。
73+
74+
様々なログのパス、メトリクスのパスなどはどうしても環境変数で吸収することは難しいので、ファイルごと分離を行い、Alloyコンテナが起動する時にファイルを取得する形式としました。
75+
76+
<img src="/images/2025/20250910a/Grafana_Meetup_Vol.6.png" alt="Grafana_Meetup_Vol.6.png" width="960" height="540" loading="lazy">
77+
78+
この2つの方法を織り込むことで、複数の環境面、複数の収集対象に適用することができました。
79+
80+
### いただいた質問
81+
82+
当日、質問を募集するslidoにていただいた質問について、当日で回答できなかったので、こちらで回答します。
83+
84+
*Q. Alloyを運用していて、パフォーマンスの問題はありましたか?Otelのcollectorだと、必要なパッケージだけ入れてビルドする、という運用ですが、Alloyはデフォルトで全部盛りと聞いていて、ナレッジあればお願いいたします*
85+
A. 全部盛りであると理解しています。私のチームでも実際にAlloyからMimir、Lokiへ転送しているため、このほかGrafanaのスタックに対しても使えます。
86+
87+
*Q. Alloyは1つのコンテナでメトリクスとログ全て送信していますか?それとも用途によってコンテナを分けていますか?*
88+
A. 今回は1つのコンテナで全てメトリクスもログも収集、送信しています。
89+
90+
*Q. Remotecfgを使っていないという認識で合っていますか?もし使わなかった理由などあればご享受頂けば幸いです。*
91+
A. [`remotecfg`](https://grafana.com/docs/alloy/latest/reference/config-blocks/remotecfg/)は知らなかったです。ドキュメントを見てみたのですが、その過程として[`remote.s3`](https://grafana.com/docs/alloy/latest/reference/components/remote/remote.s3/)というコンポーネントがあるらしく、これを使うと以下のように書けそうです(未検証のため確認が必要です)。
92+
93+
```hcl
94+
remote.s3 "external_config" {
95+
path = "s3://bucket-name/alloy/config.alloy"
96+
}
97+
```
98+
99+
他にもアクセスキーなどについても設定できそうでした。今回のユースケースであればFargateにタスクロールがついているので、そちらで賄えるのではないかと考えています。
100+
101+
## そのほかのセッション、LT
102+
103+
### Grafanaスタックをフル活用したオブザーバビリティ基盤の紹介
104+
105+
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/46fd2892cc3d48d08e8244c86c4799cb" title="Grafanaスタックをフル活用したオブザーバビリティ基盤の紹介" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
106+
107+
今回のメインセッションであるGO株式会社のQuentinさんによるセッションでした。
108+
109+
GOでは100を超えるマイクロサービスをAWS、およびGoogle Cloud上のKubernetes基盤で稼働させており、これを「Kenos」と呼称しているそうです。
110+
111+
この大きなクラスターを稼働させる上でオブザーバビリティがより重要になってきていましたが、SaaS監視ツールの料金高騰や問い合わせ対応時にツールが分散している煩雑さから、Grafanaのスタックを徐々に自前で導入しています。
112+
113+
規模感は日々ログがTBオーダー、メトリクスやトレースでもGBオーダーと、私も自前で構築をしているものの桁が違いすぎて非常に驚いたこともありますし、さらにその規模を安定して運用されているところが興味深かったです。個人的に改めて納得したポイントではありますが、同じツールでも自前で運用するか、SaaSで展開するかは扱っているデータサイズにも依存していると思いました。ただ、Grafana Cloudもあるので、ある程度運用負荷が高いなどがあれば切り替えることができるのもGrafanaの良さだと感じました。
114+
115+
また、Grafanaの自前運用での振り返りとして話されていたのは、初期の設定の躓きであったり、運用の安定性などについて自身でも気をつけたいところでした。例えば、Grafanaでの障害切り分けをする際に、Grafana自体が過負荷になりサービスダウンしてしまうといったことがあったようで、ここはGrafana自体のチューニングであったり、Loki, Mimirまで含めて設定を洗っておこうと思います。
116+
117+
そのほかの話については以下のブログにも公開されており、見返してみると私もだいぶお世話になったブログでした。
118+
119+
- [LGTM!オブザーバビリティ基盤第1話](https://techblog.goinc.jp/entry/2023/09/12/090000)
120+
- [Grafana Lokiでログを検索 | オブザーバビリティ基盤第2話](https://techblog.goinc.jp/entry/2023/11/17/090000)
121+
- [Grafana LokiのLogQLを理解する](https://techblog.goinc.jp/entry/2024/12/05/183855)
122+
123+
### Grafanaをリバプロ配下で動かすときにやること ~ Grafana Liveってなんだ ~
124+
125+
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/bc80afab6a944b4c9f52e43b0d0633ff" title="【Grafana Meetup Japan #6】Grafanaをリバプロ配下で動かすときにやること ~ Grafana Liveってなんだ ~" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
126+
127+
Grafanaがサクサク、ヌルヌル動く秘密の部分を解説してくれるセッションでした。Grafanaにはストリーミングの機能があり、ここではWebSocketを使っていますが、これをNginxなどのリバースプロキシ経由でどう使うか、使えるようにするか解説されました。
128+
私自身は過去、複数の環境を束ねているNginx越しでGrafanaを触ろうとして方式を変えた記憶があったので、改めてトライしてみようと思いました。
129+
130+
### Grafana MCPサーバーによるAIエージェント経由でのGrafanaダッシュボード動的生成
131+
132+
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/37c7b077d940478a91b28eb3b7180532" title="Grafana MCPサーバーによるAIエージェント経由でのGrafanaダッシュボード動的生成" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
133+
134+
Grafana MCPサーバを実際に使って利用できるダッシュボードを作成するセッションでした。今回はClaudeに対して自然言語で入力、対話を続けていき、最後は
135+
136+
OSS版でも対応している限りMCPサーバは使えるようですので、また試したいものが増えてしまいました。
137+
138+
## イベント中の小話
139+
140+
今回ははGrafana Labsの方もいらっしゃったのですが、なんとついに立ち上がった日本法人の入社初日だったらしく、日本のGrafanaのコミュニティが大きく変わりそうな予感がしました。そんなタイミングであることはもちろん知らなかったのですが、LTをここでできたのは個人的には良かったなと思いました。
141+
142+
## まとめ
143+
144+
今回はLTという形で登壇をしつつイベントに参加しましたが、課題を持って、感じてイベントに参加するとイベント後の懇親会も含めてより有意義になることを改めて感じたので、ちゃんと話題としても持っていこうと思いました。
145+
146+
また、今回は実際にto C向けサービスを運用している立場の声を聞くことができたので、よりどう活かそうか、取り込もうかと考えられたことも大きかったので、自身で取り組んでいる構成も見直そうと思います。
147+
148+
今後の日本におけるGrafanaのコミュニティがより盛り上がるように微力ながら頑張っていけたらと思います。
149+
150+
## 参考
151+
152+
- [Grafana Alloyを使って、EKSクラスタ外部のサーバからメトリクス取得を試してみた](/articles/20250825b/)
51.2 KB
Loading
330 KB
Loading
79.2 KB
Loading

0 commit comments

Comments
 (0)