ZO

저자 : 존크럼볼츠,라이언바비노
독서일자 :  2024.01.21 ~ 2025.02.25

어느 날 유튜브를 보다가 숏츠 알고리즘에서 '게으른 완벽주의자'라는 개념을 소개하는 영상을 보게 되었다.

흥미로운 이야기였기에 영상을 끝까지 시청했는데, 그 내용이 꼭 나를 묘사하는 것처럼 느껴졌다. 알고 보니 이 숏츠는 '빠르게 실패하기'(개정판: '더 빠르게 실패하기')라는 책의 내용을 기반으로 만들어진 것이었다. 그래서 더욱 관심이 생겨 책을 구매해 읽어보았다.

'게으른 완벽주의자'라는 표현을 보면 '완벽주의자'라는 단어 때문에 긍정적인 느낌이 들 수도 있다. 하지만 실제 의미는 조금 다르다. 완벽을 기하기 위해 더 준비해야 한다는 핑계를 대거나, 내가 아직 부족하다는 생각을 이유로 도전을 미루는 사람들을 가리킨다. 결국, 두려움이 앞서는 일에 대해 자기합리화를 하며 회피하는 것이다.

물론 누구나 그런 경험이 있을 것이다. 새로운 프로젝트나 미래에 대한 불확실성이 크면 자연스럽게 두려움을 느끼고, 그 상황을 피하고 싶어지기 마련이다. 하지만 이 책에서는 그러한 감정을 이겨내고 작은 것부터 도전해보라고 말한다. 작은 시도를 통해 작은 실패나 작은 성취를 경험하며 점차 성장하고, 궁극적으로 성공에 이를 수 있다는 메시지를 전한다.

이 책은 마치 내 이야기를 하고 있는 것 같았다. 그래서 처음으로 연속해서 두 번 읽었다. 그리고 읽을수록 나 또한 새로운 도전 앞에서 '게으른 완벽주의자'처럼 여러 가지 핑계를 대며 회피하고 있지는 않은가 하는 생각이 들었다.

이제는 고민만 하는 게 아니라, 책에서 배운 대로 작은 것부터 실천하며 변화를 만들어가야겠다고 다짐했다.

0. 개요

기존 모니터링인 Nagios에서 시스템 메트릭 모니터링을 하기 위하여 Prometheus+Grafana+NodeExporter로

내부 서버 모니터링을 시작했습니다. 온프레미스 장비들에 node_exporter 설치 후 시스템 메트릭을 수집하는 도중, /var/log/messages에 다음과 같은 ACPI 관련 커널 오류가 발생하는것을 확인 할 수 있었습니다.  

ACPI Error: SMBus or IPMI write requires Buffer of length 66, found length 32 (20090903/exfield-286)

이 오류는 ACPI(Advanced Configuration and Power Interface)와 관련된 SMBus(System Management Bus) 또는 IPMI(Intelligent Platform Management Interface) 요청 중 버퍼 길이 불일치로 인해 발생합니다. 

1. 문제원인 

Node Exporter가 /sys/class/hwmon 경로에서 하드웨어 센서 값을 수집할 때 일부 하드웨어 플랫폼 또는 펌웨어가 이러한 쿼리를 완벽하게 지원하지 못하여 커널 오류가 발생합니다. 주로 펌웨어버젼이 낮을경우에 발생합니다.

2. 해결방법

이 문제를 해결하려면 Node Exporter에서 하드웨어 모니터링(hwmon) 수집기를 비활성화해야 합니다.

1) node_exporter 서비스파일 수정

1. Node_exporter 서비스 파일 오픈

sudo vi /etc/systemd/system/node_exporter.service

2. ExecStart 라인을 찾아 다음과 같이 --no-collector.hwmon 옵션을 추가합니다:

ExecStart=/usr/local/bin/node_exporter --no-collector.hwmon

