prometheuspushgatewayalertmanagersystemdlinuxinstallation

Prometheus 설치하기 — Linux에 Prometheus·Pushgateway·Alertmanager 올리고 systemd로 운영하기

Linux에 Prometheus, Pushgateway, Alertmanager를 바이너리로 설치하고 systemd 서비스로 등록하는 방법을 정리합니다. 전용 사용자·디렉터리 구성, 세 컴포넌트의 unit 파일, 그리고 핵심 실행 옵션 — 특히 바인딩 IP를 정하는 --web.listen-address — 를 자세히 다룹니다.

Data Dynamics2026년 6월 12일13 min read

새 서버에 모니터링 스택을 올리는 일은 생각보다 단순합니다. Prometheus 생태계는 단일 정적 바이너리로 배포되어, 패키지 매니저 없이 tarball 만 받아 풀면 끝이거든요. 운영은 systemd 에 맡기면 됩니다. 이 글은 Prometheus · Pushgateway · Alertmanager 세 컴포넌트를 Linux 에 올리고, systemd 서비스로 등록하고, 꼭 알아야 할 실행 옵션 — 특히 바인딩 IP 주소 — 를 짚는 실전 가이드입니다.

이 글에서 배우는 것

설치 방식과 표준 디렉터리 구조, 전용 사용자를 만드는 이유

Prometheus / Pushgateway / Alertmanager 각각 설치하는 방법

세 컴포넌트의 systemd unit 파일 작성법

핵심 실행 옵션과 --web.listen-address(바인딩 IP) 의 선택 기준

셋을 연결하고 동작 확인 + systemd 보안 하드닝

1. 설치 방식과 디렉터리 구조

배포판 패키지도 있지만, 공식 바이너리(tarball) 설치가 버전 통제가 쉽고 가장 권장됩니다. 어떤 버전이 어느 경로에 있는지 완전히 제어할 수 있거든요. 표준 레이아웃을 먼저 정해두면 unit 파일이 깔끔해집니다.

용도	경로
실행 바이너리	`/usr/local/bin/`
설정 파일	`/etc/prometheus/`, `/etc/alertmanager/`
데이터(TSDB·상태)	`/var/lib/prometheus/`, `/var/lib/alertmanager/`, `/var/lib/pushgateway/`
실행 계정	전용 시스템 사용자 `prometheus` (로그인 불가)

기본 포트는 Prometheus 9090 · Pushgateway 9091 · Alertmanager 9093(클러스터 9094)입니다. 방화벽 설정을 미리 계획해 두는 것이 좋습니다.

2. 공통 사전 준비 — 전용 사용자와 디렉터리

데몬을 루트로 돌리는 것은 위험합니다. 혹시라도 취약점이 있으면 시스템 전체가 위험에 노출되기 때문입니다. 로그인 불가 시스템 계정을 만들어 권한을 최소화하고, 디렉터리도 미리 준비합니다.

# 전용 시스템 사용자(홈·셸 없음)
sudo useradd --system --no-create-home --shell /usr/sbin/nologin prometheus
 
# 설정·데이터 디렉터리
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo mkdir -p /etc/alertmanager /var/lib/alertmanager
sudo mkdir -p /var/lib/pushgateway
 
sudo chown -R prometheus:prometheus /var/lib/prometheus /var/lib/alertmanager /var/lib/pushgateway

3. Prometheus 설치

이제 본체를 설치할 차례입니다. prometheus.io/download 에서 최신 버전 번호를 확인한 뒤(아래 VERSION 을 교체), tarball 을 받아서 바이너리와 기본 설정을 배치합니다.

VERSION=3.2.1     # 최신 안정 버전으로 교체
cd /tmp
curl -LO https://github.com/prometheus/prometheus/releases/download/v${VERSION}/prometheus-${VERSION}.linux-amd64.tar.gz
tar xzf prometheus-${VERSION}.linux-amd64.tar.gz
cd prometheus-${VERSION}.linux-amd64
 
