Dzienniki CloudWatch działa dziwnie

Question

Mam dwa pliki dziennika z wieloliniowych wyciągów dziennika. Oba mają ten sam format datetime na początku każdej instrukcji dziennika. Konfiguracja wygląda następująco:

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 

Środek kłody cloudwatch wysyła logi log1.0 poprawnie do mojej grupy dziennika na cloudwatch jednak jej nie wysyłanie logów na log2-console.log.

awslogs.log mówi:

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. 

Choć czas serwera jest poprawna. Również dziwne jest to, że numery linii wspomniane w parametrze start_position i end_position nie istnieją w aktualnie przesyłanym pliku dziennika.

Ktoś inny doświadcza tego problemu?

Answer 1

Udało mi się to naprawić.

Stan awsloga został zerwany. Stan jest przechowywany w bazie danych sqlite w/var/awslogs/state/agent-state. Możesz uzyskać do niego dostęp poprzez

sudo jest potrzebny do uzyskania dostępu do zapisu.

Lista wszystkich strumieni z

select * from stream_state; 

Sprawdzić swój strumień dziennika i pamiętać, że SOURCE_ID który jest częścią struktury danych json w kolumnie v.

Następnie wypisz wszystkie rekordy z tym SOURCE_ID (w moim przypadku było 7675f84405fcb8fe5b6bb14eaa0c4bfd) w push_state tabeli

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

Powstała płyta ma strukturę danych json w kolumnie V, który zawiera batch_timestamp. I ten batch_timestamp szwankuje. To było w przeszłości, a wszelkie nowsze (ponad 2 godziny) wpisy w dzienniku nie były już przetwarzane.

Rozwiązaniem jest aktualizacja tego rekordu. Skopiować kolumnę V, wymienić batch_timestamp z bieżącego datownika i aktualizacji z czymś jak

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

ponownie uruchomić usługę z

sudo /etc/init.d/awslogs restart 

Mam nadzieję, że pracuje dla Ciebie!

Answer 2

Wystąpił ten sam problem, a kolejne kroki rozwiązały problem.

Jeżeli grupy dziennika nie aktualizujesz z najnowszych wydarzeń: Run kroki:

1. Zatrzymano usługę awslogs
2. Usunięty plik /var/awslogs/state/Agent-state

3. Zaktualizowano /var/awslogs/etc/awslogs.conf konfiguracji z hostaname do np ID EX:

   log_stream_name = {hostname} to log_stream_name = {instance_id} 
   

4. kroki awslogs usługi.

Answer 3

udało mi się rozwiązać ten problem na Amazon Linux przez:

1. sudo yum ponowna awslogs
awslogs usługowa
2. sudo restart

Metoda ta zachowała swoje pliki konfiguracyjne w katalogu/var/awslogs /, chociaż możesz je wykonać przed ponowną instalacją.

Uwaga: Podczas rozwiązywania problemów usunęłem również Log Group za pośrednictwem konsoli AWS. Restart całkowicie przeładował wszystkie dzienniki historyczne, ale przy obecnym znaczniku czasu, który ma mniejszą wartość. Nie jestem pewien, czy usunięcie Log Group było konieczne, aby ta metoda działała. Przed ponownym uruchomieniem warto sprawdzić konfigurację initial_position na end_of_file.