편향적인 내용으로 당연히 절대 평가는 되지 않습니다. 상황에 맞게 써야 하며, 특성을 참고하는데 도움은 됩니다.

원문: https://bitworking.org/news/2017/03/prometheus

우리는 모든 모니터링을 InfluxDB 에서 Prometheus로 마이그레이션하는 작업을 끝내 었습니다. 변화에 대한 이유를 적어 두었 습니다. 이 내용은 저의 개인적인 관찰이며 특정 프로젝트와 관련이 있습니다. 이러한 문제는 귀하에게 적용되지 않을 수 있으며 각 제품을 귀하 자신의 용도로 평가해야합니다.

업데이트 : 명확히하기 위해 InfluxDB와 Prometheus의 버전은 InfluxDB 1.1.1과 Prometheus 1.5.2입니다.

Push vs Pull

InfluxDBInfluxDB는 Push 기반 시스템입니다. 즉, 실행중인 응용 프로그램이 데이터를 모니터링 시스템에 적극적으로 Push해야합니다. Prometheus는 Pull 기반 시스템이며, Prometheus 서버는 주기적으로 실행중인 응용 프로그램에서 메트릭 값을 가져옵니다.

Prometheus로 폴링하는 방법을 중앙에서 제어 할 수 있기 때문에 Prometheus 서버의 구성을 조정하는 것만으로 매분마다 폴링을 전환 할 수 있습니다. InfluxDB를 사용하면 메트릭을 얼마나 자주 Push해야하는지에 대한 변경으로 모든 애플리케이션을 재배포해야합니다. 또한 Prometheus pull 메서드를 사용하면 Prometheus가 응용 프로그램의 실행 여부를 모니터링하는 합성 "UP"메트릭을 만들고 제공 할 수 있습니다. 수명이 짧은 애플리케이션의 경우 Prometheus에는 푸시 게이트웨이가 있습니다.

데이터 저장소

InfluxDB는 메트릭 값과 인덱스 모두에 대해 모 놀리 식 데이터베이스를 사용합니다. Prometheus는 지표에 대해 LevelDB를 사용하지만 각 측정 항목은 자체 파일에 저장됩니다.

둘 다 키 / 값 데이터 저장소를 사용하지만 키 스토어를 사용하는 방법은 매우 다르며 제품의 성능에 영향을 미칩니다. InfluxDB는 느린 속도 였고 똑같은 측정법으로 Prometheus보다 훨씬 많은 디스크 공간을 차지했습니다. InfluxDB를 시작하고 그로 인해 측정 된 데이터의 수가 적 으면 데이터 저장소가 1GB로 증가한 다음 Prometheus가 모든 측정 항목을 사용하여 아직 10GB를 크랙하지 않은 채로 전체 측정 항목에 대해 데이터 저장소를 100GB까지 빠르게 확장했습니다. . InfluxDB가 우리가 실행하고 있던 InfluxDB 버전을 업그레이드하려는 시도가 실패하거나 실패했을 때 InfluxDB가 모든 데이터를 잃어 버렸습니다.

업데이트 : Prometheus는 몇 초 만에 시작되는 반면, InfluxDB는 색인을 유효화하거나 다시 작성하는 동안 정기적으로 5 분이 걸리고 전체 프로세스 중에 데이터를 수집하지 않는 등 시작 시간에 관한 또 다른 데이터 저장소 관련 문제가 있음을 상기했습니다.

CPU

아마도 데이터 저장소의 효율성과 밀접한 관련이있는 InfluxDB는 실행중인 서버를 최대한으로 늘려 가고 있었지만 Prometheus는 동일한 인스턴스에서 최대 0.2 개의로드를 넘었습니다.

검색어 언어

InfluxDB는 SQL의 변형을 사용합니다. Prometheus는 실질적으로 보다 간단하고 직접적인 쿼리 모델을 사용합니다.

무엇을 입력 하시겠습니까?

SELECT * FROM "cpu_load_short" WHERE "value" > 0.9

