web-dev-qa-db-ja.com

CloudWatchログの動作がおかしい

複数行のログステートメントを含む2つのログファイルがあります。どちらも、各ログステートメントの先頭で同じ日時形式になっています。構成は次のようになります。

state_file = /var/lib/awslogs/agent-state

[/opt/logdir/log1.0]
datetime_format = %Y-%m-%d %H:%M:%S
file = /opt/logdir/log1.0
log_stream_name = /opt/logdir/logs/log1.0
initial_position = start_of_file
multi_line_start_pattern = {datetime_format}
log_group_name = my.log.group


[/opt/logdir/log2-console.log]
datetime_format = %Y-%m-%d %H:%M:%S
file = /opt/logdir/log2-console.log
log_stream_name = /opt/logdir/log2-console.log
initial_position = start_of_file
multi_line_start_pattern = {datetime_format}
log_group_name = my.log.group

Cloudwatch logsエージェントはlog1.0ログをcloudwatchのロググループに正しく送信していますが、log2-console.logのログファイルを送信していません。

awslogs.logによると:

2016-11-15 08:11:41,308 - cwlogs.Push.batch - WARNING - 3593 - Thread-4 - Skip event: {'timestamp': 1479196444000, 'start_position': 42330916L, 'end_position': 42331504L}, reason: timestamp is more than 2 hours in future.
2016-11-15 08:11:41,308 - cwlogs.Push.batch - WARNING - 3593 - Thread-4 - Skip event: {'timestamp': 1479196451000, 'start_position': 42331504L, 'end_position': 42332092L}, reason: timestamp is more than 2 hours in future.

サーバーの時間は正しいですが。また、奇妙なことに、start_positionに記載されている行番号と、プッシュされている実際のログファイルにend_positionが存在しません。

この問題を経験している人は他にいますか?

9
Furhan S.

私はこれを修正することができました。

Awslogsの状態が壊れていました。状態は、/ var/awslogs/state/agent-stateのsqliteデータベースに保存されます。あなたはそれを介してアクセスすることができます

Sudo sqlite3 /var/awslogs/state/agent-state

書き込みアクセスにはSudoが必要です。

すべてのストリームを

select * from stream_state;

ログストリームを検索し、v列のjsonデータ構造の一部であるsource_idに注意してください。

次に、このsource_id(私の場合は7675f84405fcb8fe5b6bb14eaa0c4bfd)を持つすべてのレコードをPush_stateテーブルにリストします。

select * from Push_state where k="7675f84405fcb8fe5b6bb14eaa0c4bfd";

結果のレコードのv列には、batch_timestampを含むjsonデータ構造があります。そして、このbatch_timestampの継ぎ目は間違っています。それは過去のものであり、新しい(2時間以上)ログエントリは処理されなくなりました。

解決策は、このレコードを更新することです。 v列をコピーし、batch_timestampを現在のタイムスタンプに置き換え、次のように更新します。

update Push_state set v='... insert new value here ...' where k='7675f84405fcb8fe5b6bb14eaa0c4bfd';

でサービスを再起動します

Sudo /etc/init.d/awslogs restart

私はそれがあなたのために働くことを願っています!

14

同じ問題が発生し、次の手順で問題が修正されました。

ロググループが最新のイベントで更新されていない場合:次の手順を実行します。

  1. Awslogsサービスを停止しました
  2. 削除されたファイル/ var/awslogs/state/agent-state
  3. 更新/ var/awslogs/etc/awslogs.conf hostanameからインスタンスIDへの構成例:

    log_stream_name = {hostname} to log_stream_name = {instance_id}   
    
  4. Awslogsサービスを開始しました。
2

私はAmazonLinuxでこの問題を次の方法で解決することができました:

  1. Sudoyumはawslogsを再インストールします
  2. Sudoサービスのawslogが再起動します

この方法では、構成ファイルを/ var/awslogs /に保持しましたが、再インストールする前にバックアップすることをお勧めします。

注:トラブルシューティングでは、AWSコンソールからLog Groupも削除しました。再起動により、すべての履歴ログが完全に再ロードされましたが、現在のタイムスタンプでは価値が低くなっています。ロググループを削除することが、このメソッドが機能するために必要だったかどうかはわかりません。再起動する前に、 initial_position configをend_of_fileに設定することを検討してください。

0
johnsampson