반응형

1.이슈 내용

  • 최근 EMR Cluster 에서 도커 이미지를 이용해 Spark - submit 실행하는 job 을 추가함.
  • 테스트 시에는 문제가 되지 않았으나, 새벽 배치에서 장애 발생

2.장애 또는 에러 내용

  • Docker inspect command : /usr/bin/docker inspect —format {{.State.ExitCode}} container_iD_appid_…..
  • Exit code from docker inspect : 1

3.이슈 원인

  • EMR 에서 Scale Out 시 Task 노드를 임의로 할당 받게 된다. (Spot instance 사용 중)
  • Task 노드의 커널 아키텍쳐가 이미지 내 빌드된 프로세서 아키텍쳐와 호환이 안될 가능성이 있다.
    • 내가 amd64 아키텍쳐로 빌드를 했는데 실제로 arm64 아키텍쳐의 노드 위에서 실행 될 경우..
  • docker inspect 는 실행 전 이미지를 검사하는 단계로 보여진다. 

4.해결방법

  • buildx 를 이용하여 멀티 프로세서 아키텍쳐에 맞게 빌드한다.
  • 참고로 buildx 를 이용할 때 빌드와 push 만 가능하다.
1. buildx 활성화 및 확인
$ docker buildx version
$ docker buildx ls

2. buildx 초기화 및 빌더 인스턴스 생성
$ docker buildx create --name multi-archi-builder
$ docker buildx use multi-archi-builder


$ docker buildx inpsect --bootstrap 
-- bootstrap 은 초기화 프로세스 플래그

3. build 와 동시에 push 하기
$ docker buildx build --platform linux/arm64,linux/amd64 -t myapp:latest --push .

4. 이미지 확인하기
$ docker manifest inpsect [이미지]:[태그]
 

5.회고

- 사실 aws 코리아 기술자 분들과 미팅을 하면서,쿠버네티스 환경에서는 꼭 컨테이너 이미지의 멀티 아키텍쳐 빌드가 필요하다는 내용을 팁으로 들었었다. 그때는 잘 끄덕였는데.. 귀로만 흘려들었더니, 새벽 4시에 일어나 장애 대응을 해야 했던 결과를 맞았다.

최근 배치 장애도 잦고, 더 꼼꼼해야 겠다. 그리고 반성하자

반응형
반응형

1.이슈 내용

- MWAA 에서 실행됐던 snowflake 관련 dag 들이 SnowflakeOperator를 import 할때 에러를 발생시킴

- MWAA  에서 SQLAlchemy 패키지가 최신 업데이트 되면서, 아래 에러를 출력

ile "/usr/local/lib/python3.8/dist-packages/snowflake/sqlalchemy/__init__.py", line 63, in <module>
    from .util import _url as URL
  File "/usr/local/lib/python3.8/dist-packages/snowflake/sqlalchemy/util.py", line 8, in <module>
    from sqlalchemy.engine.url import _rfc_1738_quote