또는

cpu_load_short > 0.9

설정

InfluxDB : 설정 파일 & SQL 명령의 혼합

Prometheus : 텍스트 파일 사용

Prometheus 설정은 간단히 YAML 파일이며, 전체 설정은 파일을 통해 이루어진다. InfluxDB를 사용하면 예를 들어 메트릭스를 저장할 명명된 데이터베이스를 생성하는 등의 구성 중 일부가 실제로 수행되는 것을 우려해야 한다. 또한 Prometheus는 15일 동안만 데이터를 저장하는 것이 기본이고, InfluxDB는 모든 데이터를 영구적으로 저장하는 것이 기본이며, 모든 데이터를 영구적으로 저장하지 않으려면 데이터가 보존되는 방법을 제어하기 위해 서버로 전송하는 SQL 명령을 생성해야 한다.


  • clone 받은 상태로 원복 할려면 해당 경로로 이동 후

git checkout . && git clean -fdx


  • git add 이전

git checkout DIR_PATH    #특정 폴더 아래의 모든 수정 사항 원복

git checkout .      # 현재 폴더 아래 모든 수정 사항 원복

git checkout FILE_PATH     #특정 파일 원복


  • git add 한 경우

git reset


  • git commit 까지 한경우 : 
    • commit 내용을 없애고 이전 상태로 원복

master 브랜치의 마지막 커밋을 가리키던 HEAD를 그 이전으로 이동시켜서 commit 내용을 없앰

git reset --hard HEAD^

    • commit은 취소하고 commit 했던 내용은 남기고 unstaged 상태로 만들기

git reset HEAD^

    • commit은 취소하고 commit 했던 내용은 남기고 staged 상태로 만들기

git reset --soft HEAD^


  • 불필요한 파일 및 디렉토리 지우기 (untracked)

git clean -fdx


  • git push를 한 경우 remote repository도 이전으로 되돌리기

git reset HEAD^

git commit -m "..." 

git push origin +master


마이크로서비스로만 가면 만능일것 같은 시대에 한번 쯤 읽고 고민해 볼만한 글이다.


"마이크로서비스는 답이 아니었다"··· 세그먼트가 모놀리틱으로 돌아온 이유

Tamlin Magee | Computerworld UK


원문보기: http://www.ciokorea.com/news/39258

다른 많은 기업과 마찬가지로, 데이터 스타트업 세그먼트(Segment) 역시 오래된 인프라스트럭처로 인한 문제 때문에 마이크로서비스(microservice)로 눈을 돌렸다. 하지만 곧 단일 구조(monolithic) 아키텍처로 돌아오지 않으면 해결할 수 없는 복잡한 문제가 있다는 것을 깨달았다.

세그먼트의 주 고객은 타임(Time), IBM, 리바이스(Levi’s) 등이다. 이들 기업의 모든 고객 데이터를 세일즈, 애널리틱스, 헬프데스크 등에 피딩하기 전에 한 지점에 모아 볼 수 있는 서비스를 제공한다.

세그먼트의 CTO이자 공동창립자인 캘빈 프렌치-오웬은 “처음에는 단일 API와 라이브러리를 제공하고 그들이 데이터를 보내오는 식의 개발자 우선 방식을 택했다. 우리가 데이터를 모아 구성한 후 이를 적절한 스키마로 정렬하고, 고객사가 사용하는 200여 가지 이상의 툴에 이 데이터를 보냈다. 여기서 툴이란 세일즈포스 같은 세일즈 툴 일수도 있고, 젠데스크(Zendesk) 같은 고객 관련 툴, 혹은 레드시프트(Redshift)나 빅쿼리(BigQuery)같은 데이터 웨어하우스 일수도 있다”라고 말했다.

세그먼트사는 전적으로 AWS에 의존하고 있으며, ECS(Elastic Container Service)가 관리하는 1만 6000개 컨테이너가 250여 가지 마이크로서비스를 제공한다.

