☰

먼저 부패(탐지에 의한 부패)에 대해 이야기해보자 journalctl --verify.

tag-icon • tag-icon systemd
먼저 부패(탐지에 의한 부패)에 대해 이야기해보자 journalctl --verify.

오늘 CPU 사용률이 100%인 서버 문제가 발생했습니다. 서버를 다시 되찾기 위해 하드 리셋을 해야 했고, 지금은 높은 부하의 원인을 파악하려고 노력 중입니다.

불행히도 Journalctl은 다시 시작될 때까지 로그 정보를 표시하지 않습니다. 이렇게 했는데 journalctl --verify손상된 파일이 표시되었습니다. 이것이 문제와 관련이 있다고 가정하고 있는데, 손상되기 전의 로그를 어떻게 볼 수 있습니까? journalctl --since yesterday이틀 전부터 시도했지만 여전히 성공하지 못했습니다.

답변1

비교적 작은 로그 파티션을 만들어 옵션 및 마운트 경로에 추가해 보세요 /etc/fstab.sync/var/log

...<previos fstab lines>...
UUID=<UUID of created partition>  /var/log  ext4  rw,sync  0  0

이렇게 하면 시스템이 쓰기를 캐시하지 않고 블록 장치에 직접 로그를 쓰게 되므로 로그 메시지는 발생하는 대로 기록되며 재부팅 시 삭제되지 않습니다. 그러나 동기식 로그 쓰기는 IO 집약적일 수 있으며 프로덕션 서버에서 장기간 사용하는 데 적합하지 않다는 점을 염두에 두십시오.

답변2

먼저 부패(탐지에 의한 부패)에 대해 이야기해보자 journalctl --verify.

디스크 형식에 중복성이 없다는 점에서 로그의 손상은 복구할 수 없습니다. 또한 어떤 경우에는 파일 중간의 손상으로 인해 "꼬리"를 읽을 수 없게 됩니다(실제로는 또 다른 주제입니다). 그러나 journald비정상 종료의 로그 파일은 절대 기록되어서는 안 되므로 비정상 종료로 인한 피해는 무해합니다.

그러나 이것은 실제로 관련이 없습니다.

마지막 시작 로그를 보는 데 사용할 수 있습니다 journalctl -b -1.

귀하의 경우 문제는 블록 I/O가 일반적으로 후기입 캐시되기 때문에 하드웨어가 재설정될 때까지 마지막 N 항목을 볼 수 없다는 것입니다. I/O를 동기화하는 것 외에는 할 수 있는 일이 많지 않습니다.

관련 정보