プロダクト紹介
Log Serviceとは
ログデータのワンストップサービスとして、Log Service (Log) は Alibaba Group のビッグデータシナリオで実証済みです。Log Service を使用することにより、開発することなく、迅速にログデータを収集、処理、送信、照会/分析することができます。保守管理 (O＆M) と運用の効率が上がり、DT (データ技術) 時代において膨大なログを処理できます。
Log Service のラーニングパス
Log Service のラーニングパスは、推奨機能に関するドキュメントであり、Log Service に関する知識を迅速に蓄積するのに役立ちます。ドキュメントおよびビデオが用意されており、習得しやすくなっています。
リアルタイムにログを収集/処理 (LogHub)
機能：
- Elastic Compute Service (ECS)、コンテナ、モバイル端末、オープンソースソフトウェア、 JS を使用してリアルタイムログデータ (Metric、Event、 BinLog 、TextLog、Click など) にアクセスします。
- リアルタイム処理やリアルタイムサービスと連携できるよう、リアルタイム処理インターフェイスが用意されています。
目的：
ETL、ストリーム処理、モニタリングとアラーム、機械学習、反復計算。
LogShipper
安定した信頼性の高いログ送信 (shipping) により、 LogHub のデータはストレージサービスに送信、格納され、ビッグデータを分析できます。。 圧縮、カスタム化パーティション、行ストレージ、列ストレージといったさまざまなストレージ方法に対応しています。
目的：
データウェアハウス+ データ分析、モニタリング、推奨システム、ユーザープロファイリング
リアルタイムに照会/分析（照会/分析）
リアルタイムにデータのインデックスが作成され、照会、分析できます。
- クエリ: キーワード検索、あいまい検索、コンテキスト検索、および範囲検索
- 統計: SQL 集約といった豊富なクエリ方法
- 視覚化: ダッシュボードおよびレポート機能
- 相互接続: Grafana および JDBC/SQL9
目的：
DevOps /オンライン O＆M 、リアルタイムなログデータ分析、セキュリティ診断と分析、運用とカスタマーサービスシステム
利点
完全管理型サービス
- 優れたアクセシビリティで、サービスの利用開始までに 5 分とかかりません。また、エージェントを使用して、あらゆるネットワーク環境でデータを収集できます。
- LogHub は Kafka のすべての機能を備えており、モニタリングやアラームといった有用データを提供し、自動スケーリング（PB /日単位）に対応します。 使用コストは、自社開発コストの 50％ 未満に収まります。
- LogSearch/Analytics には、クエリの保存、ダッシュボード、およびアラーム機能があります。使用料は、自社開発時の 20％ 未満です。
- Log Service に接続する方法は、30 以上あります。シームレスにクラウド製品 (OSS、E-MapReduce、MaxCompute、Table Store、MNS、CDN) やオープンソースソフトウェア (Storm や Spark) と連携できます。
豊富なエコシステム
- LogHub は、LogStash や Fluentd といった 30 以上ものログ収集ツールに対応しています。組み込みデバイス、Web ページ、サーバー、プログラムから簡単に接続できます。また、Spark Streaming、Storm、 CloudMonitor、ARMS といった処理システムとも連携できます
- LogShipper は、さまざまなデータ形式 (TextFile、SequenceFile、Parquet など) に対応しており、シャードをカスタム化することもできます。また、Presto、Hive、Spark、Hadoop、E-MapReduce、HybridDB といったストレージエンジンより直接データを処理することができます。
- LogSearch/Analytics は、クエリ構文と分析構文が完備されており、SQL-92 と互換性があります。JDBC プロトコルで Grafana との連携も可能です。
高性能なリアルタイム処理
- LogHub: データが書き込まれると同時に使用できます。 Logtail (データ収集エージェント) は、データを 1 秒以内に収集し、サーバー側に転送します (99.9 % のケースで)。
- LogSearch/Analytics: データが書き込まれると同時に照会し、分析することができます。複数のクエリ条件を指定した場合でも、膨大なデータから 1 秒以内に分析することができます。複数の集約条件を指定した場合も、膨大なデータから 1 秒以内に分析することができます。
完全な API / SDK
- カスタム化した管理や二次開発を行えます。
- API / SDK ですべての機能を実装できます。あらゆる言語の SDK が用意されており、容易にサービスを管理できます。
- クエリ構文と分析構文 (SQL-92 互換) はシンプルです。インターフェイスを使用して、オープンソフトウェアに簡単に接続できます (Grafana との連携も可)。
コストメリット
コストメリット
Log Serviceは、3つのログ処理シナリオにより、下記のコスト上の利点があります：
- LogHub:
- 購入したクラウドホスト+クラウドディスクを使用してカフカを構築する場合と比較して、98％のシナリオでコスト効率の高い選択肢となります。 小規模のウェブサイトのカフカコストを30％削減します。
- RESTful APIの提供により、モバイルデバイス上のデータ収集をサポートし、ログ収集用のゲートウェイサーバーのコストを削減します。
- いつでもどこにいても、メンテナンスフリーと自動スケーリングができます。
- LogShipper:
- コード/マシンリソースが不要で、柔軟な構成、豊富な監視データ。
- リニアスケーラビリティ（1日あたりPB級）、現在無料で利用可能。
- LogSearch/Analytics:
- クラウドホスト+自己ビルドELKを購入するコストの15％以下で、クエリ機能とデータ処理規模を大幅に強化します。 詳しくは比較レポートをご参照ください。 上記のログ管理ソフトウェアソリューションよりも優れた選択肢としては、さまざまなストリームコンピューティング+オフラインコンピューティングフレームワークをシームレスに統合することで、ログの妨げにならないようにします。
コスト比較
ご参考として、以下に課金モデルにおけるLog Serviceと自己構築ソリューションの比較例を記します。
LogHub (LogHub vs Kafka)
| - | フォーカス | LogHub | 自立ミドルウェア（Kafkaなど） |
|---|---|---|---|
| Use | New | Imperceptible | O&M required |
| Expansion | Imperceptible | O&M required | |
| Increase backups | Imperceptible | O&M required | |
| Multitenancy | Quarantine | Might affect each other | |
| 费用 | Internet collection (10 GB/day) | USD 2/day | USD 16.1/day |
| Internet collection (1 TB/day) | USD 162/day | USD 800/day | |
| Intranet collection (small data size) | - | - | |
| Intranet collection (moderate data size) | - | - | |
| Intranet collection (large data size) | - | - |
ログストレージとクエリエンジン
| フォーカス | LogSearch | ES (Lucene Based) | NoSQL | Hive | - |
|---|---|---|---|---|---|
| Scale | Scale | PB | TB | PB | PB |
| Cost | Store (USD/GB per day) | 0.0115 | 3.6 | 0.02 | 0.035 |
| Write (USD/GB) | 0.35 | 5 | 0.4 | 0 | |
| Query (US $/GB) | 0 | 0 | 0.2 | 0.3 | |
| Speed-query | Millisecond level-second level | Millisecond level-second level | Within milliseconds | In minutes | |
| Speed-statistics | Weak+ | Relatively strong | Weak | Strong | |
| Latency | Write->queryable | Real time | In minutes | Real time | Ten-minute level |
注：ここでの価格比較は、ソフトウェアソリューションがECSに導入され、3つのコピーが構成されているという事実に基づいて計算されています。
シナリオ
Log Service アプリケーションによくあるシナリオとして、データ収集、リアルタイム処理、データウェアハウスのオフライン分析、プロダクトの運用と分析、O＆M と管理があります。一般的なアプリケーションのシナリオを以下に示します。 ベストプラクティスにもシナリオをいくつか記載されていますので、ご参照ください。
データの収集と処理
Log Service の LogHub 機能により、大量のリアルタイムログデータ (Metric、BinLog、TextLog、Click を含む) に低コストにアクセスできます。
ソリューションの利点：
- 使いやすい: リアルタイムにデータを収集する方法が 30 以上用意されており、すばやく環境を構築することができます。高性能な設定と管理機能により、保守管理にかかる負荷を軽減させることができます。中国、また、世界のあらゆるリージョンにあるノードをご利用いただけます。
- 自動スケーリング: トラフィック量の増加やサービス拡充に容易にご対応いただけます。
図1.データの収集と処理
ETL/ストリーム処理
LogHub は、あらゆるリアルタイム処理サービスと組み合わせることができます。進捗モニタリングとアラーム機能を完備しており、SDK/API でカスタマイズ処理できます。
- 簡単な操作性: さまざまな SDK とプログラミングフレームワークが用意されており、シームレスにさまざまなストリーム処理エンジンと連携できます。
- 機能が豊富: さまざまなモニタリングデータ、アラーム機能が用意されています。
- 柔軟な拡張性: 遅延なしに PB 単位に拡張できます。
図2.データクリーニングとストリーム処理
データウェアハウス
LogShipper により、LogHub 内のデータがストレージサービスに送信 (ship) されます。圧縮、カスタム化シャード、行ストレージ、列ストレージといったあらゆるストレージ形式に対応します。
- 大量のデータ: データ量に上限なし
- 豊富なストレージ形式: 行ストレージ、列ストレージ、TextFile といった、さまざまなストレージ形式に対応
- 柔軟に設定: シャードのカスタム化といった設定が可能
図3.データウェアハウスにドッキング
ログをリアルタイムに照会/分析
LogAnalytics は、LogHub のデータをリアルタイムにインデックスが作成され、キーワード検索、あいまい検索、コンテキスト、範囲指定、SQL 集約といったクエリが豊富に用意されています。
- 高性能にリアルタイム: データが書き込まれたと同時にクエリ可能
- 大容量で低コスト: PB/日でインデックスが作成され、独自開発する場合と比較して 15 % 割安
- 高度に分析: あらゆるクエリが行えます。また、視覚化とアラーム通知機能が用意されています。
図4.リアルタイムなログ照会/分析
基本概念
ログ
ログは、プロセス実行によってシステムに加えられた変更を要約したものです。ログの中身は、特定のオブジェクトに対して行なった処理を時系列に集まっています。LogFile、Event、BinLog、および Metric のデータは、それぞれ異なるログに格納されています。各ログファイルはログを 1 つ以上含み、各ログにはシステムイベントが 1 つ記述されています。Log Service で処理されるデータの最小単位がログです。
ロググループ
ロググループはログを集めたものであり、書き込みと読み取りの基本単位です。
ログトピック
Logstore 内のログは、ログトピック別に分類することができます。ログを書き込む際はトピックを指定することができます。照会の際は、トピックは必ず指定する必要があります。
プロジェクト
プロジェクトは、 Log Service におけるリソース管理の単位です。リソースをそれぞれ別々に管理することができます。プロジェクトにより、アプリケーションのログと関連するログソースをすべて管理できます。 プロジェクトで、Logstore 情報、ログ収集マシンの設定情報のすべてを管理し、Log Service リソースにアクセスするためのポータルとしての役割を果たします。
Logstore
Logstore は、Log Service におけるログデータの収集、保存、およびクエリの単位です。各 Logstore はプロジェクトに属し、各プロジェクトには複数の Logstore を作成することができます。
シャード
各 Logstore はいくつかのシャードに分割され、各シャードの範囲は MD5 左閉右開区間です。各区間は重複することがなく、全シャードの範囲は、すべての MD5 区間を合わせたものとなります。
FAQ
ログ収集エラーの種類
Logstore ページで、診断をクリックすると、Logstore のログ収集エラーがすべて表示されます。 エラーの種類および各エラーの処理方法は、以下のとおりです。
本ドキュメントに記載されていないエラーが発生した場合は、チケットを起票し、サポートセンターにお問い合わせください。なお、起票の際は、エラーの詳細をご提示ください。
| エラーの種類 | 説明 | 処理方法 |
|---|---|---|
| LOGFILE_PERMINSSION_ALARM | 指定したファイルを読み取る権限が Logtail にありません。 | Logtail サーバーを起動したアカウントを確認します。 root ユーザーで Logtail を起動されることをお勧めします。 |
| SPLIT_LOG_FAIL_ALARM | 正規表現と、ログの行頭のパターンが一致しないため、ログを複数行に分割することができません。 | 行頭の正規表現が正しいかどうか確認します。 1 行ログの場合、行頭の正規表現を .*にします。 |
| MULTI_CONFIG_MATCH_ALARM | 各ログファイルは、1 つの設定でしか収集させることができません。 | ログファイルが、複数の設定で収集されていないことを確認します。 ログが複数の設定で収集されている場合は、不要な設定を削除します。 |
| REGEX_MATCH_ALARM | ログコンテンツと正規表現のパターンとが一致しません。 | サンプルとして、パターンの一致しないログコンテンツをコピーし、新たに正規表現を生成し直します。 |
| PARSE_LOG_FAIL_ALARM | ログフォーマットが、JSON 形式または区切り文字形式に沿っていないため、ログの解析に失敗します。 | エラーメッセージをクリックして詳細を確認します。 |
| CATEGORY_CONFIG_ALARM | Logtail に無効な設定がされています。 | 正規表現でログ項目のファイルパスを抽出する際によく発生するエラーです。正規表現を修正されることをお勧めします。 エラーの原因が上記に該当しない場合は、チケットを起票し、サポートセンターにお問い合わせください。なお、起票の際は、エラーの詳細をご提示ください。 |
| LOGTAIL_CRASH_ALARM | Logtail サーバーのリソース使用量が上限に達しているため、Logtail からの応答がありません。 | CPU 使用量およびメモリ使用量の上限を変更する方法については、「Logtail 起動設定パラメーター」をご参照ください。 または、チケットを起票し、サポートセンターにお問い合わせください。 |
| REGISTER_INOTIFY_FAIL_ALARM | Linux へのログモニタリング登録に失敗しました。 原因としては、フォルダに対するアクセス権が Logtail にない、または、ログフォルダが削除されていることが考えられます。 | フォルダへのアクセス権が Logtail にあるかどうか、また、フォルダが削除されていないかどうかを確認します。 |
| DISCARD_DATA_ALARM | Logtail の使用可能な CPU リソースが不足しているか、Log Service の受信可能なトラフィック量が上限を超えています。 | 使用可能な CPU の上限、または、Log Service の受信可能なトラフィック量の上限を変更する方法については、「Logtail 起動設定パラメーター」をご参照ください。 または、チケットを起票し、サポートセンターにお問い合わせください。 |
| SEND_DATA_FAIL_ALARM |
|
|
| REGISTER_INOTIFY_FAIL_ALARM | Logtail による、ログディレクトリへの inotify ウォッチャーの登録に失敗しました。 | ディレクトリがあるかどうかを確認します。 また、ディレクトリに設定されているアクセス権を確認します。 |
| SEND_QUOTA_EXCEED_ALARM | 書き込みログが上限を超えています。 | コンソールで、シャード数を増やします。 |
| READ_LOG_DELAY_ALARM | ログの生成に、ログの収集が追いついていません。 一般的には、Logtail に必要な CPU リソースが不足しているか、Log Service に設定されている受信トラフィックの上限が原因です。 | 使用可能な CPU の上限、または、Log Service の受信可能なトラフィック量の上限を変更する方法についてはチケットを起票し、サポートセンターにお問い合わせください。 |
| DROP_LOG_ALARM | ログの生成に、ログの収集が追いついていません。収集されていないログが 20 を上回っています。 一般的には、Logtail に必要な CPU リソースが不足しているか、Log Service の受信可能なトラフィック量が上限を超えていることが原因です。 | 使用可能な CPU の上限、または、Log Service の受信可能なトラフィック量の上限を変更する方法については、チケットを起票し、サポートセンターにお問い合わせください。 |
| LOGDIR_PERMINSSION_ALARM | ログモニタリング対象のディレクトリを読み取る権限が Logtail にありません。 | ログモニタリングディレクトリがあるかどうかを確認します。 また、ディレクトリに設定されているアクセス権を確認します。 |
| ENCODING_CONVERT_ALARM | コードのエンコードに失敗しています。 | ログのエンコード形式が指定した形式に沿っていることを確認します。 |
| OUTDATED_LOG_ALARM | Logtail がログを受信してから 12 時間経過しており、ログの期限が切れています。 考えられる原因は次のとおりです。
|
|
| STAT_LIMIT_ALARM | Logtail 構成ディレクトリ下のファイル数が上限を超えています。 | Logtail 構成ディレクトリに、ファイルおよびサブディレクトリの数が異常に多くないかどうか確認します。 ファイルおよびサブディレクトリの数が異常に多い場合は、モニタリングするルートディレクトリ、また、そのディレクトリからどの階層までモニタリングするかを指定します。 |
| DROP_DATA_ALARM | ログ収集の処理が完了すると、ローカルディスクに対するログの書き込み期限も終了します。 ローカルディスクに書き込まれなかったログは破棄されます。 | 一般的に、収集ブロックに重大な障害が発生している場合に、本エラーが報告されます。 なお、チケットを起票し、サポートセンターにお問い合わせいただくことでもアップグレードできます。 |
| INPUT_COLLECT_ALARM | ログの収集時にエラーが発生しました。 | エラーメッセージに従ってエラーを処理します。 |
| HTTP_LOAD_ADDRESS_ALARM | 無効な HTTP アドレスです。 | 有効なアドレスかどうか確認します。 |
| HTTP_COLLECT_ALARM | HTTP によるログ収集でエラーが発生しました。 | エラーメッセージに従ってエラーを処理します。 一般的に、有効期限が切れているために発生するエラーです。 |
| FILTER_INIT_ALARM | フィルターの初期化でエラーが発生しました。 | エラーメッセージに従ってエラーを処理します。 一般的に、無効な正規表現によるフィルタリングが原因で発生するエラーです。 |
| INPUT_CANAL_ALARM | MySQL binlog の実行中に発生するエラーです。 | エラーメッセージに従ってエラーを処理します。 Logtail 構成が更新されると、canal サービスが再起動することがあります。 canal サービスの再起動でエラーが発生している場合は、無視して構いません。 |
| CANAL_INVALID_ALARM | MySQL binlogs の内部ステータスが正常ではありません。 | エラーが発生したときにテーブルのスキーマに変更がなかったかどうかを確認します。 binlog の実行中にテーブルのスキーマに変更があり、メタデータに変更があった場合によく発生するエラーです。上記が原因でない場合は、チケットを起票し、サポートセンターにお問い合わせください。 |
| MYSQL_INIT_ALARM | MySQL の初期化でエラーが発生しました。 | エラーメッセージに従ってエラーを処理します。 |
| MYSQL_CHECKPOING_ALARM | MySQL のチェックポイントの形式が正しくありません。 | 実行中の Logtail のチェックポイント設定を変更する必要があるか確認します。 チェックポイントの設定を変更してもエラーが解決しない場合は、チケットを起票し、サポートセンターにお問い合わせください。なお、起票の際は、エラーの詳細をご提示ください。 |
| MYSQL_TIMEOUT_ALARM | MySQL クエリの期限が切れています。 | MySQL サーバー、または、ネットワークに異常がないか確認します。 |
| MYSQL_PARSE_ALARM | MySQL クエリ結果の解析に失敗します。 | MySQL に設定しているチェックポイント形式と、当該フィールドの形式とが一致するかどうか確認します。 |
| AGGREGATOR_ADD_ALARM | Logtail はキューへのデータ追加に失敗しました。 | 送信するデータが大きい場合、本エラーは無視して構いません。データを送信するタイミングが早すぎるためにエラーが発生しています。 |
| ANCHOR_FIND_ALARM | アンカープラグインの誤り、アンカープラグインを誤って設定している、または、ログが設定と一致しない、のいずれかがエラーの原因として考えられます。 | エラーメッセージをクリックしてエラーの詳細を表示します。次のいずれかに該当しないか確認します。 エラーの詳細を基に、該当する設定を確認します。
|
| ANCHOR_JSON_ALARM | anchor プラグインが Start および Stop に指定されたキーワードに対して JSON を展開する際にエラーが発生します。 | エラーメッセージをクリックしてエラーの詳細を表示します。 キーワードおよび関連する構成を確認します。 構成に誤りがないか、また、無効なログがないか確認します。 |
| CANAL_RUNTIME_ALARM | binlog プラグインの実行時にエラーが発生しました。 | エラーメッセージをクリックして詳細を表示し、エラーを対処します。 接続している MySQL マスターデータベースに関するエラーです。 |
| CHECKPOINT_INVALID_ALARM | プラグインがチェックポイントの解析に失敗しました。 | エラーメッセージをクリックして詳細を表示し、チェックポイントキー、チェックポイントのコンテンツ (最初の 1,024 バイト) といった情報を基にエラーを対処します。 |
| DIR_EXCEED_LIMIT_ALARM | 同時にモニタリングしているディレクトリ数が上限を超えました。 | Logstore や Logtail に設定したディレクトリ下にディレクトリ数が多すぎないかどうか確認します。 ディレクトリ数が多い場合には、モニタリングするルートディレクトリ、ディレクトリの階層を調整します。 |
| DOCKER_FILE_MAPPING_ALARM | Logtail のコマンドによる Docker ファイルマッピング追加に失敗しました。 | エラーメッセージをクリックして詳細を表示し、エラーを対処します。 |
| DOCKER_FILE_MATCH_ALARM | 指定されたファイルが Docker コンテナにありません。 | エラーメッセージをクリックして詳細を表示し、コンテナ情報およびファイルパスを基にエラーを対処します。 |
| DOCKER_REGEX_COMPILE_ALARM | Docker の stdout プラグインは、BeginLineRegex 設定の正規表現を構築できません。 | エラーメッセージをクリックして詳細を表示し、正規表現が適切かどうかを確認します。 |
| DOCKER_STDOUT_INIT_ALARM | Docker は標準出力収集の初期化に失敗しました。 | エラーメッセージをクリックして詳細を確認します。エラーが次のいずれかに該当しないか確認します。
|
| DOCKER_STDOUT_START_ALARM | Docker の標準出力 (stdout) 収集の初期化時に、stdout のファイルサイズが上限を超えました。 | 通常、最初の収集時に stdout ファイルは既に存在するため、エラーを無視して構いません。 |
| DOCKER_STDOUT_STAT_ALARM | Docker stdout プラグインは stdout ファイルの確認に失敗しました。 | エラーは無視して構いません。コンテナが停止しているために、コンテナによる標準出力ファイルへのアクセスが失敗しています。 |
| FILE_READER_EXCEED_ALARM | Logtail によって開かれているファイル数が上限を超えました。 | 設定内容が適切かどうかを確認します。収集されているファイル数が多すぎる場合に発生するエラーです。 |
| GEOIP_ALARM | geoip プラグインに問題があります。 | エラーメッセージをクリックして詳細を確認します。詳細には、次のいずれかに該当しないか確認します。
|
| HTTP_INIT_ALARM | 設定に指定されている ResponseStringMatch 正規表現が適切でないために、HTTP プラグインがコンパイルに失敗しました。 | エラーメッセージをクリックして詳細を表示し、正規表現に間違いがないかどうかを確認します。 |
| HTTP_PARSE_ALARM | HTTP は HTTP レスポンスを受信できません。 | エラーメッセージをクリックして詳細を表示し、設定、また、リクエスト先 HTTP サーバーを確認します。 |
| INIT_CHECKPOINT_ALARM | binlog プラグインがチェックポイントの読み込みに失敗しました。 プラグインはプレークポイントを無視してログの収集を続けます。 | エラーメッセージをクリックして詳細を表示し、無視しても問題のないエラーかどうかを確認します。 |
| LOAD_LOCAL_EVENT_ALARM | Logtail はローカルイベントを処理しました。 | 手動操作によるイベントであれば無視します。その他の場合は、チケットを起票し、サポートセンターにお問い合わせください。なお、起票の際は、エラーの詳細をご提示ください。エラーの詳細 (ファイル名、構成名、プロジェクト、Logstore、およびその他の情報) は、エラーメッセージをクリックすると表示されます。 |
| LOG_REGEX_FIND_ALARM | processor_split_log_regex および processor_split_log_string プラグインが、ログから、設定に指定されている SplitKeyの取得に失敗しました。 | エラーメッセージをクリックして詳細を表示し、設定に問題がないか確認します。 |
| LUMBER_CONNECTION_ALARM | service_lumberjack プラグインでエラーが発生したため、サーバーを停止することができません。 | エラーメッセージをクリックして詳細を表示し、適切にエラーを処理します。 一般的に、無視して構わないエラーです。 |
| LUMBER_LISTEN_ALARM | ログモニタリング用 service_lumberjack プラグインの起動中にエラーが発生しました。 | エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。
|
| LZ4_COMPRESS_FAIL_ALARM | Logtail による LZ4 圧縮の際にエラーが発生しました。 | エラーメッセージをクリックして詳細を表示し、ログフィールドの値、プロジェクト、カテゴリ、およびリージョンを基にエラーを対処します。 |
| MYSQL_CHECKPOINT_ALARM | MySQL プラグインでチェックポイントエラーが発生しました。 | エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。
|
| NGINX_STATUS_COLLECT_ALARM | nginx_status プラグインがサーバーステータスを取得する際にエラーが発生しました。 | エラーメッセージをクリックして詳細を表示し、URL およびエラー情報を基にエラーを対処します。 |
| NGINX_STATUS_INIT_ALARM | nginx_status プラグインは、設定に指定されている URL の起動および解析に失敗しました。 | エラーメッセージをクリックして詳細を表示し、URL のアドレスが適当かどうか確認します。 |
| OPEN_FILE_LIMIT_ALARM | 開いているファイルの数が上限に達しているため、新しいファイルを Logtail が開くことができません。 | エラーメッセージをクリックして詳細を表示し、ログのファイルパス、プロジェクト、Logstore といった情報を基にエラーを処理します。 |
| OPEN_LOGFILE_FAIL_ALARM | Logtail がファイルを開く際にエラーが発生しました。 | エラーメッセージをクリックして詳細を表示し、ログのファイルパス、プロジェクト、Logstore といった情報を基にエラーを対処します。 |
| PARSE_DOCKER_LINE_ALARM | service_docker_stdout プラグインがログの解析に失敗しました。 | エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。
|
| PLUGIN_ALARM | プラグインの初期化または呼び出しにエラーが発生しました。 | エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。 適切にエラーを対処します。
|
| PROCESSOR_INIT_ALARM | 正規表現プラグインが、設定に指定された正規表現のコンパイルに失敗しました。 | エラーメッセージをクリックして詳細を表示し、正規表現が適切かどうか確認します。 |
| PROCESS_TOO_SLOW_ALARM | Logtail のログ解析に時間がかかり過ぎています。 |
|
| REDIS_PARSE_ADDRESS_ALARM | Redis プラグインは、設定に指定されている ServerUrls の解析に失敗しました。 | エラーメッセージをクリックして詳細を表示し、URL を確認します。 |
| REGEX_FIND_ALARM | 正規表現プラグインは、ログ内に、SourceKey として指定されているフィールドを特定できませんでした。 | エラーメッセージをクリックして詳細を表示し、SourceKey に間違いがないかどうか、また無効なログが存在しないかどうかを確認します。 |
| REGEX_UNMATCHED_ALARM | プラグインの正規表現が、ログのパターンと一致しません。 | エラーメッセージをクリックして詳細を表示します。エラーの詳細は、次のいずれかに該当します。 設定が正しいかどうか確認し、適切にエラーを対処します。
|
| SAME_CONFIG_ALARM | Logstore に同じ名前の設定があります。 Logtail はいずれかの設定でログ収集されます。ログ収集に使用しない方の設定は破棄されます。 | エラーメッセージをクリックして詳細を表示し、指定したパスやエラー情報を確認してエラーを対処します。 |
| SPLIT_FIND_ALARM | split_char プラグインまたは split_string プラグインは、ログ内に、SourceKey として指定されているフィールドを特定することができません。 | エラーメッセージをクリックして詳細を表示し、SourceKey 設定が適切か、また無効なログが存在しないかどうか確認します。 |
| SPLIT_LOG_ALARM | processor_split_char プラグインまたは processor_split_string プラグインの解析フィールド数が、SplitKeys のフィールド数と異なります。 | エラーメッセージをクリックして詳細を表示し、SourceKey の設定が適切か、また無効なログが存在しないかどうか確認します。 |
| STAT_FILE_ALARM | プラグインが LogFileReader オブジェクトからログファイルを収集した際に、エラーが発生しました。 | エラーメッセージをクリックして詳細を表示し、ファイルパスなどの情報を確認してエラーを対処します。 |
| SERVICE_SYSLOG_INIT_ALARM | service_syslog プラグインの初期化に失敗しました。 | エラーメッセージをクリックして詳細を表示します。設定されているアドレスが適切かどうか確認します。 |
| SERVICE_SYSLOG_STREAM_ALARM | service_syslog プラグインによる TCP 経由でのデータ収集時にエラーが発生しました。 | エラーメッセージをクリックして詳細を表示します。エラーの内容は次のいずれかに該当します。 適切にエラーを処理します。
|
| SERVICE_SYSLOG_PACKET_ALARM | service_syslog プラグインの UDP 経由のデータ収集にエラーが発生しました。 | エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。 適切にエラーを処理します。
|
収集エラーをトラブルシュート
Logtail でのログ収集に失敗、また、収集が異常ステータスの場合、次の手順に従ってエラーをトラブルシュートします。
手順
- マシングループの Logtail のハートビートが正常であるかどうかを確認 Log Service コンソールにログオンし、マシンステータスをクリックして、マシングループのステータスを確認します。詳細は、マシングループの管理をご参照ください。 ハートビートが正常ステータスであれば、次のステップへ進みます。
ハートビートが失敗ステータスの場合、Logtail ハートビートエラーのトラブルシューティングをご参照ください。
- 収集の構成情報が作成され、マシングループに適用されているかどうかを確認 Logtail クライアントが正常ステータスであることを確認できた場合、以下を確認します。
- Logtail の構成情報が作成されているかどうか 詳細は、Logtail の構成情報をご参照ください。ログモニタリングのディレクトリおよびログファイル名が、マシン上のファイルと相違ないことを確認します。ディレクトリにはワイルドカードを使用することができないため、絶対パスを指定します。ログファイル名にワイルドカードを使用することはできます。
- マシングループに Logtail 設定が適用されているかどうか マシングループの管理の構成情報の管理を確認します。構成がマシングループに適用されていることを確認します。
- 収集エラーを確認 Logtail が正しく設定されていれば、ログファイルに新しいデータがリアルタイムに生成されているかどうかを確認します。Logtail は増分データのみを収集し、インベントリファイルに更新がない場合、ファイルは読み込まれません。ログファイルに更新があっても、Log Service で更新を照会できない場合は、次の方法で問題を診断します。
-
収集エラーを診断
ログ収集エラーのクエリを参照し、Logtail から報告されたエラーをもとにトラブルシュートします。
-
Logtail のログを確認
クライアントログには、重大な INFO ログと WARNING および ERROR ログのすべてが含まれます。完全なエラーとリアルタイムのエラーは、以下のパスで確認します。
- Linux: /usr/local/ilogtail/ilogtail.LOG
- Linux: /usr/local/ilogtail/logtail_plugin.LOG (logs of input sources such as HTTP,MySQL binlog, and MySQL query results)
- Windows x64: C:\Program Files (x86)\Alibaba\Logtail\logtail_*.log
- Windows x32: C:\Program Files\Alibaba\Logtail\logtail_*.log
-
使用量が上限を超えている
- 大量のログ、ファイル、またはデータを収集するには、Logtail の起動設定を変更してログ収集スループットを上げます。 詳細については、Logtail 起動設定パラメーターをご参照ください。
問題が解決しない場合は、チケットを起票し、サポートセンターにお問い合わせください。その際、トラブルシューティング中に収集したキー情報を添付してください。
ネットワークタイプ変更後の Logtail 設定の更新有無
ネットワークのタイプをクラシックネットワークから VPC に変更した場合は、Logtail を再起動し、Logtail マシングループの設定を更新する必要があります。
Logtail のインストール後に、ECS ネットワークタイプをクラシックネットワークから VPC に変更した場合、次の手順で Logtail 設定を更新します。- 管理者権限を有するユーザーで Logtail を再起動
- Linux :
sudo /etc/init.d/ilogtaild stopsudo /etc/init.d/ilogtaild start
- Windows :
コントロールパネルより、システムとセキュリティ > 管理ツールを順にクリックします。 サービスプログラムを開き、LogtailWorker ファイルを右クリックし、メニューより再起動をクリックします。
- Linux :
- マシングループ設定の更新
- カスタム ID
マシングループにカスタム ID を設定している場合は、マシングループの設定を変更する必要はありません。引き続き VPC にアクセスできます。 - IP アドレス
マシングループに ECS サーバーの IP アドレスを設定している場合は、Logtail を再起動し、app_info.json ファイルの ip フィールドを、取得されたマシングループの IP アドレスに置き換えます。
app_info.json ファイルの保管場所は、次のとおりです。- Linux : /usr/local/ilogtail/app_info.json
- Windows x64 : C:\Program Files (x86)\Alibaba\Logtail\app_info.json
- Windows x 32 : C:\Program Files\Alibaba\Logtail\app_info.json
- カスタム ID
-
収集エラーを診断