세그먼트는 원래 단일 구조 아키텍처를 사용했다. API가 데이터를 처리해 싱글 큐(queue)에 포워딩하면 직원이 데이터를 읽고 이벤트를 모든 서버측 ‘목적지’, 그러니까 파트너 API에 선형 체인을 통해 전송했다. 그러나 이런 방식은 이내 문제를 발생시켰다. 툴에서 서버 에러를 반송할 때의 재시도가 큐와 만나 다른 이벤트와 뒤섞이는 것이다. 이로 인해 파이프가 막히고 성능 장애로 이어졌다.

세그먼트의 소프트웨어 엔지니어 알렉스 누난은 “단일 구조에서 탈피해 마이크로서비스로 전환한 것도 이 때문이었다. 우리에게는 데이터를 수집하는 API와 라우터가 있고, 라우터는 이벤트를 목적지별 큐와 서비스로 라우팅했다. 이벤트가 발생하면 라우터가 ‘좋아, 이 이벤트는 구글 애널리틱스와 맥스 패널로 보내야겠어’라고 판단을 내리고 해당 이벤트의 카피를 2개 생성해 각각의 큐로 이를 보내는 식이었다”라고 말했다.


바람 잘 날 없었던 “마이크로서비스”의 세계

마이크로서비스 방식은 한동안 잘 돌아 가는 것처럼 보였다. 그러나 역시 문제가 발생했다. 누난의 표현을 빌리면 '마이크로서비스 세계의 더 깊숙한 곳에서 개별 파트너의 API 목적지와 서비스에 대한 새로운 타입의 큐가 형성됨'에 따라 발생했다. 결국 개발자는 모든 업데이트를 수동으로 처리해야 했고 어떤 업데이트 버전이 어디의 어느 리포(repo)에 있는지를 일일이 기억하는 것이 한계에 다다랐다.

누난은 “시간이 갈수록 개발자의 생산성이 급격히 저하됐다. 모든 것이 각기 다른 별개의 큐와 별개의 서비스, 그리고 자체적인 리포에 있었기 때문이다. 우리는 통합을 유지, 생성하기 위해 공유 라이브러리를 만들었지만 이것을 전개할 좋은 방법도, 또 제대로 테스팅할 여건도 안됐다. 공유 라이브러리를 업데이트하기에는 시간도 자원도 부족했다. 결국 구글 애널리틱스 버전만 업데이트하는 식이 됐다. 모든 라이브러리가 서로 다른 업데이트 버전을 갖게 됐다"라고 말했다.

세그먼트 팀은 파트너 API가 각각 어느 라이브러리 버전에서 구동되는지 추적하고, 그 버전 간의 차이도 기억해야 했다. 누난은 “라이브러리 관리 업무 만으로도 개발자에게 너무 큰 부담이 됐다. 꾹 참고 서비스마다 하나하나 변경할 수도 있지만 그러려면 수 일이 걸렸고, 특히 서비스 하나 하나를 테스트하고 전개하는데 여러 명의 개발자가 필요하게 됐다. 이것이 너무 큰 부담으로 작용한 끝에 결국 꼭 필요한 변경사항조차도 적용하지 않게 되는 일까지 발생했다. 모든 서비스에 아주 작은 변경사항만 적용하기 위해서도 팀 전체가 달려 들어 일주일 이상 소모해야만 했다”라고 말했다.

세그먼트의 직원은 이러한 큐를 처리하기 위해 수면 부족에 시달리는 것도 모자라, 성능 이슈에도 직면했다. 예를 들어 구글 애널리틱스와 같은 대규모 목적지의 경우 초당 수천 건에 달하는 이벤트를 처리하는 반면 하루에 수 건 이내의 이벤트만을 처리하는 곳도 있었다. 세그먼트 팀은 오토-스케일링 룰을 적용해 이러한 서비스의 수동 커스터마이징을 최소화 했지만 서비스마다 고유의 CPU 및 메모리 로드 패턴이 있었기 때문에 모든 통합에 같은 룰을 적용할 수는 없었다.