ImportError: cannot import name '_rfc_1738_quote' from 'sqlalchemy.engine.url' (/usr/local/lib/python3.8/dist-packages/sqlalchemy/engine/url.py)```

2.이슈 원인

- sql_alchemy 가 1.4.42버전으로 업데이트 되면서 rfc 1738 즉 quote 처리하는 method 가 rename 되면서 import 하는 코드가 동작하지 않게 되는 이슈가 발생

3.해결 방법

- 일단 급하게 1.4.41 버전으로 다운그레이드 했지만, 버그가 수정된듯 하다.

https://github.com/snowflakedb/snowflake-sqlalchemy/issues/350

 

SNOW-679045: _rfc_1738_quote is no longer available in sqlalchemy 1.4.42 · Issue #350 · snowflakedb/snowflake-sqlalchemy

The latest release of sqlalchemy 1.4.42 has renamed all of the rfc 1738 stuff so this import no longer works: snowflake-sqlalchemy/src/snowflake/sqlalchemy/util.py Line 8 in be1f741 from sqlalchemy...

github.com

https://github.com/sqlalchemy/sqlalchemy/issues/8647

 

4.회고

- 일단 내가 생각없이 행동했던 조치는 1차 구글링, snowflake 패키지 버전 업데이트 그리고 해결이 안되자 스노우플레이크 기술이사님께 해당 이슈를 공유드리고, 에러가 나는 부분의 코드를 해석 후에 어떤 경우에 발생하는지 코드를 따라가봤다. 

-이슈 공유 드리고, 30분도 안되서 기술 이사님께 github 에 관련 issue 의 링크를 공유 받았고, 다운그레이드로 일단 선 대응할 수 있었다.

- sqlAlchemy 도 오픈 소스인걸 알았음에도 왜 github 에 issue 를 살펴보지 않았을까 후회했다. 

- 습관적으로 구글링에 의존하고, 어떤 설치나 재시작, 재시동 만으로 문제를 편하게 풀려고만 했던 행동들을 반성하자. 

 

 
반응형
반응형

1.이슈 내용

- 파이썬 클래스의 멤버 변수 초기화시 특정 컬럼이 tuple 값으로 초기화되던 문제.

- tuple 로 초기화 된 값 때문에, external 테이블이 미리 정의한 컬럼 타입과 불일치 하여 조회에 이슈가 발생했었다.

2.이슈 원인

-내 손의 잘못.

-콤마. 파이썬은 원소 뒤에 콤마가 있으면 단일 튜플로 인식한다.

 

- 예제 재연

import json

ods_json_data ='''
{
    "log_seq" : "00001",
    "event_time" : 1656771413
}
'''

class ODSLog:
    def __init__(self,
                 log_Seq = None, 
                 event_time = None,
                 field_1 = None,
                 field_2 = None,
                 **kwargs):
        self.log_seq=log_Seq
        self.event_time=event_time
        self.field_1=field_1,
        self.field_2=field_2
        
def get_ods_transform_log():
    ods_data = json.loads(ods_json_data)
    ods_log = ODSLog(ods_data)
    print(ods_log.__dict__)
   
get_ods_transform_log()
# 출력 값 - 
{'log_seq': {'log_seq': '00001', 'event_time': 1656771413}, 'event_time': None, 'field_1': None, 'field_2': (None,)}

- ods_json_data 와 같은 방식으로 데이터가 들어오면, 클래스를 이용하여 필요한 ETL 처리후에 데이터를 출력 처리

- 실시간 데이터 수집의 경우 이상값이나 정의하지 않은 컬럼이 들어올 때를 예측해서 처리 로직을 추가해주면 좋다.

 

3.회고

콤마가 포함된 라인 하나를 발견하지 못해, 원천 데이터를 탓하며 일부러 타입 캐스팅을 하드코딩할 생각까지 했던 스스로를 반성한다. 

컬럼이 엄청 많은 로그를 처리할때 sublime text 나 엑셀을 이용해 프로그램 코드의 일부분을 일괄로 처리할 때가 있다. 그때 일부는 하나하나 찾아가면서 보정을 하게 되는데 그 과정에서 실수가 많이 발생하는 것 같다.

 

하반기에는 파이썬 공부도 해야 할 것 같다....

반응형
반응형

문제 해결이라기 보단, 회고에 가까움.

그라파나 자체 사용자 인증 기능을 사용하거나 sqlite 를 사용한다면 아래 이슈참고.

 

1.이슈 내용

  • grafana 사용자 view 권한 기능을 검증하려다, 모르고 organization 을 삭제 .. 정확하게는 신규 사용자에게 잘못 부여한 organization 을 제거한다는게, organization 을 삭제하는 작업을 진행해버림.
  • 갑자기 생성한 대시보드, 팀 모두 사라짐...  오잉 .. -_-??

2. 이슈 원인

  • grafana 기능 테스트 중 기존 조직(organization) 삭제..
  • 조직이 삭제되면서 연관된 팀과 대시보드가 자동으로 삭제 됨....

나랑 비슷한 실수를 한 사례들 조사

https://community.grafana.com/t/is-there-a-way-to-restore-an-accidentally-deleted-dashboard/23839

https://community.grafana.com/t/deleted-organization-how-to-recover/7189

 

 

3. 해결방법

 

결론은.. 주기적으로 백업하지 않으면 복원이 어려움. 

sqlite 에 진입해서 organization 레코드만 수동으로 만들어주면 되지 싶었으나, 연계된 데이터들 모두 삭제되서 행이 보이지 않았음..

 

 

 

일단 sqlite db 복제 스크립트를 등록 ...

## crontab 등록
0 0 * * * /usr/local/backup_script/backup_grafana_sqlitedb.sh
 
 
 
# 복제 스크립트
#!/bin/bash
GRAFANA_DATA=/usr/local/grafana/data
command cp ${GRAFANA_DATA}/grafana.db ${GRAFANA_DATA}/grafana_backup.db

 

 

데이터가 사라진건 아니지만, 너무 미안하게도 동료들이 작성한 대시보드, 데이터 소스들이 사라졌다. 

grafana 가 사용하는 meta db 의 백업은 필수로 하길 권장한다.

 

꼭..

반응형
반응형

1.  에러 로그

-- 유실..

 

2. 원인 또는 현상

Werkzeug 모듈이 버전에 따라 secure_filename() 의 위치가 달라져, 발생하는 이슈

 

3.해결방법

해당 패키지 업그레이드.

$pip install --upgrade werkzeug==0.16.1
반응형

+ Recent posts