Log Service

プロダクト紹介

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、ストリーム処理、モニタリングとアラーム、機械学習、反復計算。

ETL、ストリーム処理、モニタリングとアラーム、機械学習、反復計算

LogShipper

安定した信頼性の高いログ送信 (shipping) により、 LogHub のデータはストレージサービスに送信、格納され、ビッグデータを分析できます。。 圧縮、カスタム化パーティション、行ストレージ、列ストレージといったさまざまなストレージ方法に対応しています。

目的:

データウェアハウス+ データ分析、モニタリング、推奨システム、ユーザープロファイリング

データウェアハウス+ データ分析、モニタリング、推奨システム、ユーザープロファイリング

リアルタイムに照会/分析(照会/分析)

リアルタイムにデータのインデックスが作成され、照会、分析できます。

  • クエリ: キーワード検索、あいまい検索、コンテキスト検索、および範囲検索
  • 統計: SQL 集約といった豊富なクエリ方法
  • 視覚化: ダッシュボードおよびレポート機能
  • 相互接続: Grafana および JDBC/SQL9
目的:

DevOps /オンライン O&M 、リアルタイムなログデータ分析、セキュリティ診断と分析、運用とカスタマーサービスシステム

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.データの収集と処理

図1.データの収集と処理

ETL/ストリーム処理

LogHub は、あらゆるリアルタイム処理サービスと組み合わせることができます。進捗モニタリングとアラーム機能を完備しており、SDK/API でカスタマイズ処理できます。

  • 簡単な操作性: さまざまな SDK とプログラミングフレームワークが用意されており、シームレスにさまざまなストリーム処理エンジンと連携できます。
  • 機能が豊富: さまざまなモニタリングデータ、アラーム機能が用意されています。
  • 柔軟な拡張性: 遅延なしに PB 単位に拡張できます。

図2.データクリーニングとストリーム処理

図2.データクリーニングとストリーム処理

データウェアハウス

LogShipper により、LogHub 内のデータがストレージサービスに送信 (ship) されます。圧縮、カスタム化シャード、行ストレージ、列ストレージといったあらゆるストレージ形式に対応します。

  • 大量のデータ: データ量に上限なし
  • 豊富なストレージ形式: 行ストレージ、列ストレージ、TextFile といった、さまざまなストレージ形式に対応
  • 柔軟に設定: シャードのカスタム化といった設定が可能

図3.データウェアハウスにドッキング

図3.データウェアハウスにドッキング

ログをリアルタイムに照会/分析

LogAnalytics は、LogHub のデータをリアルタイムにインデックスが作成され、キーワード検索、あいまい検索、コンテキスト、範囲指定、SQL 集約といったクエリが豊富に用意されています。

  • 高性能にリアルタイム: データが書き込まれたと同時にクエリ可能
  • 大容量で低コスト: PB/日でインデックスが作成され、独自開発する場合と比較して 15 % 割安
  • 高度に分析: あらゆるクエリが行えます。また、視覚化とアラーム通知機能が用意されています。

図4.リアルタイムなログ照会/分析

図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
  • Alibaba Cloud アカウントに、AccessKey (AK) がありません。
  • Logtail クライアントより Log Service サーバーに接続できないか、通信状態に問題があります。
  • サーバーの容量不足により、書き込みに失敗します。
  • Alibaba Cloud アカウントで AK を作成します。
  • ローカルの設定ファイル「/usr/local/ilogtail/ilogtail_config.json」を確認します。curl<endpoint>を実行し、その実行結果を確認します。
  • Logstore のシャード数を増やして、Logstore にデータを書き込むことができるようにします。
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 時間経過しており、ログの期限が切れています。 考えられる原因は次のとおりです。
  • ログの解析に 12 時間以上の遅れが生じている
  • 時間フィールドの設定が正しくない
  • ログ記録プログラムの時間が正しくない
  • READ_LOG_DELAY_ALARM エラーが発生していないか確認します。 READ_LOG_DELAY_ALARM エラーが発生している場合は、当該エラーの処理方法をご参照ください。発生していない場合は、時間フィールドの設定を確認します。
  • 時間フィールドの設定を確認します。時間フィールドの設定に間違いがない場合は、ログ記録プログラムの時間に間違いがないか確認します。
