5

我有兩個包含多行日誌語句的日誌文件。他們兩個在每個日誌語句的開頭都有相同的日期時間格式。配置是這樣的:CloudWatch日誌表現怪異

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的日誌代理正確發送log1.0日誌我的日誌組對CloudWatch的,然而,它不發送日誌文件的log 2-的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在實際的日誌文件被推入時不存在。

任何其他人遇到此問題?

+0

我有同樣的效果,仍然在尋找解決方案。重新啓動服務沒有幫助。 BTW:start_position和end_position不是行號,而是字節位置。 –

回答

8

我能解決這個問題。

awslogs狀態被打破。狀態存儲在/ var/awslogs/state/agent-state中的sqlite數據庫中。您可以通過

sudo sqlite3 /var/awslogs/state/agent-state 

sudo需要寫入權限。

列出所有與

select * from stream_state; 

流查一查你的日誌流,並注意SOURCE_ID這是在V列中的JSON數據結構的一部分。

然後列出這個SOURCE_ID所有記錄(在我的情況下,它是7675f84405fcb8fe5b6bb14eaa0c4bfd)在push_state

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

所得記錄在其中包含batch_timestamp在V列中的JSON數據結構。而這個batch_timestamp接縫是錯誤的。它在過去,任何更新(超過2小時)的日誌條目都不再被處理。

解決方法是更新此記錄。複製V色譜柱,與當前的時間戳和更新的東西與

sudo /etc/init.d/awslogs restart 

我希望它爲你更換batch_timestamp像

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

重新啓動該服務!

+0

在我的情況下,push_state表是空的 - 我該怎麼辦? – Andrey

+0

但是,您會收到警告「...原因:未來時間戳超過2小時」。使用「sudo /etc/init.d/awslogs restart」重新啓動服務? –

+0

嘿,你有什麼辦法強制重置cloudwatch日誌?看起來我在幾臺機器上遇到了這個問題,而且我無法真正負擔登錄到每臺機器並執行每個實例。我很抱歉丟失了以前的非同步日誌。當發生這樣的問題時,我的磁盤空間似乎每小時都會填充1GB,所以我的Web服務只是在一夜之間死掉...... –

0

我們遇到了同樣的問題,以下步驟解決了問題。 執行這些步驟:

如果日誌組不與最近發生的事件更新

  1. 停止awslogs服務
  2. 刪除的文件在/ var/awslogs /國家/劑狀態
  3. 更新了/var/awslogs/etc/awslogs。CONF從hostaname配置 實例ID例如:

    log_stream_name = {hostname} to log_stream_name = {instance_id} 
    
  4. 發起者awslogs服務。
0

我能夠解決在Amazon Linux的這個問題:

  1. 須藤yum的重裝awslogs
  2. sudo的服務awslogs重啓

這種方法保留在/ var我的配置文件/ awslogs /,儘管您可能希望在重新安裝前備份它們。

注意:在我的疑難解答中,我還通過AWS控制檯刪除了我的Log Group。重新啓動完全重新加載所有歷史日誌,但是在當前時間戳處,這是較不值的。我不確定是否刪除日誌組是這種方法工作所必需的。在重新啓動之前,您可能需要考慮將initial_position配置設置爲end_of_file