만약 Centos6와 같은 구버젼의 Daemon파일은 아래와 같은절차로 진행합니다.

1. Node_exporter 데몬파일 오픈

vi /etc/init.d/node_exporter

2. start 함수에  --no-collector.hwmon 설정 추가

start(){
	echo -n"Starting $PROGNAME: "
    cd /usr/shared/node_exporter/
    daemon --user $USER --pidfile="$LOCKFILE" "$PROG --no-collector.hwmon &>$LOGFILE &"
    echo $(pidofproc $PROGNAME) >$LOCKFILE
    echo
}

2) 서비스 리로드 및 재시작

1. systemd 데몬을 리로드하여 변경사항을 적용합니다.

sudo systemctl daemon-reload

2. node_exporter 서비스를 재시작 합니다.

sudo systemctl restart node_exporter

위 작업 진행 후 더이상 /var/log/messgaes에 관련 로그가 발생하지 않습니다.

3. 결론

Node Exporter에서 hwmon 수집기를 비활성화하여 과도한 로그 발생을 방지했습니다. 하드웨어 센서 모니터링이 비활성화되는 단점이 있지만, ACPI 상호작용이 Node Exporter와 호환되지 않는 시스템에서는 실용적인 해결책입니다.

저자 : 유발하라리
독서일자 :  2024.11.01 ~ 2025.01.10

한동안 책을 안 읽다가 다시 읽게 되었는데, 여러 책을 고민하던 중 회사 임원분께서 추천해 주신 사피엔스라는 책을 읽기 시작했다. 인류학을 주제로 쓰인 책인데 흥미로운 부분도 있지만 이해하기 어려운 부분이 있어 독서하는 시간이 생각보다 오래 걸린듯하다.  전체적으로 읽어보니 인류가 어떻게 발전해 왔는지 즉, 유인원부터 현재까지 이르기에 있었던 역사적인 사건, 사고등을 한 번에 볼 수 있어 좋았다. 다양한 역사에 대해 알게 되니 식견이 좀 넓어진 느낌이다.

이 책도 국가란 무엇인가와 똑같이 독서 능력이 지금보다 더 향상된다면 다시 한번 정독해보고싶은 책이다.

내용 중 흥미로웠던 주제는 호모사피엔스(우리)가 세상을 지배 할수있었던건 협동을 할 수 있는 존재이기 때문이며 이와 같은 협동을 가능케 하는 건 상상 속에 있는 신, 국가, 종교, 정치체제 등 허구를 믿을 수 있는 독특한 능력 때문이라고 한다. 국가, 종교, 정치체제와 같은 건 허구라는 관점으로 바라보는 시각이 독특하다고 생각했는데, 다시 한번 고민해 보니, 실제 하지 않는 허구가 맞다고 생각이 든다. 신, 국가, 종교, 정치체제와 같은 것들은 실존하지 않으며, 사람들의 생각으로 정의되는 것이니까.

대다수의 사람들은 신은 모르겠지만, 국가, 종교와 같은걸 허구라는 생각조차 하지 않았을까.

우리는 이미 그곳에 소속되어있거나, 소속되어 있는 사람들을 보았으니까 

ps. 임원분추천으로 읽은책이였는데, 이 책도 페이커 추천도서 중 한 권이었다.  

0. 들어가며

ElasticStack을 구축하며 beat와 logstash를 연동하여 운영하는데, beat를 통해 데이터를 수집하는 서버에서 아래 이미지와 같은 에러가 지속적으로 발생함을 알수있었다.

해당 글은 지속적으로 발생하는 해당 에러를 조치하는 방안을 작성한 글이다.

1. 원인 파악

원인을 파악하기 위해 클라이언트(beat)에서 로그스태시로 telnet 접속시도를 했는데 정상적으로 커넥션이 되는걸 확인할 수 있었다. 즉 통신에는 문제가 없음을 확인하였고, 로그를 확인해보니 내용에 나와있는 connection reset by peer의 경우 클라이언트가 아닌 서버측에서 RST를 던져서 접속이 끊길때 발생하는 에러이기에, RST를 던진쪽이 서버(logstash)인지 