# 바이너리
sudo cp prometheus promtool /usr/local/bin/
 
# 기본 설정 (없을 때만)
sudo cp prometheus.yml /etc/prometheus/prometheus.yml
sudo chown -R prometheus:prometheus /etc/prometheus

promtool 은 설정·규칙 검증 도구입니다. Prometheus 와 함께 설치해 두면 나중에 알림 규칙 검증할 때 유용합니다.

4. Pushgateway 설치

VERSION=1.11.0    # 최신 버전으로 교체
cd /tmp
curl -LO https://github.com/prometheus/pushgateway/releases/download/v${VERSION}/pushgateway-${VERSION}.linux-amd64.tar.gz
tar xzf pushgateway-${VERSION}.linux-amd64.tar.gz
sudo cp pushgateway-${VERSION}.linux-amd64/pushgateway /usr/local/bin/

5. Alertmanager 설치

VERSION=0.28.0    # 최신 버전으로 교체
cd /tmp
curl -LO https://github.com/prometheus/alertmanager/releases/download/v${VERSION}/alertmanager-${VERSION}.linux-amd64.tar.gz
tar xzf alertmanager-${VERSION}.linux-amd64.tar.gz
cd alertmanager-${VERSION}.linux-amd64
 
sudo cp alertmanager amtool /usr/local/bin/
sudo cp alertmanager.yml /etc/alertmanager/alertmanager.yml
sudo chown -R prometheus:prometheus /etc/alertmanager

각 컴포넌트는 버전 번호가 서로 다릅니다(Prometheus·Pushgateway·Alertmanager 가 독립 릴리스). 이 점은 처음에 헷갈릴 수 있으니, 다운로드 시 각자의 최신 버전을 따로 확인하세요.

6. systemd 서비스 등록

바이너리를 깔았으면 systemd 에 서비스로 등록해야 재부팅해도 자동으로 뜹니다. 세 개의 unit 파일을 만듭니다. ExecStart 의 옵션 의미는 다음 장에서 자세히 설명합니다.

/etc/systemd/system/prometheus.service:

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target
 
[Service]
User=prometheus
Group=prometheus
Type=simple
Restart=on-failure
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --storage.tsdb.retention.time=30d \
  --web.listen-address=0.0.0.0:9090 \
  --web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
 
[Install]
WantedBy=multi-user.target

/etc/systemd/system/pushgateway.service:

[Unit]
Description=Prometheus Pushgateway
Wants=network-online.target
After=network-online.target
 
[Service]
User=prometheus
Group=prometheus
Type=simple
Restart=on-failure
ExecStart=/usr/local/bin/pushgateway \
  --web.listen-address=0.0.0.0:9091 \
  --persistence.file=/var/lib/pushgateway/metrics \
  --persistence.interval=5m
 
[Install]
WantedBy=multi-user.target

/etc/systemd/system/alertmanager.service:

[Unit]
Description=Prometheus Alertmanager
Wants=network-online.target
After=network-online.target
 
[Service]
User=prometheus
Group=prometheus
Type=simple
Restart=on-failure
ExecStart=/usr/local/bin/alertmanager \
  --config.file=/etc/alertmanager/alertmanager.yml \
  --storage.path=/var/lib/alertmanager \
  --web.listen-address=0.0.0.0:9093 \
  --cluster.listen-address=
ExecReload=/bin/kill -HUP $MAINPID
 
[Install]
WantedBy=multi-user.target

등록·기동:

sudo systemctl daemon-reload
sudo systemctl enable --now prometheus pushgateway alertmanager
sudo systemctl status prometheus
journalctl -u prometheus -f      # 로그 추적

7. 중요한 옵션 — 특히 바인딩 IP

바인딩 IP: `--web.listen-address`

