아래는 QuickBuild 모니터링을 위한 종합적인 Grafana 대시보드 JSON 파일. 이 대시보드는 시스템 리소스, 빌드 메트릭, 로그 이벤트 등을 한눈에 확인할 수 있도록 구성. ```json { "annotations": { "list": [ { "builtIn": 1, "datasource": "-- Grafana --", "enable": true, "hide": true, "iconColor": "rgba(0, 211, 255, 1)", "name": "Annotations & Alerts", "target": { "limit": 100, ..
운영자 관점에서 꼭 확인해야 할 핵심 항목 중심1. Splunk 서비스 상태 확인# splunkd 서비스 상태 확인 (Splunk 실행 여부)$ sudo /opt/splunk/bin/splunk status# 실행/중지/재시작$ sudo /opt/splunk/bin/splunk start$ sudo /opt/splunk/bin/splunk stop$ sudo /opt/splunk/bin/splunk restart기본 설치 경로는 /opt/splunk/입니다. Splunk Universal Forwarder라면 /opt/splunkforwarder/로 바뀝니다. 2. 포트, 프로세스 확인# splunkd 포트 (기본: 8089), 웹 포트 (기본: 8000) 확인$ sudo netstat -tulnp | ..
Ubuntu 서버에서 QuickBuild 점검 및 로그 확인을 위한 주요 항목과 명령어 Ubuntu 서버에서 QuickBuild를 운영 중일 때, 상태 점검과 로그, 이벤트 등을 확인하는 주요 항목과 그에 맞는 구체적인 명령어를 아래에 정리해 줄게. 서비스 점검, 리소스 사용량, 로그 확인, 네트워크 상태 등을 포함해서 "실무 기준 체크리스트"처럼 정리해봤어.1. QuickBuild 서비스 상태 확인# 시스템 서비스로 등록한 경우sudo systemctl status quickbuild# 프로세스 직접 확인 (포트 8810 사용 여부 포함)ps -ef | grep quickbuildlsof -i :8810 2. 로그 파일 확인# 기본 경로는 QUICKBUILD_HOME/logstail -f /opt/qu..
QuickBuild의 configuration.log 파일을 생성하는 "코드"에 대해 설명.결론부터 말씀드리면, 사용자가 직접 볼 수 있는 단일 스크립트나 코드 파일은 없습니다. 해당 로그는 QuickBuild 서버 애플리케이션의 핵심 로직(컴파일된 Java 코드)에 의해 생성.하지만 어떻게, 왜, 그리고 어떤 형식으로 로그가 생성되는지 그 원리를 이해하는 것이 중요. 이 원리를 알면 로그를 더 잘 파싱하고 활용할 수 있다.configuration.log 생성 원리: Log4j 로깅 프레임워크QuickBuild는 Java로 만들어진 애플리케이션이며, 내부적으로 매우 유명한 로깅 프레임워크인 Apache Log4j를 사용.즉, QuickBuild의 소스 코드 내에는 다음과 같은 형태의 "로그를 남겨라"는 ..
QuickBuild 로그는 보통 텍스트 파일 형태이므로, Grafana가 직접 읽을 수 없다. 따라서 중간에 로그를 수집하고 저장하는 시스템이 필요. 가장 인기 있고 Grafana와 궁합이 잘 맞는 조합은 Loki와 Promtail.전체 프로세스 아키텍처QuickBuild 서버: configuration.log 파일을 생성.Promtail (로그 수집기): QuickBuild 서버에서 로그 파일을 읽어와 파싱(Parsing)한 후 Loki로 전송.Loki (로그 저장소): Promtail로부터 받은 로그를 저장하고, Grafana가 쿼리할 수 있도록 API를 제공.Grafana (시각화 도구): Loki를 데이터 소스로 연결하여, LogQL이라는 쿼리 언어를 사용해 데이터를 조회하고 대시보드로 시각화.1..
신규 입사자가 성공적으로 팀에 안착하고, 빠르게 성장하는 과정을 구체적인 행동 중심으로 정리한 사례. 이 단계를 따라가시면 막연함을 없애고 체계적으로 업무를 파악할 수 있다.Phase 1. 첫 1주차: 생존 및 관찰 (Survival & Observation)목표: 팀의 '언어'와 '지도'를 익히고, 질문할 기반을 마련한다.모범 사례 1: '액세스 생존 키트' 확보 및 환경 설정행동: 입사 첫날, 사수/선임에게 **"업무에 필요한 계정, 시스템, 개발 도구 목록을 요청"**구체적 항목:계정: Git(GitLab/GitHub), Jira/Redmine(이슈 트래커), Confluence(위키), 사내 클라우드(SCP 등), Nexus/Artifactory(라이브러리 저장소) 접근 계정.권한: 개발 서버..
새로운 업무에 빠르게 적응하고 전문가로 성장하기 위한 업무 파악 방법과 핵심 기술 스택 키워드 정리Part 1. 효과적인 업무 파악 방법 (단계별 접근)성공적인 온보딩을 위해 'Top-Down' (전체 숲 보기)과 'Bottom-Up' (개별 나무 보기) 방식을 병행하는 것이 중요1단계: 숲 보기 (Big Picture & Business Context)기술에 바로 뛰어들기 전에, 이 플랫폼이 왜 존재하고, 누구를 위해, 어떤 가치를 제공하는지 이해하는 것이 최우선목표 이해 (Purpose):"플랫폼의 핵심 목표는 무엇인가?" (예: 개발 생산성 향상, 배포 시간 단축, 품질 표준화)주요 고객은 누구인가? (사내 개발팀, 특정 사업부, 외부 고객 등)고객(사용자)들이 겪는 가장 큰 어려움(Pain Poi..
Workflow Template은 여러 Job Template들을 엮어서 하나의 큰 작업 흐름으로 만든다. 마치 플로우차트처럼 성공/실패에 따라 다른 단계를 실행할 수 있다. Workflow Template 구성은 AWX UI에서 그래픽하게 이루어지므로, 여기서는 각 노드가 될 수 있는 Playbook의 특징이나 Workflow의 개념적 흐름을 코드로 확인 한다.환경 준비 및 검증 (첫 단계)Workflow의 시작점에서 인프라 상태, 의존 서비스 가용성 등을 체크. 실패 시 Workflow를 중단시켜 불필요한 배포 시도를 막는다. # wf_node_01_prepare_env.yml- name: 배포 환경 준비 및 검증 hosts: all # 또는 특정 검증 서버 그룹 gather_facts:..