특정 서비스를 재기동했는데 상태가 엇갈린다.
systemctl status sas-viya-sand-default -> active (running)
sas-viya 상태 확인 -> health check failed
not ready 로 남는 서비스도 함께 나온다. 화면과 OS 가 서로 다른 말을 하는 것처럼 보이지만 둘 다 맞는 말이다.
systemctl 은 프로세스가 살아 있는지만 본다. 자바 프로세스가 떠 있고 죽지 않았으면 active (running) 이다.
Viya 3.5 의 상태 표시는 그 위의 층을 본다. 서비스가 Consul 에 등록한 health check 가 통과했는지, 즉 자기 의존 대상과 통신이 되는지를 본다. 프로세스는 떴는데 붙어야 할 곳에 못 붙으면 active 이면서 health check failed 가 된다.
따라서 systemctl restart 를 반복하는 것으로는 풀리지 않는다. 무엇에 못 붙고 있는지를 찾아야 한다.
여러 서비스가 한꺼번에 실패로 보일 때, 대부분은 하나가 무너지고 나머지가 그 결과다. 뒤따라 실패한 쪽을 먼저 보면 시간만 쓴다.
백엔드 저장소 / 인증 계층
|
(붙지 못함)
v
1차 서비스 --> health check failed
|
v
그 서비스를 쓰는 서비스 --> not ready
먼저 실패 시각을 대조해 가장 먼저 무너진 것을 고른다.
journalctl -u 'sas-viya-*' --since '-2h' --no-pager | grep -i 'fail\|error\|refused'
Viya 3.5 의 서비스 로그는 두 곳에 있다.
journalctl -u sas-viya-<서비스>-default -n 200 --no-pager
ls -lt /opt/sas/viya/config/var/log/<서비스>/default/
로그에서 다음 패턴을 찾는다. 어느 쪽이 나오느냐에 따라 원인이 갈린다.
| 로그 패턴 | 원인 |
|---|---|
Connection refused, NoNodeAvailableException |
의존 대상이 떠 있지 않거나 포트가 막혔다 |
PKIX path building failed, SSLHandshakeException |
인증서 신뢰 실패. 최근 TLS 적용이나 호스트명 변경을 의심한다 |
UnknownHostException, 이름 해석 실패 |
DNS 또는 /etc/hosts 변경 |
Access denied, 인증 실패 |
자격 증명 만료나 계정 잠김 |
Timeout, 기동 중 멈춤 |
자원 부족. 힙과 디스크를 본다 |
서비스가 스스로 뭐라고 하는지 직접 물어보는 것이 가장 빠르다. 포트는 Consul 에 등록된 값이거나 서비스 설정에 있다.
curl -sk http://localhost:<포트>/health
curl -sk http://localhost:<포트>/actuator/health
응답의 details 에 어떤 하위 점검이 DOWN 인지 나온다. 이것이 곧 원인이다.
엔드포인트 경로는 서비스마다 다르다. 응답이 없으면 프로세스가 그 포트를 실제로 듣고 있는지부터 본다.
ss -lntp | grep <포트>
Viya 3.5 는 서비스 디스커버리와 상태를 Consul 이 들고 있다. Consul 이 흔들리면 멀쩡한 서비스도 실패로 보인다.
systemctl status sas-viya-consul-default
journalctl -u sas-viya-consul-default -n 100 --no-pager
Consul 자체가 정상인지부터 확인한 뒤 개별 서비스를 판단한다. Consul 연결 실패로 다른 서비스가 뜨지 않는 경우의 대응은 SAS Viya 3.5 운영 에 정리돼 있다.
원인을 고친 뒤에는 의존 순서대로 올린다. 아무 순서로 올리면 아래 서비스가 아직 준비되지 않은 상태에서 위 서비스가 붙으려다 다시 실패한다.
/opt/sas/viya/home/bin/sas-viya-all-services-default stop
/opt/sas/viya/home/bin/sas-viya-all-services-default start
전체 재기동은 시간이 오래 걸린다. 원인을 좁힌 뒤 해당 계통만 순서대로 올리는 편이 낫다.
대화 기록에 남은 사례는 원인을 확정하지 못한 채 끝났다. 초기 진단에서 Elasticsearch 연결 실패를 원인으로 지목했으나, 해당 환경에는 Elasticsearch 가 배포돼 있지 않아 성립하지 않는 가설이었다. 같은 증상을 다시 만나면 다음을 먼저 확보한다.
배포에 어떤 구성 요소가 실제로 들어 있는지부터 확인하고 가설을 세운다.
ls /opt/sas/viya/config/etc/
systemctl list-units 'sas-viya-*' --no-pager