최현복 2021.10.08. influxDB로 시계열 데이터를 수집하여 grafana를 통해서 시각화하여 모니터링에 사용중이였습니다. prometheus를 통해서도 수집을 하는 데이터가 있지만, 특정 기간을 그룹핑하는데는 influxDB에 강점이 있다고 판단되어 influxDB 사용하게 되었습니다. flux query을 사용하여 기간별 통계 그래프를 작성하였습니다. 익숙하지 않은 query 이지만, 참고 문서를 활용하면 원하는 그래프를 그릴 수 있습니다. influxDB 란? InfluxDB는 인플럭스데이터가 개발한 오픈 소스 시계열 데이터베이스(TSDB:Time-series Database)입니다. 시계열 데이터 베이스 란? 데이터를 저장할 때 시간을 key로 저장하는 데이터베이스 입니다. 시간을 베이스로 조회하는 기능을 제공합니다. flux query 를 활용하기 저장된 데이터 collection 은 상품수, index 는 동적색인, api는 검색api 호출량 입니다. 서비스를 구분하기 위해서 name으로 tag를 추가했습니다. db measurement field tag search collection count name search index count name search api count name A. 일간 상품수 그래프 만들기 < query > from(bucket:"search") |> range(start: -${start_time}, stop: now()) |> filter(fn: (r) => r._measurement == "collection") |> filter(fn: (r) => r._field == "count") |> filter(fn: (r) => r.name == "기준상품") |> group(columns: ["count"], mode: "by") |> aggregateWindow(every: 1d, fn: max) |> map(fn: (r) => ({_value: r._value, _time: r._time, _field: "기준 상품 수"})) < 설명 > bucket은 db를 기입합니다. range 범위는 (start: -${start_time}, stop: now()) 시작값(start)을 start_time 변수로 사용하고 종료값(stop)은 현재(now() 까지로 설정했습니다. filter 를 사용하여 measurement 는 상품수를 저장한 "collection" 을 사용합니다. 추가적인 filter 를 사용하여 count 이 외에 저장한 field가 있어서 설정을 하였습니다. tag를 사용하여 서비스 별로 name으로 구분하기 때문에 "기준상품" 을 선택했습니다. aggregateWindow 집계함수를 사용하여 every: 1d 1일간, fn: max 최대값을 사용하도록 했습니다. map을 사용하여 count로 저장된 이름을 "기준 상품 수"로 변경하였습니다. 위에 쿼리로 구성한 그래프 입니다. * start_time 설정 grafana 대시보드 설정(Settings)에서 Variable

최현복 2021.04.09. 검색 운영을 하면서 다양한 정보를 한 페이지로 모니터링 할 수 있는 시스템을 구축하였습니다. 다양한 프로그램과 서비스를 운영하다 보면 현재 상태와 과거의 추이를 한번에 확인하고 모니터링 하기가 쉽지 않습니다. 검색API 또는 검색엔진, 동적색인의 현재 상태를 파악하기 위해서는 각 서비스에 특화된 모니터링 툴을 사용해서 확인해야 했습니다. 그리고 하루 하루 쌓이는 통계 데이터를 저장하고, 기간에 따른 추이를 보기 위해서 사람이 직접 데이터를 다루는 과정이 필요했습니다. 이러한 불편함을 개선하고자 다양한 로그를 시계열로 분석하여 한 곳으로 모으고 시각화 까지 하는 작업을 진행하였습니다. 검색 모니터링 시스템에는 색인된 상품 수, 동적색인 소요 시간, 동적색인 량, 동적색인 대기 메세지 수, 검색량, 검색속도 데이터를 분, 시간, 일 단위로 현재 상태와 추이를 모니터링을 할 수 있습니다. 로그 스크랩 (golang) 모니터링에 추가할 프로그램의 로그를 실시간으로 수집하여 지정한 시간 단위 데이터로 가공해서 api로 제공합니다. - 검색API, 동적색인 매트릭 스케줄러 (golang) 로그 스크랩 API, ElasticSearch API, rabbitmq API 를 설정한 시간 단위로 호출하여 influxDB에 저장합니다. influxDB : 저장 시계열 데이터베이스로 타임 스탬프 데이터 전용으로 작성된 맞춤형 고성능 데이터 저장소 입니다. 기존에 활용하던 prometheus 는 시계열의 그룹화에 한계가 있으므로 influxDB로 변경하게 되었습니다. grafana : 시각화 시각화는 기존에 사용하던 grafana를 사용했습니다. chronograf 보다는 다양하고 유연한 대시보드에 사용하기 좋습니다. 구성도 로그 스크랩 로그 스크랩은 다양한 로그를 실시간으로 수집하여 지정한 시간 단위로 데이터를 가공하여 API로 제공합니다. 다양한 로그를 동시에 수집할 수 있도록 고루틴(Goroutine)을 사용하고, 동기화 문제를 해결하기 위해서 sync.Map{} 을 사용하였습니다. 로그 수집에 대한 확장성을 고려하여 신규로 수집하고 싶은 로그에 대해서는 parser만 추가하면 되도록 구성했습니다. 설정 내용) 큐 인덱스의 로그와 검색API 로그를 수집하여 지정된 시간 단위로 가공하여 제공하는 API 설정 내용입니다. logs[]는 수집할 로그의 단위입니다. type은 로그의 parser를 구분하는 설정값 입니다. path, file은 경로와 파일명이며, unit은 API로 가공하고 제공될 시간의 단위 데이터입니다. { "port": 9000, "logs": [ { "type": "indexer", "path": "queue-index/logs", "file": "application.log", "unit": "Minutes" }, { "type": "searchapi", "path": "searchapi_node1/logs", "file": "access.log", "unit": "Hours" }, { "type": "se

성능 테스트는 모든 LINE 서비스에서 없어서는 안되는 필수 과정입니다. 하지만 다음과 같은 이유로 성능 테스트의 환경을 설정하고 관리하는 작업이 항상 쉽고 효율적인 것은 아닙니다. 먼저, 기능과 컴포넌트, 이벤트 등에 따라 서버 워크로드의 기준이 다릅니다. 컴포넌트의 종류나 이벤트의 규모에 따라 해당 기능의 성능 기준이 달라지기 때문에 RPS(Request Per Second) 역시 천차만별입니다. 또한, 대부분의 오픈소스 성능 툴에는 다수의 테스트 실행자(executor)를 통제하거나 테스트별 결과 보고서를 통합해 주는 기능이 없습니다. 테스터가 직접 단계 별로 테스트를 진행하고 성능 테스트 스크립트를 실행하기에 적합한 수준의 장비를 찾아야 합니다. 이를 위해 신규 장비 할당과 필요한 라이브러리 설치, 스크립트 업로드, 스크립트가 테스트 장비에 과부하가 걸리지 않는 범위에서 필요한 워크로드를 생성하는지 확인하기 위한 여러 번의 시도를 거쳐야 합니다. 두 번째로 서비스나 팀별로 성능 테스트 환경이 다릅니다. 워크로드 기준 및 릴리스 일정이 다르기 때문에 대만에 위치한 각 팀이나 서비스는 워크로드 장비와 InfluxDB, Grafana 대시보드 등 자체적으로 성능 테스트 환경을 관리합니다. 기능적인 면에서 거의 동일한 서버를 팀별로 각각 설정하고 관리하는 것은 매우 번거로울 뿐만 아니라 개발자 경험 측면에서도 부정적입니다. 세 번째로 장비 사용률이 매우 낮습니다. 대규모 성능 테스트는 그리 빈번하게 발생하지 않습니다. 보통 신규 기능을 구현하거나 구조적인 변경이 발생한 경우에만 시행합니다. 자주 발생하지 않는 테스트를 위해 각 팀에 서버를 할당하면 전체 사용률은 매우 낮으면서 유지 보수 자원은 각각 필요합니다. 마지막으로 통합된 모니터링 대시보드가 없습니다. 성능을 테스트하기 위해서는 테스트 실행 자원과 서버 자원 모니터링이 동시에 필요합니다. 예전에는 한 명의 엔지니어가 데스크톱 창에 여러 개의 터미널 콘솔을 실행해 놓고 CPU와 메모리, 디스크, 네트워크 I/O 등을 모니터링하는 명령어를 실행했습니다. 이런 방식은 설정도 쉽지 않지만 테스트 시행 결과를 통합하고 관리하기도 어렵습니다. 이번 글에서는 Jenkins Kubernetes 플러그인의 동적 자원 관리를 이용해 위에서 언급한 문제를 해결할 수 있는 방법에 대해 이야기해 보겠습니다. LINE Taiwan에서는 대부분 k6를 테스트 툴로 사용하기 때문에 글의 내용은 k6를 기반으로 하고 있지만 다른 툴을 사용하는 경우에도 큰 차이는 없을 거라고 생각합니다. 아키텍처 다이어그램 핵심은 각 팀이 인프라 설정이나 관리에 따로 신경 쓰지 않으면서 성능 테스트 스크립트를 실행할 수 있도록 Jenkins의 Kubernetes 플러그인을 이용한 플랫폼을 준비하는 것입니다. 단일 장비에서 컴퓨팅 자원과 네트워크 대역폭에 부하를 걸어 테스트하는 대신 해당 플랫폼을 통해 클러스터에서 가용 가능한 노드에 워크로드를 균등하게 분배합니다. 이를 통해 실제와 가까운 시나리오를 실행할 수 있습니다. 플랫폼

안녕하세요. 사람인HR IT연구소 SE팀 박용철입니다. SE팀은 사람인HR에서 제공하는 서비스의 전반적인 인프라 구성/운영/관제를 담당하며 서비스가 안정적으로 운영이 되도록 모니터링을 하기 위해 다양한 오픈소스툴을 활용하거나 필요에 따라 직접 개발하기도 합니다. 이번 포스팅은 IDC 의 서비스트래픽 모니터링을 위해 오랜기간 사용중이던 cacti 에서 telegraf, grafana, influxdb 를 활용한 사례를 공유하고자 합니다.2018년 11월경에 응답속도가 느려지거나 정상적으로 연결되지 않는 현상이 짧게는 수초동안 길게는 몇분간 간헐적으로 발생한 적이 있었습니다.서버 부하등 시스템상으로도 특이사항이 없다5분단위로 수집되는 트래픽도 특이 사항이 없다IDC 에서 제공해주는 트래픽 차트에도 트래픽과부하는 아니다10초 주기 웹사이트 관제의 경우 메인라인을 통해 접근되는 부분만 응답속도가 느리거나 7초후 timeout 이 발생짧은 시간동안 발생한 경우는 인지하지 못했거나 1분내외로 발생한 경우 일시적인 문제인가 등 그냥 지나쳐버린 경우도 있었을것입니다. 당시 저 는 여기저기 흩어져있던 모니터링화면이 한곳에 집중되어 있길 원했고 그중 스위치트래픽모니터링과 관련된 부분을 먼저 작업중이었는데 차트를 확인하던 중 cacti 와는 조금 다르게 보이는 부분이 있었습니다.극단적인 예이긴 하지만 만약 5분중에 2분30초간 1Gbps 트래픽이 발생한다고 가정할 경우 아래와 같은 형태일것입니다.5분간격의 평균과 1분간격의 평균일때 나오는 수치에 큰 차이가 있습니다. 1G 회선의 경우 5분간격의 평균일 경우 트래픽과부하 현상을 인지하지 못하게 되는 문제가 있습니다. 지난 이슈중 일부는 이런 이유로 인해 인지가 늦어진 부분이 있었고 트래픽과부하와 관련됬을거라고 추정은 됬지만 기존 관제의 수치상으로는 트래픽과부 하라고 단정하기는 어려운 점이 있었습니다. 이에 수집주기는 짧고 평균을 위한 시간범위도 크지 않게 하면서 트래픽과부하가 발생한 포트에 어떤 장비가 연결되어 있는지에 대한 알림까지 받았으면 좋겠다는 생각이 들었습니다.바꾸자!!기존에 수집하던 데몬도 있었지만 가능하면 기존 오픈소스의 가능을 최대한 활용하고 부족한 부분만 채워넣는 형태로 준비했습니다.telegraf다양한 플러그인을 제공하는 모니터링 및 지표 수집 에이전트influxdb오픈소스 시계열 데이터베이스로 SQL 계열 언어 를 제공grafana시계열 메트릭데이터나 로그등의 데이터를 시각화할 수 있도록 대시보드를 제공해주는 Visualization Tool사전작업telegraf 가 snmp 프로토콜을 이용 하여 metric 데이터를 가져올 수 있도록 네트워크장비에 snmp 설정을 합니다 (예: cisco 장비)snmp-server community __SNMPCOMMUNITY__ RO SARAMIN_ACL이후에는 linux 서버에서 아래의 명령으로 테스트가 가능합니다snmptable -v2c -c __SNMPCOMMUNITY__ __SNMPHOST__ IF-MIB::ifXTable구성 설정telegra