옵션 중에서 가장 먼저 챙겨야 할 것이 바로 이것입니다. Prometheus 계열 컴포넌트는 기본적으로 인증이 없습니다. 따라서 어느 IP 에 바인딩하느냐가 곧 보안의 첫 번째 선입니다. 세 컴포넌트 모두 HTTP 서버가 어느 IP·포트에 바인딩할지를 --web.listen-address 로 정합니다. 형식은 호스트:포트 이며, 호스트 부분이 곧 바인딩 대상 인터페이스입니다.

--web.listen-address=0.0.0.0:9090     # 모든 인터페이스 (기본값 성격) — 어디서든 접속 가능
--web.listen-address=127.0.0.1:9090   # 로컬호스트 전용 — 같은 서버에서만 접속
--web.listen-address=10.0.0.5:9090    # 특정 NIC/IP 에만 바인딩 — 내부망 IP 만 노출
--web.listen-address=:9090            # 호스트 생략 = 모든 인터페이스 (0.0.0.0 과 동일)
--web.listen-address=[::1]:9090       # IPv6 로컬호스트

선택 기준:

0.0.0.0(모든 인터페이스) — 가장 열려 있음. 공인 IP 가 붙은 서버라면 그대로 두면 외부에 그대로 노출됩니다. Prometheus·Pushgateway·Alertmanager 는 기본적으로 인증이 없으므로 위험합니다.
127.0.0.1(로컬호스트) — 같은 호스트의 리버스 프록시(Nginx 등) 뒤에 두고, 프록시에서 TLS·인증을 처리할 때 적합합니다.
특정 내부 IP(10.0.0.5) — 관리망/사설망 NIC 에만 노출하고 공인 NIC 로는 닫고 싶을 때.

보안 권고: 운영 환경에서는 내부 IP 또는 127.0.0.1 로 바인딩 + 방화벽을 기본으로 하고, 외부 접근이 필요하면 리버스 프록시(TLS·인증)를 앞에 두세요. Prometheus 계열은 --web.config.file 로 네이티브 TLS·basic auth 도 지원합니다.

Alertmanager의 두 번째 바인딩: `--cluster.listen-address`

Alertmanager 는 바인딩 포트가 두 개입니다. HTTP UI/API 용 --web.listen-address 외에, HA 클러스터 간 가십 통신용 --cluster.listen-address(기본 0.0.0.0:9094) 를 따로 가집니다.

단일 노드라면 클러스터링이 필요 없으니 빈 값으로 비활성화: --cluster.listen-address=
다중 노드(HA) 라면 각 노드의 IP 로 바인딩하고 --cluster.peer=<다른노드:9094> 로 서로를 가리킵니다.

그 밖의 핵심 옵션

컴포넌트	옵션	의미
Prometheus	`--config.file`	설정 파일 경로
Prometheus	`--storage.tsdb.path`	TSDB 데이터 디렉터리
Prometheus	`--storage.tsdb.retention.time`	보존 기간(기본 15d). 예: `30d`
Prometheus	`--storage.tsdb.retention.size`	보존 용량 상한. 예: `50GB`
Prometheus	`--web.enable-lifecycle`	HTTP 로 `/-/reload`·`/-/quit` 허용
Prometheus	`--web.external-url`	리버스 프록시 뒤 외부 URL
Pushgateway	`--persistence.file`	재시작 후에도 메트릭 유지(파일 경로)
Pushgateway	`--persistence.interval`	영속화 주기(기본 5m)
Alertmanager	`--storage.path`	알림 상태(silence 등) 저장 경로
Alertmanager	`--data.retention`	상태 보존 기간(기본 120h)

--web.enable-lifecycle 를 켜두면 설정 변경 후 재시작 없이 리로드할 수 있습니다.

curl -X POST http://localhost:9090/-/reload

8. 세 컴포넌트 연결