누난은 “하루에도 수십 번씩 쉴 새 없이 호출이 왔고, 직원이 일일이 개입해 이러한 서비스를 처리해야 했다. 이런 식으로 2년 넘게 마이크로서비스 방식을 이용한 결과 큐와 리포에 140여 가지 서비스를 갖게 됐지만 시스템 장애를 막는 데에만 모든 에너지를 쏟아도 역부족이었기에 그보다 더 건설적이거나 선제적인 어떤 노력도 할 수 없는 상황이었다. 이쯤 되자 한걸음 물러나 생각해 보지 않을 수 없었다. ‘대체 이 상황을 해결하려면 어떻게 해야 하지?’ 결국 인력을 추가해야 한다는 결론이 나왔지만, 그런 식으로 문제를 해결하고 싶지는 않았다”라고 말했다.

그러나 결국 세그먼트는 마이크로서비스 아키텍처가 지속 불가능하다는 결론에 다다랐다. 목적지를 추가할수록 성능 저하가 눈에 띄게 증가했고 이것은 ‘상당히 뚜렷한 경고 신호’였다. 누난은 “한창 마이크로서비스로 인한 광기가 극에 달했을 때 내가 세그먼트에 합류했다. 당시 이미 어떻게 하면 이 문제를 해결할 것인가에 대한 논의가 이루어지고 있었다”라고 말했다.



단일 구조로 돌아가다

세그먼트 팀은 마이크로서비스를 어떻게 다시 하나의 거대한 시스템으로 재설계할 것인지 방법을 찾아야 했다. 이른바 ‘신(新) 단일구조’로의 이행이었다. 결국 당시 세그먼트가 진행 중이던 ‘센트리퓨즈(Centrifuge)’ 인프라스트럭처 프로젝트를 통해 새로운 단일 구조로 이행하기로 결정됐다. 센트리퓨즈는 세그먼트 비즈니스의 핵심이라 할 수 있는 단일 이벤트 딜리버리 시스템이다.

프렌치-오웬은 “센트리퓨즈는 큐를 생성하고 실패가 발생했을 때 트래픽을 흡수하기 위한 시스템이다. 이 시스템 덕분에 우리는 여러 코드를 한 장소에 통합하고, 이를 통해 두 마리 토끼를 잡는 전략을 취하기로 했다"라고 말했다.

이를 위해 먼저 모든 목적지 코드를 하나의 리포로 통합했다. 하나의 리포에 모든 종속 항목과 테스트를 합병하는 것이었다. 서비스가 하나뿐이므로 논리적으로 당연했다. 그러나 이 과정이 대단히 복잡하고 머리 아픈 과정이었다. 누난은 "120개가 넘는 고유의 종속 항목들 각각에 대해 우리는 모든 목적지에 대한 하나의 버전을 만드는 데 집중했다. 또한 목적지를 이동하면서 사용 중인 종속 항목을 확인하고 이들을 최신 버전으로 업데이트했다. 또 목적지의 새로운 버전에서 생긴 부분을 바로 바로 수정했다"라고 말했다.

이렇게 일관성을 확보한 결과 코드베이스를 어지럽히던 혼란이 상당 부분 해소되었다. 세그먼트 팀은 또한 빠르고 쉽게 모든 목적지 테스트를 한 번에 진행할 수 있는 테스트 스위트는 개발했다. 지나치게 길고 복잡한 테스트 과정 역시 업데이트를 방해하던 주요 요소 중 하나였기 때문이다.

이처럼 목적지 코드를 단일 리포로 이동시켜 단일 서비스로 통합하자 곧바로 개발자 생산성 증대라는 성과로 이어졌다. 서비스 전개 시간도 수 분 이내로 단축됐다. 누난은 “인프라스트럭처의 가장 큰 부분을 재설계해야 했기 때문에 단일 구조로의 전환에는 상당한 시간이 걸렸다. 당연한 일이었다. 하지만 적어도 예전처럼 계속해서 고객 지원 요청이 들어오거나 하는 일은 없다. 모두가 수면 부족에 시달리지 않을 수 있게 됐다. 모든 것을 하나의 리포로 통합하고 나니 관리도 쉬워졌다”라고 말했다.

