코알못

redash 기능중 특정 조건을 만족할시 알람을 보내는 기능이 있다. 로그 수가 특정 카운트 이하로 떨어졌을시 알람을 발생시키는 실습을 진행해본다! 우선 오늘 날짜 로그 수를 카운팅하는 쿼리를 작성한다. 현재는 1건이고 3건 이하일시 알람을 보내도록 설정한다. redash 페이지를 접속한뒤 Create > Alert 를 클릭한다. 그러나 메일 서버를 설정하라는 오류가 발생한다. 메일 서버는 나중에 셋팅하기로 하고 우선 slack 연동을 진행해본다. 설정 값은 아래와 같다. - totalcount 칼럼의 값이 3보다 작을시 알람을 보낸다. - 상태값이 변경(경고 > 정상 or 정상 > 경고 등) 되면 무조건 보낸다. - rearm secounds 는 알람을 보낸뒤 1s 동안은 감지 하지 않는다. (만약 6..

이번 실습은 redash 에서 조회한 데이터를 외부에 공유 하는 실습을 해본다. 쿼리 결과 공유 파일로 공유 (공유 시점의 데이터) CSV 파일 다운후 공유 엑셀 파일로 다운후 공유 이미지 파일로 다운후 공유 URL로 공유 (저장된 데이터를 서버에서 가져오는것으로 호출 시점에 DB 를 조회하여 데이터를 갱신하지는 않는다.) CSV 파일 다운 URL JSON 파일 다운 URL 웹 뷰 URL 대시 보드 웹 뷰 URL 공유 (저장된 데이터를 서버에서 가져오는것으로 호출 시점에 DB 를 조회하여 데이터를 갱신하지는 않는다.) 자 실습 진행해본다! 쿼리 결과 공유 실습부터 진행한다. 우선 공유할 대상 쿼리를 선택한다. CSV, Excle 을 클릭 하여 모두 저장한다. 확인해보면 아래와 같이 다운이 되었으며 열어보..

이번 시간에는 대시 보드를 이용하여 관련 있는 데이터끼리 한눈에 볼 수 있도록 한다. redash 를 접속하여 Create > Dashbord 를 클릭한다. 원하는 대시보드명을 지정하고 Save 를 눌러 저장한다. Add Widget 은 기존에 만들어둔 쿼리를 이용해 결과 데이터를 활용하며, Add Textbox 는 대시보드 설명을 붙여줄 텍스트 박스를 추가하는 것이다. 우선 'Add Widget' 를 눌러 기존에 만들어둔 쿼리 불러온다. 태그명으로 조회해본다. (태그명을 잘지정하면 검색이 용이하다.) 그러나 선택이 안된다. 이 부분은 기존에 만들어둔 쿼리가 publish 상태가 아니라서 대쉬보드에 이용이 불가능 한것이다. 대시보드 생성은 잠시 멈추고 쿼리를 publish 하기 위해 만들어둔 쿼리 수정할..

이번 시간에는 쿼리를 이용해 데이터 시각화를 해볼 예정이다. 쿼리를 작성한뒤 Excute 를 클릭하면 쿼리가 제출 된다. 그리고 조회가 완료 되면 아래와 같이 데이터가 나온다. 이제 해당 데이터를 시각화 해본다. New Visuallzation 을 클릭한다. 아래와 같이 원하는 그래프 유형, 이름, x 축, y축 데이터 선택하면 오른쪽 화면에 미리보기로 볼 수 있다. Save 를 눌러 저장한다. 만들어진 그래프위에 마우스를 올려두면 아래와 같이 카메라 버튼을 클릭하여 이미지로 저장할 수 있다. 이미지로 저장한 파일을 보면 정상적으로 저장된것을 확인 할 수 있다. 워드 클라우드 형태로도 만들어 본다. 저장이 되었으며 아래와 같이 확인 가능하다. 해당 쿼리에 대한 제목과 태그를 추가하여 다음에 불러올시 구분..

이번 시간에는 데이터 저장소 연결 하는 실습을 진행해본다. 저자의 경우 HIVE DB 를 저장소로 사용하고 있어 해당 저장소를 연결하는 실습을 진행한다. [지난번에 생성한 redash 인스턴스] 의 public ip를 인터넷 창에 입력하여 접속 한다. 아래와 같이 Data Sources를 클릭한다. New Data Source 를 클릭한다. 저장소를 선택할 수 있으며 저자의 경우 HIVE를 연결 해야하니 HIVE 를 선택한다. 아래와 같이 connection 정보를 입력한다. HIVE 를 우선 EC2 에 구축하였기에 security group 설정에 해당 redash IP 에서 HIVE Port 접근을 허용한다. Name : 원하는 명칭 Host : DB host 명 Port : DB port Datab..

빅데이터를 수집하여 저장소에 저장을 했다면 기획자나 외부 보고용으로 공유 시에는 데이터를 시각화 하여 (예: 그래프) 공유 하는것이 이해하기 쉽고 데이터 변화가 한눈에 보여 좋다. 그리고 아래와 같이 많은 기능을 제공하고 있어 활용도도 높다! 데이터 시각화 대시보드 기능 (쿼리 결과 대시보드로 만들어 보여줄수 있음) 스케쥴링 기능 (주기적으로 데이터를 조회하여 대시보드가 자동 갱신되도록 할 수 있다.) 경고 알람 기능 (slack, 이메일 가능) 슬랙으로 쿼리 조회 기능 (그래프 이미지까지 볼 수 있다.) deprecated 다른 저장소의 결과(예: mysql , orcle 테이블간 조인)를 조인하여 새 데이터 가공 가능 데이터 공유 기능 사용자 초대 ldap 연동 그리고 zapier 와 함께 이용하면 ..

서비스 별로 로그가 있는 서버에 파일비트를 설치하여 수집하고 logstash 에 로그를 모을 것이다. 그리고 logstash 에서 원하는곳을 하나 또는 그 이상을 지정하여 보낼것이다. 이때, 로그를 서비스 별로 다른곳에 보내고 싶다면 어떻게 해야할까? 결론, 서비스별로 분기처리 가능하다. 그럼 kafka 로 로그 데이터를 넘길시 서비스 별로 토픽을 따로 따야 할까 ? 저자 생각으로는 서비스 별로 토픽을 추가하는 방식으로 간다면 서비스가 추가 될때마다 토픽을 따는 작업과, logstash 분기 처리 하는 작업이 필요하여 관리에 대한 공수가 커진다. 그렇기에 지금은 하나의 토픽으로 관리하되, 필요시에 추가하는 방향으로 가는것이 (수정이 어렵지 않고 이슈도 없어 보여) 좋을 것 같다. 실습은 아래와 같이 진행..

logstash 의 경우 내부 큐 타입은 2가지로 설정 가능하다. - memory (메모리) - persisted (디스크) 두가지 방식에 대한 차이를 구글링 해보았을때 아래와 같다. 구분 memory persisted 장애 발생시 큐에 저장된 데이터 유실 데이터 유실 없음 속도 빠름 느림 현재 회사에 설정된 queue type 은 memory 이며 데이터 유실이 발생할 수 있는 구조이다. 데이터 유실 없이 데이터 수집이 필요하여 persisted 사용시 성능 차이가 얼마나 발생하는지, 얼마나 디스크를 차지하는지를 이번시간에는 파악해보기로 한다. 우선 결과부터 말하자면 아래와 같다. 방식 데이터 건수 소요 시간 사용 메모리 사용 CPU 샤용 디스크 memory 3,000,000 5분 750MB 90% 0..