각각 뜨고 있다고 끝이 아닙니다. Prometheus 가 Pushgateway 를 긁고, Alertmanager 로 알림을 보내고, 규칙 파일을 읽도록 prometheus.yml 을 구성해야 합니다.

global:
  scrape_interval: 15s
  evaluation_interval: 15s
 
rule_files:
  - "/etc/prometheus/rules/*.yml"
 
alerting:
  alertmanagers:
    - static_configs:
        - targets: ["127.0.0.1:9093"]
 
scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["127.0.0.1:9090"]
 
  - job_name: "pushgateway"
    honor_labels: true             # 푸시된 job/instance 라벨 보존(필수)
    static_configs:
      - targets: ["127.0.0.1:9091"]

설정 후 검증 → 리로드:

promtool check config /etc/prometheus/prometheus.yml
curl -X POST http://localhost:9090/-/reload

9. 동작 확인

모두 올라갔다면 각 컴포넌트가 정상인지 확인해 봅시다. 각 컴포넌트는 헬스/레디 엔드포인트를 제공합니다.

curl -s http://localhost:9090/-/healthy     # Prometheus
curl -s http://localhost:9090/-/ready
curl -s http://localhost:9091/-/healthy     # Pushgateway
curl -s http://localhost:9093/-/healthy     # Alertmanager
 
# 리슨 중인 포트 확인
sudo ss -ltnp | grep -E '9090|9091|9093'

브라우저로 http://<서버IP>:9090 (Prometheus), :9091(Pushgateway), :9093(Alertmanager) 에 접속해 UI 를 확인합니다. Prometheus 의 Status → Targets 에서 타깃이 모두 UP 이면 정상입니다.

10. (보강) systemd 하드닝

전용 사용자로 실행하는 것만으로도 많이 안전해지지만, 한 걸음 더 나아갈 수 있습니다. systemd 보안 옵션으로 데몬의 파일시스템 접근을 더 좁히면 좋습니다. [Service] 섹션에 추가합니다.

NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/prometheus      # 데이터 디렉터리만 쓰기 허용

ProtectSystem=strict 은 시스템 전체를 읽기 전용으로 만들므로, 데이터 디렉터리만 ReadWritePaths 로 예외 처리하는 것이 핵심입니다. (Pushgateway·Alertmanager 도 각자의 데이터 경로로 동일하게.)

마무리

Prometheus 스택 설치는 결국 바이너리 배치 → 전용 사용자·디렉터리 → systemd unit → 옵션 튜닝 의 반복입니다. 특히 운영에서 가장 먼저 점검할 것은 바인딩 IP입니다. 기본 인증이 없는 컴포넌트들이므로, --web.listen-address 를 127.0.0.1 이나 내부 IP 로 좁히고 방화벽·리버스 프록시(TLS·인증)를 앞세우는 것이 안전한 출발점입니다.

다음 단계로는 이 위에 node_exporter 같은 익스포터를 붙이고, 앞선 글들에서 다룬 알림 규칙(Alert Rule)과 Alertmanager 라우팅을 연결해 "수집 → 알림 → 통지" 파이프라인을 완성해 보길 권합니다.

마치며 — 핵심 요약

Prometheus 스택은 정적 바이너리 하나라 패키지 매니저 없이 tarball 만 받아 풀면 됩니다.
반드시 전용 시스템 계정(prometheus)으로 실행하고 루트 권한을 주지 마세요.
--web.listen-address 가 핵심 보안 옵션입니다. 운영에서는 0.0.0.0 대신 127.0.0.1 이나 내부 IP 로 좁히세요.
Alertmanager 단일 노드 운영 시 --cluster.listen-address= (빈 값)로 클러스터 포트를 비활성화하세요.
--web.enable-lifecycle 를 켜두면 재시작 없이 설정을 리로드할 수 있습니다.
systemd 하드닝(ProtectSystem=strict, ReadWritePaths 등)을 추가하면 데몬의 파일시스템 접근을 최소화할 수 있습니다.