상단 또는 네트워크장비인지 확인을 하기위해 방화벽장비에서 패킷을 캡쳐하여 와이어샤크로 확인을해봤다.

 위 이미지와 서버내 tcpdump와 같은 추가적인 확인을 통해 서버(logstash)에서 RST를 던지고 있음을 확인하였고, 추가로 서버에서 통신을 끊는 이유를 확인하기 위하여 logstash에서  타임아웃관련 옵션을 공식 docs를 통해 확인해봤다.

Client_inactivity_timeout

위 공식 Docs 링크에 나와있듯이 logstash의 input plugin의 옵션중 client_inactivity_timeout이라는 옵션이 있으며,

해당 옵션은 클라이언트가 inactivity상태라면 X초후에 끊는다 라는 의미로 보인다.

* Close Idle clients after X seconds of inactivity.

기본값은 60초이므로 즉 예상하건데, beat에서 60초내에 데이터를 보내지않는다면 접속을 끊는다는 의미인거같다.

2. 해결방안

이미 위에 내용에서 예상했겠지만, 간단한 조치방법은 해당 옵션을 활성화 하여 알맞은 시간을 할당하는 방법이다. 필자는 타임아웃값을 30분(1800초)으로 줬으나, 만약 빈번하게 데이터흐름이 발생한다면 좀더시간을 줄여도 괜찮을듯하다.

vi /etc/logstash.conf


input {
  beats {
    port => 5044
    client_inactivity_timeout => 1800
  }
}
####중략######

0. 들어가며

Rocky OS를 운영하며 제목과 같은 에러가 주기적으로 /var/log/messages에 발생하는것을 확인 할 수 있었습니다.

해당 메시지는 crontab에 등록된 작업이 실패 할 경우에 다량으로 발생하는것을 확인하였는데,

이 글은 위에 대한 조치 방안에 대해서 작성하였습니다.

1. 발생 원인

cron은 기본적으로 작업 실행 결과에 대한 내용을 메일로 발송하게끔 구성되어있습니다.

이로 인해  crontab에서 시행한 결과를 발송하려했으나, 서버내에 메일에 대한 설정이 없을 경우에

제목과 같은 에러가 발생합니다.

2. 조치 방안

조치 방안은 크게 두가지 방안이 있습니다.

2-1) 메일 프로세스 설치

간단한 조치 방법으로 메일서버를 설치해주면 해당 에러는 더이상 발생하지 않습니다.

[root@test ~]# dnf install postfix

==============================================================================================================================================================================================================
 꾸러미                                          구조                                           버전                                                     저장소                                          크기
==============================================================================================================================================================================================================
설치 중:
 postfix                                         x86_64                                         2:3.5.8-7.el8                                            baseos                                         1.5 M

연결 요약
==============================================================================================================================================================================================================

2-2) crond mail disable

서버 용도, 환경에 따라 메일 서버 설치가 어려운 경우에 crond 실행 결과 메일 발송을 비활성화 할 수 있습니다. 

man crond 중에 -m 옵션에 대한 내용입니다.

[root@test ~]# man crond
##중략##
-m     This  option allows you to specify a shell command to use for sending Cron mail output instead of using sendmail(8) This command must accept a fully formatted mail message (with headers)
              on standard input and send it as a mail message to the recipients specified in the mail headers.  Specifying the string off (i.e., crond -m off) will disable the sending of mail.

뒤에 내용을 보면 -m off를 통해 크론메일전송을 비활성화 할 수 있다는 내용이 있습니다.

아래와 같이 설정 및 재기동 해줍니다.

[root@test ~]# vi /etc/sysconfig/crond

# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS="-m off"

[root@test ~]# systemctl restart crond