上記以外の場合は、チケットを起票し、サポートセンターにお問い合わせください。
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 cannot find key: 構成に SourceKey は指定されているが、ログには当該フィールドがない
  • anchor no start: Start に該当するコンテンツが SourceKey 値に含まれない
  • anchor no stop: Stop に該当するコンテンツが SourceKey 値に含まれない
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 は標準出力収集の初期化に失敗しました。 エラーメッセージをクリックして詳細を確認します。エラーが次のいずれかに該当しないか確認します。
  • host ... version ... error: 設定に指定している Docker エンジンにアクセスできるかどうかを確認します。
  • load checkpoint error: エラーがチェックポイントの読み取りに失敗しているため、影響がない場合、本エラーは無視して構いません。
  • container ...: label の値には、stdout (標準出力) または stderr (標準エラー出力) を指定します。 コンテナの label に無効な値が指定されているためにエラーが発生しています。エラーの詳細を基にエラーを処理します。
DOCKER_STDOUT_START_ALARM Docker の標準出力 (stdout) 収集の初期化時に、stdout のファイルサイズが上限を超えました。 通常、最初の収集時に stdout ファイルは既に存在するため、エラーを無視して構いません。
DOCKER_STDOUT_STAT_ALARM Docker stdout プラグインは stdout ファイルの確認に失敗しました。 エラーは無視して構いません。コンテナが停止しているために、コンテナによる標準出力ファイルへのアクセスが失敗しています。
FILE_READER_EXCEED_ALARM Logtail によって開かれているファイル数が上限を超えました。 設定内容が適切かどうかを確認します。収集されているファイル数が多すぎる場合に発生するエラーです。
GEOIP_ALARM geoip プラグインに問題があります。 エラーメッセージをクリックして詳細を確認します。詳細には、次のいずれかに該当しないか確認します。
  • invalid ip ...: プラグインは IP アドレスの取得に失敗しました。 設定の SourceKey が適切かどうか、また、無効なログがないかどうかを確認します。
  • parse ip ...: プラグインは取得した IP アドレスからの都市情報の特定に失敗しました。 エラーメッセージに従ってエラーを処理します。
  • cannot find key...: プラグインはログに指定されている SourceKey の特定に失敗しました。 設定に問題がないかどうか、また、無効なログがないかどうかを確認します。
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 プラグインの起動中にエラーが発生しました。 エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。
  • init tls error ...: TLS の設定が適切かどうか確認します。
  • listen init error ...: アドレスの設定が適切かどうか確認します。
LZ4_COMPRESS_FAIL_ALARM Logtail による LZ4 圧縮の際にエラーが発生しました。 エラーメッセージをクリックして詳細を表示し、ログフィールドの値、プロジェクト、カテゴリ、およびリージョンを基にエラーを対処します。
MYSQL_CHECKPOINT_ALARM MySQL プラグインでチェックポイントエラーが発生しました。 エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。
  • init checkpoint error ...: チェックポイントの初期化に失敗しました。 設定に指定されているチェックポイントカラムとその値が正しいかどうかを確認します。
  • not matched checkpoint ...: チェックポイント情報が一致しません。 手動更新 (たとえば、設定の更新) が原因で不一致を起きていないかどうかを確認します。手動更新のために不一致が起きている場合は、エラーを無視します。
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 プラグインがログの解析に失敗しました。 エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。
  • docker line parse error: 空の行: ログがありません。
  • parse json docker line error ...: プラグインは JSON 形式のログを解析できません。 エラーメッセージおよびログの最初の 512バイトを基にエラーを対処します。
  • parse cri docker line error ...: プラグインは CRI 形式のログを解析できません。 エラーメッセージおよびログの最初の 512 バイトを基にエラーを対処します。
PLUGIN_ALARM プラグインの初期化または呼び出しにエラーが発生しました。 エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。 適切にエラーを対処します。
  • init plugin error ...: プラグインの起動に失敗
  • hold on error...: プラグインの停止に失敗
  • resume error...: プラグインの再起動に失敗
  • start service error...: サービス input-type プラグインの起動に失敗
  • stop service error...: サービス input-type プラグインの停止に失敗
PROCESSOR_INIT_ALARM 正規表現プラグインが、設定に指定された正規表現のコンパイルに失敗しました。 エラーメッセージをクリックして詳細を表示し、正規表現が適切かどうか確認します。
PROCESS_TOO_SLOW_ALARM Logtail のログ解析に時間がかかり過ぎています。
  1. エラーメッセージをクリックして詳細を表示します。ログの数、バッファサイズ、および解析時間より、解析時間に問題がないかどうか確認します。
  2. 解析処理に時間がかかり過ぎている場合は、解析設定が不適切でないかどうか確認します。 たとえば、Logtail 処理にノードの CPU リソースが異常に占有されていないか、また、非効率な正規表現がないかを確認します。
