Contents
Quick Start(前提・最短手順)
ここでは最小構成で受信確認までを完了する「最短手順」を示します。短時間で動作確認し、その後に設計とセキュリティを強化してください。
最短手順(数分で受信確認)
最短で受信確認を行うための手順を示します。順に実行し動作を確認してください。
- Grafana Cloud にサインアップし、Stack を作成して Logs を有効化します。Push エンドポイントとドキュメントを控えます。
- Ingest 用の API キー(最小権限)を発行し、安全なシークレットストアに格納します。
- 簡易エージェント(Promtail または Fluent Bit の最小構成)を一台にデプロイして push URL を設定します。まずはテスト用の1ノードで検証します。
- curl でテストログを送信し、Grafana の Logs 画面で受信を確認します(具体例は「テスト送信」節を参照)。
- 受信が確認できたら、ラベル設計・パース・マスキング・サンプリングを段階的に導入します。
Grafana Cloud Logs と Loki の関係
Grafana Cloud の Logs はオープンソース Loki を基盤にしたマネージドサービスです。Loki のラベル指向アプローチは検索性能とコストに影響するため設計が重要です。
Loki のアーキテクチャ概要
Loki はログを「ストリーム(ラベル付き)」として扱い、全文インデックスを作らないことでコストを抑えます。ラベル設計が検索性能と保存コストに直結します。
Grafana Cloud(Managed Loki)の特記事項
Managed Loki はスケーリングや運用の利便性を提供しますが、機能や提供状況はプランやリージョンで異なります。AI インサイト等の有無や保持ポリシーはプラン依存です。製品の詳細は公式ページを参照してください(公式ページ: https://grafana.com/products/cloud/logs/、参照: 2024-06-01)。
収集と導入(エージェント比較・環境別差分)
環境ごとに最適なエージェントとパイプラインの差分を示します。設定の詳細は付録のテンプレートにまとめていますので、本文は差分と設計上のポイントに絞ります。
主要エージェントの比較(概要)
主要エージェントの適用場面と長所短所を簡潔にまとめます。選定は運用要件で判断してください。
- Promtail: Kubernetes 向けに最適化されています。Pod メタデータをラベル化する relabel_configs が強力です。
- Fluent Bit: 軽量で高性能。EC2 やサイドカーに向きます。プラグインで柔軟に出力先を指定可能です。
- Fluentd: 大量データの変換や永続バッファが必要なケースに適します。プラグインが豊富です。
- Beats (Filebeat 等): 既存 Elastic からの移行や単純なファイル収集に便利です。
- CloudWatch / S3 / Athena: AWS ネイティブログはエクスポートやバッチ処理で Loki に投入するハイブリッド運用が可能です。
Kubernetes(Promtail)の差分
Kubernetes 環境では Promtail を DaemonSet 化して Pod メタデータをラベルに付与します。詳しい設定は付録参照です。差分ポイントは次の通りです。
- Pod の検出は kubernetes_sd_configs を使います。
- relabel_configs で namespace、app、pod 名などをラベル化します。
- pipeline_stages で早期に JSON パースやタイムスタンプ補正、PII マスキングを実施します。
EC2 / オンプレ(Fluent Bit / Fluentd)の差分
Fluent Bit は軽量性を優先する場合に、Fluentd は複雑な処理や永続バッファが必要な場合に選びます。差分ポイントを以下に示します。
- Fluent Bit: out_loki または汎用 out_http を使い Authorization ヘッダでトークン指定を推奨します。
- Fluentd: プラグインを利用して HTTP 出力や fluent-plugin-loki を使えます。バッファ設定を慎重に設計してください。
AWS CloudWatch → Loki(S3/Athena を含む)
CloudWatch から直接転送する方法と、S3 にエクスポートしてバッチで Loki に投入する方法の二択があります。設計で留意すべきは IAM 設定、データ転送コスト、遅延要件です。
ラベル設計・LogQL(実務向け)
ラベル設計と LogQL の使い分けは可視化・アラート性能に直結します。ここでは実務で使える指針と代表的なクエリを示します。
ラベル設計(実務方針)
ラベルは検索単位であり、カーディナリティを抑えることが最優先です。設計方針は次の通りです。
- 推奨ラベル: app、env、cluster、namespace、component、region(必要な場合)
- 避けるラベル: user_id、session_id、リクエスト固有の一意値
- 収集側で JSON 構造化を行い、不要フィールドは送信前に除去またはマスキングする
LogQL の基礎と実務クエリ例(Loki 2.x 系を想定)
以下のクエリ例は Loki 2.x 系で一般的な構文を想定しています。関数や最適化の挙動はバージョン差がありますので、公式ドキュメントをあわせて確認してください(LogQL: https://grafana.com/docs/loki/latest/logql/、参照: 2024-06-01)。
-
生ログフィルタ
{app="web", env="prod"} |= "ERROR" -
5 分間のエラー合計(ストリーム合計)
sum(count_over_time({app="web", env="prod"} |= "ERROR" [5m])) -
エラー率 (%)
(
sum(rate({app="web", env="prod"} |= "ERROR" [5m]))
/
sum(rate({app="web", env="prod"} [5m]))
) * 100 -
上位発生源トップ10(インスタンス別)
topk(10, sum by (instance) (count_over_time({app="orders", env="prod"} |= "ERROR" [15m]))) -
JSON パースしてステータスで絞る(パース段階は pipeline_stages と合せて設計)
{app="api"} | json | status >= 500
実務上の注意点として、count_over_time は時間窓内のイベント数を返します。rate は秒当たりレートを返します。例えば 5 分間で 120 件の ERROR があれば、sum(count_over_time(...)) は 120 を返し、sum(rate(... [5m])) はおおむね 120/300 = 0.4(events/sec)となります。これは概念的な例であり、実環境のメトリクス化は検証を推奨します。
可視化・アラート・AIインサイト・運用(コスト管理・セキュリティ)
可視化からアラート設計、AI 機能の扱い方、コスト制御まで運用に必要なポイントをまとめます。
可視化(Grafana 設定の実務)
Grafana の Logs パネルで生ログ確認を行い、Timeseries/Heatmap でメトリクス化した LogQL を可視化します。頻繁参照する指標はログからメトリクス化して Timeseries にするのが有効です。
アラート設計(ノイズ対策)
ログベースのアラートはメトリクス化クエリを用います。ノイズ低減の手法としては次が有効です。
- 条件に for を付けて短期スパイクを無視する
- サービス単位でグルーピングしてアラート粒度を調整する
- サンプリングや dedup を導入する
例: 条件 sum(count_over_time({app="web", env="prod"} |= "ERROR" [5m])) > 50 を Evaluate every 1m For 5m とする。
AI インサイト(提供状況と注意点)
AI による要約や異常検知は運用効率を上げますが、機能はプランや地域で提供状況が異なります。AI 処理に供するログからは PII を除外または匿名化し、AI の出力は補助として扱って必ず人のレビューや監査を行ってください。機能詳細は公式ドキュメントを参照してください(公式ページ: https://grafana.com/products/cloud/logs/、参照: 2024-06-01)。
コスト管理
コストは取り込みバイト数、保持期間、クエリ頻度で決まります。対策として保持期間の階層化、取り込み前のサンプリング、不要フィールドの削減、長期アーカイブの S3 移行を検討してください。
セキュリティ・テスト送信・トラブルシューティング
認証やシークレット運用、テスト送信例、よくあるエラーの対処法を実務で使える形でまとめます。
認証と推奨方式
認証はトークンベース(Bearer トークン/サービスアカウント)を推奨します。Basic 認証が必要なケースはプラグインの互換性によるため、可能なら Authorization ヘッダでトークンを渡す方式を使ってください。API キーは最小権限で発行し、ハードコーディングは避けます。
シークレット管理とローテーション手順
シークレットは Vault/KMS/Cloud Secret Manager 等で管理し、定期ローテーションを実装します。基本的なローテーション手順は次の通りです。
- Grafana Cloud 上で新しい API キーを発行する(最小権限)。
- 新しいキーをシークレットストアへ登録する。
- エージェントの設定を参照するシークレットを更新し、ローリングでエージェントを再起動する。
- 取り込みメトリクスで正常性を確認する(エラー増加や 401 を検出しないこと)。
- 問題がなければ旧キーを削除する。
ローテーション頻度はリスク評価に基づき決定してください(例: 90 日)。
curl でのテスト送信(実行例)
以下は Loki の push API へ直接送る最小の curl 例です。ヘッダには Bearer トークンを推奨します。タイムスタンプはナノ秒単位文字列を使用します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
curl -X POST 'https://<LOKI_PUSH_URL>/loki/api/v1/push' \ -H "Authorization: Bearer <YOUR_API_KEY>" \ -H 'Content-Type: application/json' \ --data-raw '{ "streams": [ { "stream": {"app":"test","env":"dev"}, "values": [ ["'"$(date +%s%N)"'","{\"level\":\"info\",\"msg\":\"test log from curl\"}"] ] } ] }' |
上記の
よくあるエラーと対処
運用で頻出する障害と簡単な対処案を示します。
- 401 Unauthorized: API キーの権限と保存場所(改行やエンコード)を確認する。
- TLS ハンドシェイク失敗: サーバ証明書チェーン、TLS バージョン設定、tls.verify を確認する。
- 404 / endpoint not found: Push エンドポイントの URL を確認する。
- パース失敗: pipeline_stages の JSON/regex 設定を検証する。
- カーディナリティ急増: ラベル漏れや一意キーがラベル化されていないか確認し、ラベル設計を見直す。
- エージェントバッファオーバーフロー: バッファ設定とディスク永続バッファを有効化する。
エージェントの確認コマンド(例)
エージェントの動作状況を確認する基本コマンド例です。環境に合わせて実行してください。
- Kubernetes: kubectl get daemonset -n
promtail - Kubernetes: kubectl logs -l app=promtail -n
--tail 200 - Systemd (Fluent Bit): sudo systemctl status fluent-bit
- Systemd (Fluent Bit) logs: sudo journalctl -u fluent-bit -f
- エージェントのメトリクス(Prometheus)を確認してエラーを把握する
付録: 設定テンプレート(集中管理)
ここに主要テンプレートを集中して掲載します。実運用ではシークレットを外部ストアから注入し、設定をテンプレート化して管理してください。プラグインごとのキー名やオプションはバージョン差があるため、各プラグインの公式ドキュメントも参照してください(付録の例はテンプレートとして利用してください)。
Promtail(promtail.yaml のテンプレート)
以下は主要パラメータを示すテンプレート例です。認証はファイル経由の Bearer トークンを想定しています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
server: http_listen_port: 9080 positions: filename: /var/log/promtail/positions.yaml clients: - url: https://<LOKI_PUSH_URL>/loki/api/v1/push bearer_token_file: /var/run/secrets/loki/token # シークレットマウント推奨 scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod pipeline_stages: - json: expressions: level: level msg: message - timestamp: source: time format: RFC3339 - labels: level: - drop: expression: 'level == "debug"' relabel_configs: - source_labels: [__meta_kubernetes_namespace] target_label: namespace - source_labels: [__meta_kubernetes_pod_label_app] target_label: app |
注: Grafana Cloud の場合、push URL とトークンの取得方法は Stack の UI を参照してください。トークンはボリュームや Secret マネージャ経由で注入してください。
Fluent Bit(fluent-bit.conf のテンプレート、概念例)
Fluent Bit は out_loki プラグインや out_http を利用できます。ここでは汎用的な out_http のヘッダ指定例を示します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
[Service] Flush 1 Log_Level info [Input] Name tail Path /var/log/containers/*.log Parser docker Tag kube.* [Parser] Name docker Format json [Filter] Name kubernetes Match kube.* [Output] Name http Match * Host <LOKI_HOST> Port 443 URI /loki/api/v1/push Header Authorization Bearer <TOKEN_PLACEHOLDER> Format json tls On tls.verify On |
注: out_loki プラグインを使う場合はプラグインのオプションに合わせて認証方法を指定してください。Authorization ヘッダにトークンを入れる手法が互換性高く推奨されます。
Fluentd(概念テンプレート)
Fluentd は fluent-plugin-loki や out_http を利用できます。以下は汎用 http 出力の概念例です。プラグインの設定方法はバージョンで異なるので注意してください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
<source> @type tail path /var/log/myapp/*.log pos_file /var/log/fluentd-pos/myapp.pos tag myapp format json </source> <filter myapp> @type record_transformer <record> hostname ${hostname} </record> </filter> <match myapp> @type http endpoint https://<LOKI_PUSH_URL>/loki/api/v1/push serializer json <buffer> flush_interval 5s </buffer> <header> Authorization Bearer <TOKEN_PLACEHOLDER> </header> </match> |
注: 実際のプラグインでは header の指定方法が異なる場合があります。fluent-plugin-loki の使用を検討すると設定が簡潔になる場合があります。
LogQL クエリ集(付録)
代表的な LogQL のクエリをまとめます。実運用では時間範囲やラベルで絞り込み、頻出指標はメトリクス化してください。
- {app="web", env="prod"} |= "ERROR"
- sum(count_over_time({app="web"} |= "ERROR" [5m]))
-
(
sum(rate({app="web"} |= "ERROR" [5m]))
/
sum(rate({app="web"} [5m]))
) * 100 -
topk(10, sum by (instance) (count_over_time({app="orders", env="prod"} |= "ERROR" [15m])))
用語集(表記の統一)
主要用語の表記を統一します。以後はこの表記を本文で用いました。
| 用語(日本語) | 英語 / 原語表記 |
|---|---|
| カーディナリティ | cardinality |
| ラベル | label |
| ストリーム | stream |
| パイプラインステージ | pipeline stage |
| AI インサイト | AI Insights |
参考リソース(公式・実践記事)
重要な公式ドキュメントと参考記事を掲載します。内容は随時更新されるため実運用前に再確認してください。
- Grafana Cloud Logs(公式) — https://grafana.com/products/cloud/logs/(参照: 2024-06-01)
- Loki / LogQL リファレンス(公式) — https://grafana.com/docs/loki/latest/(参照: 2024-06-01)
- CloudWatch → S3 / Athena 経由の事例(サードパーティ) — https://dev.classmethod.jp/articles/aws-cloudtrail-grafana-loki/(参照: 2024-06-01)
まとめ
最短で検証する手順と、実務で重要なラベル設計、認証・シークレット運用、コスト管理の要点をまとめました。まずは小規模で受信確認を行い、ラベル設計とマスキング、ローテーションを順に導入して本番化してください。