요약일반적으로 사용하는 프로메테우스와 프로메테우스 Docker Image 의 메트릭이 저장되는 기본 경로가 다르다.프로메테우스의 기본 메트릭 저장 경로는 /prometheus/data 이다.docker image에는 --storage.tsdb.path 옵션이 붙어 /prometheu 로 경로가 변경된다.prometheus documenter에 나온 정보대로 기본 경로 /prometheus 로 지정하고 싶다면, 따로 --storage.tsdb.path=/prometheus 옵션을 부여해야 하니, 구성에 주의해야 한다. 현재 docker compose를 구성하여 프로메테우스를 구성 중 docker compose up -d 명령으로 컨테이너 실행을 진행하면 계속해서 컨테이너 마운트 포인트 관련한 에러가 ..
1. 기존 프로메테우스 데이터 마이그레이션현재 테스트로 프로메테우스를 구성하여 node exporter를 통해 몇몇 리눅스 서버를 모니터링하고 있다.별 다른 설정 없이, 단순 프로메테우스 이미지를 컨테이너 실행 시킨 것 뿐이라, 데이터 등도 컨테이너 내부에서 쌓이고 있다. 대강 이런 형식인데, 문제는 모니터링 대상이 추가되거나, 구성에 변경이 있을 시 컨테이너를 재시작하면 쌓여있던 데이터가 전부 날아가는 것이다..(당연히,, 컨테이너를 새로 빌드하면 그렇지..) 그래서 지금 동작중인 해당 프로메테우스의 저장된 3개월치의 데이터를 가지고신규 구성한 컨테이너로 마이그레이션하는 작업을 진행해보겠다. 신규 구성 프로메테우스 구성은 기존 글을 참고하시라https://cwpack0730.tistory.com/10..
1. Prometheus 구성 목적본인은 현재 시스템을 하이브리드 클라우드 형태로 운영하고 있는데 (AWS, NCP, GCP, Azure, IDC센터 및 사내 전산실 모두 관리중이다.)프로젝트나 서비스 별로 플랫폼과 환경이 달라서 어느 정도의 통합이 필요한 상황이다... (혼자서 관리하기에 너무 어렵다.)지금 가장 시급한 것은 모니터링 통합이라고 생각했고, 그래서 여러 모니터링 서비스를 찾아보던 중 prometheus를 알게되었다. 현재 대표적인 모니터링 솔루션으로는 zabbix, telegraf, cloudwatch, scouter 등 많이들 있지만, prometheus로 진행해보기로 결정하였다.(몇개는 이미 포스팅하였다. ) 이유는 다음과 같다. 시계열 데이터베이스를 사용한다. (TSDB)데이터가 ..
DHCP 미 할당 이슈 발생본인은 현재 2개의 망으로 네트워크를 분리해서 운영중에 있다.각 내부 서버, NAS, PC 등의 연결과 유선 인터넷 전화기에 연결하는 용도로 사용중인데 근래 사내 PC 들이 DHCP 할당을 못 받아오는 이슈가 종종 발생하였다. DHCP.conf 구성과 연결된 Client 구성에는 문제가 없어, 중간에 네트워크 통신 과정에서 route/swicth 문제가 아닐까 하였는데, DHCP 할당이 안 되는 PC들에겐 모두 공통점이 있었다.모두 원래 사용중이던 대역이 아닌 다른 망의 대역으로 잡히는 것이다. 원인두 개의 망이 각자 DHCP 서버가 존재한다.그리고 내부 구성에서 두 망이 연결되어 있다.(애초에 이 구성부터 잘못되긴 함…)그리고 PC에서 사용중인 망에서 DHCP 할당을 받지 못..
!! Redmine레드마인(Redamine)은 오픈소스 프로그램으로 웹 기반의 프로젝트 관리와 버그 추적 기능을 제공하는 도구이다. 주요 기능으로는 달력과 칸트 차트, 일정관리 기능이 있다.이를 화면기반의 기능을 제공하여 프로젝트 관리에 도움을 줄 수 있다.redmine의 디자인은 Trac에 영향을 많이 받았으며 ruby에 기반하여 작성되었고 멀티 플랫폼을 지원하며 여러가지 종류의 데이터베이스 및 34개의 언어를 지원한다. Ubuntu 20.04 LTS , installdatabase(mariaDB) 설치# database를 설치한다.apt-get updateapt-get install mariadb-server -ymysql -u root -p# db 버전에 따라서 utf8로 진행하여도 된다.Mar..
Grafana Image Renderer 그라파나에서 대시보드 패널이미지를 포함시키기 위해선 그라파나 이미지 랜더러가 필요하다. 그라파나 이미지 렌더러(Grafana Image Renderer) 그래프 이미지화를 위해 해당 플로그린을 설치하거나 독립 실행형으로 배포할 수 있다. 이미지 렌더러 문서(링크) 에서 자세한 설치방법을 확인할 수 있다. 1. 그라파나 cli를 사용한 설치 현재 그라파나를 직접 설치해서 사용하고 있다. 이 같은 경우 cli를 통한 설치가 가능하다. 설치과정에서 크로미움 관련 라이브러리 종속성이 있다. 설치 후, 그라파나 재시작이 필요하기 때문에 docker로 돌리고 있다면 이후 설명하는 독립실행형으로 설치 또는 이미지 렌더러를 포함한 이미지를 사용해야 한다. $ grafana-cl..
Slack app 구축 slack api에 접속하여, create new app을 진행한다. from scartch을 선택한다. 이후 app name을 설정하고 연결할 slack workspace를 선택한다. 좌측 Features 탭에서 OAuth & Permissions을 선택한다. 설치를 진행한다. 관리자 권한이 필요하다. 이후 슬랙 api를 통해 메세지와 그래프이미지 등을 전송할 것이기 때문에, files:wirte , chat:wirte 권한을 추가한다. 이후, 생성된 토큰값을 복사하여 grafana → alerting → contact point를 생성한다. 생성된 contact point에 대한 라우팅 설정을 진행해야 하는데, notification policles 에서 정책을 추가한다. ro..
CloudWatch https://cwpack0730.tistory.com/64 [AWS] CloudWatch (AWS 리소스 상태 모니터링) CloudWatch는 AWS 리소스의 상태를 모니터링 하는 서비스입니다. 모니터링 뿐만 아니라 측정치(Metric)와 연계하여 다양한 액션(Action)을 사용할 수 있습니다. 💡 프리 티어에서 사용 가능 CloudWatch는 cwpack0730.tistory.com 본인이 학습한 cloudwatch 개념 정리된 링크이다. 현재 aws ec2에 서버가 있고, 해당 서버의 기본 리소스(cpu,disk R/W 등)를 grafana로 모니터링 및 slack 알람까지 구현하겠다. # CloudWatch 기본 개념 기본적인 CPU, disk 읽기/쓰기, network 등은..
Server-less Web Service (S3, CloudFront, Route53) 개요 이전 사내 웹 서비스를 서버리스로 호스팅 한 사례를 공유해보려 한다. 웹 개발자나 클라우드에 관심이 있는 사람들에게는 정말 기초적인 작업이지만 서버리스 환경을 처음 접하게 된 계기가 되어 준비하였다. 1. 신규 웹페이지 서비스 오픈 1. 웹 페이지는 개발이 완료되어 데이터 공유받음 2. 호스팅 방식 선택 3. 서비스 오픈 진행 2. 신규법인 웹페이지 호스팅 호스팅 방식 1. 본사 온프레미스에서 호스팅 2. Cloud에서 서버 생성하여 호스팅 3. AWS Service 활용하여 서버 없이 호스팅 1-1. 본사 VM 호스팅 금액: 0원(전기세...?) 관리: 서버 관리자 필요 난이도: 직접 웹서버를 구축해야 함 2..
Canned Policy / Custom Policy 를 사용한 Signed URL 생성 https://cwpack0730.tistory.com/88 [AWS] CloudFront Signed URL 사용 설정Signed URL 사용 설정하기 먼저 Signed URL을 사용하러면 CloudFront 배포에서 Behavior(동작, 행동) 설정이 필요하다. 본인은 실습을 위해 새로 웹 서버를 생성하고 CloudFront로 배포중인 상태이다. CloudFrontcwpack0730.tistory.com 지난 포스팅에서 CloudFront 키 페어 생성을 완료했다. 이제 본격적으로 Signed URL을 직접 생성해보겠다.Signed URL은 보통 애플리케이션에서 자체적으로 생성하여 사용한다. 따라서 Java,..
Signed URL 사용 설정하기 먼저 Signed URL을 사용하러면 CloudFront 배포에서 Behavior(동작, 행동) 설정이 필요하다. 본인은 실습을 위해 새로 웹 서버를 생성하고 CloudFront로 배포중인 상태이다. CloudFront 배포 목록에서 EC2와 연동한 CloudFront 배포를 선택한다. 선택한 CloudFront 배포에서 동작 탭으로 이동하여 defult 동작을 편집하였다. ! CloudFront Restrict Viewer Access 설정 ! 뷰어 엑세스 제한을 Yes로 변경하여 Signed URL을 사용했다. 신뢰할 수 있는 인증 유형으로 키 그룹을 선택할 수 있는 Trusted Key groups, 서명자(사용자)를 직접 선택할 수 있는 Trusted signer..
Signed URL은 CloudFront로 배포되는 파일의 사용을 제한하는 기능이다. Signed URL은 특정 날짜가 지나면 파일을 받지 못하게 하고 싶을 때, 특정 날짜 이후에 파일을 받게 하고 싶을 때, 특정 IP에서만 파일을 받을 수 있도록 할 때 사용된다. Signed URL은 크게 2가지가 있다. Canned Policy를 사용한 Signed URL : 파일 1개의 사용을 제한한다. 또한, 특정 날짜가 지나면 파일을 받지 못하게 하는 기능만 사용할 수 있다. 정책(Policy)의 내용이 URL에 포함되어 있지 않아 URL의 길이가 짧다. Custom Policy를 사용한 Signed URL : 파일 여러 개의 사용을 제한한다. 날짜가 지나면 파일 못받게 하는 기능, 날짜 이후에 받게 하는 기능..