REDIS_PARSE_ADDRESS_ALARM Redis プラグインは、設定に指定されている ServerUrls の解析に失敗しました。 エラーメッセージをクリックして詳細を表示し、URL を確認します。
REGEX_FIND_ALARM 正規表現プラグインは、ログ内に、SourceKey として指定されているフィールドを特定できませんでした。 エラーメッセージをクリックして詳細を表示し、SourceKey に間違いがないかどうか、また無効なログが存在しないかどうかを確認します。
REGEX_UNMATCHED_ALARM プラグインの正規表現が、ログのパターンと一致しません。 エラーメッセージをクリックして詳細を表示します。エラーの詳細は、次のいずれかに該当します。 設定が正しいかどうか確認し、適切にエラーを対処します。
  • unmatch this log content...: ログのパターンと、設定した正規表現とが一致しません。
  • match result count less ...: パターン一致したログの数が、Keys に指定されている数より少ない。
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 経由でのデータ収集時にエラーが発生しました。 エラーメッセージをクリックして詳細を表示します。エラーの内容は次のいずれかに該当します。 適切にエラーを処理します。
  • accept error...: 接続受け付け処理中にエラーが発生しました。 しばらくの待機後、プラグインは再起動します。
  • setKeepAlive error ...: キープアライブの設定に失敗しました。 プラグインはエラーを無視し、処理は続行されます。
  • connection I / o timeout ...: TCP 経由のデータ読み込み期限が終了しています。 プラグインによって期限は更新され、データは適切に読み込まれます。
  • scan error...: プラグインによる TCP 経由でのデータ読み込みにエラーが発生しました。 しばらくの待機後、プラグインによって再試行されます。
SERVICE_SYSLOG_PACKET_ALARM service_syslog プラグインの UDP 経由のデータ収集にエラーが発生しました。 エラーメッセージをクリックして詳細を表示します。次のいずれかに該当しないか確認します。 適切にエラーを処理します。
  • connection i/o timeout ...: UDP 経由のデータ読み込み期限が終了しています。 プラグインによって有効期限は更新され、適切にデータが読み込まれます。
  • read from error...: プラグインによる UDP 経由のデータ読み込みにエラーが発生しました。 しばらくの待機後、プラグインによって再試行されます。

収集エラーをトラブルシュート

Logtail でのログ収集に失敗、また、収集が異常ステータスの場合、次の手順に従ってエラーをトラブルシュートします。

手順

  1. マシングループの Logtail のハートビートが正常であるかどうかを確認 Log Service コンソールにログオンし、マシンステータスをクリックして、マシングループのステータスを確認します。詳細は、マシングループの管理をご参照ください。 ハートビートが正常ステータスであれば、次のステップへ進みます。

    ハートビートが失敗ステータスの場合、Logtail ハートビートエラーのトラブルシューティングをご参照ください。

  2. 収集の構成情報が作成され、マシングループに適用されているかどうかを確認 Logtail クライアントが正常ステータスであることを確認できた場合、以下を確認します。
    1. Logtail の構成情報が作成されているかどうか 詳細は、Logtail の構成情報をご参照ください。ログモニタリングのディレクトリおよびログファイル名が、マシン上のファイルと相違ないことを確認します。ディレクトリにはワイルドカードを使用することができないため、絶対パスを指定します。ログファイル名にワイルドカードを使用することはできます。
    2. マシングループに Logtail 設定が適用されているかどうか マシングループの管理の構成情報の管理を確認します。構成がマシングループに適用されていることを確認します。
  3. 収集エラーを確認 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 設定を更新します。

    1. 管理者権限を有するユーザーで Logtail を再起動
      • Linux :
        1. sudo /etc/init.d/ilogtaild stop
        2. sudo /etc/init.d/ilogtaild start
      • Windows :
        コントロールパネルより、システムとセキュリティ > 管理ツールを順にクリックします。 サービスプログラムを開き、LogtailWorker ファイルを右クリックし、メニューより再起動をクリックします。
    2. マシングループ設定の更新
      • カスタム 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