Надежная проверка журнала wget на наличие ошибок с помощью grep или ack - PullRequest
Новая
       66

Надежная проверка журнала wget на наличие ошибок с помощью grep или ack

2 голосов
/ 01 июня 2019

В bash-файле у меня есть logfileA.txt, который содержит выходные данные из wget, которые я хотел бы запустить grep, чтобы проверить наличие любых слов "error" или "fail" и т. Д., Как так: 

grep -ni --color=never -e "error" -e "fail" logfileA.txt | awk -F: '{print "Line "$1": "$2}'
# grep -n line number, -i ignore case; awk to add better format to the line numbers (https://stackoverflow.com/questions/3968103)

Проблема в том, что я думаю, что вывод wget в logfileA.txt полон символов, которые могут испортить ввод для grep, поскольку я не получаю надежных совпадений.

Устранение неполадок, я даже не могу cat содержимое файла журнала надежно. Например, с cat logfileA.txt все, что я получаю, это последняя строка, которая искажается: 

FINISHED --2019-05-29 17:08:52--me@here:/home/n$ 71913592/3871913592]atmed out). Retrying.

Содержимое logfileA.txt: 

--2019-05-29 15:26:50--  http://somesite.com/somepath/a0_FooBar/BarFile.dat
Reusing existing connection to somesite.com:80.
HTTP request sent, awaiting response... 302 Found
Location: http://cdn.somesite.com/storage/a0_FooBar/BarFile.dat [following]
--2019-05-29 15:26:50--  http://cdn.somesite.com/storage/a0_FooBar/BarFile.dat
Resolving cdn.somesite.com (cdn.somesite.com)... xxx.xxx.xx.xx
Connecting to cdn.somesite.com (cdn.somesite.com)|xxx.xxx.xx.xx|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3871913592 (3.6G) [application/octet-stream]
Saving to: 'a0_FooBar/BarFile.dat’

a0_FooBar/BarFile.dat   0%[                    ]       0  --.-KB/s               
a0_FooBar/BarFile.dat   0%[                    ]  15.47K  70.5KB/s               
...
a0_FooBar/BarFile.dat  49%[========>           ]   1.80G  --.-KB/s    in 50m 32s 

2019-05-29 16:17:23 (622 KB/s) - Read error at byte 1931163840/3871913592 (Connection timed out). Retrying.

--2019-05-29 16:17:24--  (try: 2)  http://cdn.somesite.com/storage/a0_FooBar/BarFile.dat
Connecting to cdn.somesite.com (cdn.somesite.com)|xxx.xxx.xx.xx|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 3871913592 (3.6G), 1940749752 (1.8G) remaining [application/octet-stream]
Saving to: 'a0_FooBar/BarFile.dat’

a0_FooBar/BarFile.dat  49%[+++++++++           ]   1.80G  --.-KB/s               
...
a0_FooBar/BarFile.dat 100%[+++++++++==========>]   3.61G  1.09MB/s    in 34m 44s 

2019-05-29 16:52:09 (909 KB/s) - 'a0_FooBar/BarFile.dat’ saved [3871913592/3871913592]

FINISHED --2019-05-29 17:08:52--

Я предполагаю, что проблема может быть / с или --- с или > с или ==> с или | с?

Но поскольку выходные данные из wget могут отличаться, как мне ожидать и избегать чего-то проблемного для grep?

Команда: 

grep -ni --color=never -e "error" -e "fail" logfileA.txt | awk -F: '{print "Line "$1": "$2}'

Ожидаемый результат: 

Line 17: 2019-05-29 16:17:23 (622 KB/s) - Read error at byte 1931163840/3871913592 (Connection timed out). Retrying.

Кроме того, линия ack будет лучше на этой работе? И если да, то что / как?

1 Ответ

2 голосов
/ 01 июня 2019

Wrt I assume the problem could be the /s or ---s or >s or ==>s or |s? - нет, в этих символах / строках нет ничего особенного. Похоже, у вас могут быть окончания строки DOS (\r\n), см. Почему выходные данные моего инструмента перезаписываются и как это исправить? . Так как вы сказали with cat logfileA.txt, all I get is the last line which is garbled Интересно, у вас ТОЛЬКО \r с и нет \n с в качестве концов строк. Если вы сделаете это, tr '\r' '\n' < logfileA.txt > tmp && mv tmp logfileA.txt исправит это. Если это проблема, то в дальнейшем вы можете использовать awk -v RS='\r' 'script', чтобы изменить разделитель записей со стандартного \n на \r, и тогда вам не нужно будет делать этот шаг tr.

Вам не нужен grep, когда вы используете awk. Это: 

grep -ni --color=never -e "error" -e "fail" logfileA.txt |
    awk -F: '{print "Line "$1": "$2}'

можно записать так: 

awk 'tolower($0) ~ /error|fail/{print "Line "NR":"$0}' logfileA.txt

, но версия только для awk является более надежной, поскольку она будет правильно отображать полные строки, содержащие : s, где версия grep + awk урезает их до первой :.

Вы можете обработать окончания строки DOS, если таковые имеются, настроив скрипт на: 

awk 'tolower($0) ~ /error|fail/{sub(/\r$/,""); print "Line "NR":"$0}' logfileA.txt

и вы можете заставить его искать ошибку или ошибку как отдельные слова (в отличие от части других строк, таких как terror или failles), делая это с помощью GNU awk: 

awk -v IGNORECASE=1 -v RS='\r?\n' '/\<(error|fail)\>/{print "Line "NR":"$0}' logfileA.txt

или это с любым awk: 

awk 'tolower($0) ~ /(^|[^[:alnum:]_])(error|fail)([^[:alnum:]_]|$)/{sub(/\r$/,""); print "Line "NR":"$0}' logfileA.txt
...