이어 "이제 공유 라이브러리에 업데이트를 생성하고 싶을 때, 엔지니어 1명이 한 시간만 투자해 테스트하고 전개할 수 있다. 우리에게는 정말 획기적인 변화였다. 처음 마이크로서비스를 채택했을 때 당시 그런 선택을 할 만한 사정이 있었다고 생각한다. 당시 팀이 처한 상황이나 겪고 있던 성능 이슈를 고려하면 최고의 선택이었다. 그러나 시간이 지날수록 마이크로서비스의 장점은 사라지고 생산성과 성능만 잡아먹게 됐다. 그래서 다시 단일 구조로 돌아온 것이다"라고 말했다.

세그먼트 사가 다른 기업에 비해 처리하는 데이터 양에서 압도적으로 많긴 하지만 비슷한 불편을 겪는 다른 기업 역시 단일 구조로 돌아오는 것이 하나의 대안이 될 수 있다. 누난도 "그런 선택을 한다고 해도 전혀 놀라운 일이 아니다"라고 말했다.

단일 구조로 돌아온 후 나아진 건 세그먼트 사 직원의 워크-라이프 밸런스 뿐 만이 아니다. 고객 역시 훨씬 일관되고 안정적인 서비스를 누릴 수 있게 됐다. 프렌치-오웬은 “모든 서비스가 한 장소에, 단일 리포에 통합됨에 따라 추가된 변경 사항이 다음 번에도 모든 서비스에 똑같이 전개될 것이라는 확신을 가질 수 있게 됐다. 덕분에 고객 역시 서비스 별로 각기 다른 버전으로 인해 발생하는 혼란이나 비일관성을 더 이상 겪지 않아도 됐다"라고 말했다. 

ciokr@idg.co.kr 


https 디버깅할려니 필요해서..

출처: https://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html

Adding trusted root certificates to the server

If you want to send or receive messages signed by root authorities and these authorities are not installed on the server, you must add a trusted root certificatemanually.

Use the following steps to add or remove trusted root certificates to/from a server.

Mac OS X

FunctionMethod
Add

Use command:

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ~/new-root-certificate.crt

Remove

Use command:

sudo security delete-certificate -c "<name of existing certificate>"

Windows

FunctionMethod
Add

Use command:

certutil -addstore -f "ROOT" new-root-certificate.crt

Remove

Use command:

certutil -delstore "ROOT" serial-number-hex

Linux (Ubuntu, Debian)

FunctionMethod
Add
  1. Copy your CA to dir /usr/local/share/ca-certificates/
  2. Use command: sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt
  3. Update the CA store: sudo update-ca-certificates
Remove
  1. Remove your CA.
  2. Update the CA store: sudo update-ca-certificates --fresh

NOTE

Restart Kerio Connect to reload the certificates in the 32-bit versions or Debian 7.

Linux (CentOs 6)

FunctionMethod
Add
  1. Install the ca-certificates package: yum install ca-certificates
  2. Enable the dynamic CA configuration feature: update-ca-trust force-enable
  3. Add it as a new file to /etc/pki/ca-trust/source/anchors/: cp foo.crt /etc/pki/ca-trust/source/anchors/
  4. Use command: update-ca-trust extract

NOTE

Restart Kerio Connect to reload the certificates in the 32-bit version.

Linux (CentOs 5)

FunctionMethod
Add

Append your trusted certificate to file /etc/pki/tls/certs/ca-bundle.crt

cat foo.crt >>/etc/pki/tls/certs/ca-bundle.crt

NOTE

Restart Kerio Connect to reload the certificates in the 32-bit version.


+ Recent posts