Category: HowTo

Time-Series data 특징

Time-Series 데이터베이스가 존재한다. InfluxDB, Prometheus 등이 대표적인데 Time-Series 데이터베이스의 특징에 대해서 정리 본다.

  1. High-speed data ingest: ‘고속 데이터 수집’ 으로 번역된다. IoT 사용 사례나 시장 분석 데이터와 같이 꾸준히 고속으로 도착하는 연속된 혹은 한꺼번에 밀려드는 대량의 데이터를 처리해야 한다. 대부분의 솔루션들은 데이터를 24시간 365일 처리하도록 되어 있다.
  2. Immutable data: ‘변경될 수 없는 데이터’ 로 번역된다. Immutable 은 프로그래밍에서도 자주 언급되는 단어다. 데이터베이스에 한번 Insert가 되면 데이터 포인트는 데이터가 만료(expire) 되거나 삭제(delete) 되기전까지 그 어떠한 변경도 일어나지 않는다. 이런 데이터는 전통적으로 timestamp 와 아주 적은 데이터 포인트를 가지는 로그 데이터들이다.
  3. Unstructured labels: Time-series 데이터는 일반적으로 많은 소스들에 의해서 오랜 기간 동안 지속적으로 생산되어진다. 예를들어, Iot 경우에, 모든 센서들은 time-series 데이터의 소스다. 이런 상황에서, 시리즈의 각 데이터 포인트들은 소스 정보와 라벨로 다른 센서의 측정치들을 저장한다. 모든 소스들의 데이터 라벨들은 같은 구조나 순서들을 보장하지 않는다.
  4. Diminishing value over time: ‘시간이 지남에 따라 가치가 낮아진다’ 정도로 번역할 수 있겠다. 적절한 시간 범위를 가진 집계된 요약 데이터만이 미래에 연관성이 있을 수 있다. 1년 후에, 대부분의 사용자들은 마이크로초 단위의 범위에 저장된 모든 데이터 포인트를 필요로하지 않을 것이다. 오직 수분, 수시간, 몇일동안 집계되어지고 정형화된 데이터만이 필요로하게 된다.
  5. Queries are aggregated by time intervals: time-series 데이터에 기반한 차트는 확대/축소를 가능하게 한다. 이건 시간 간격에 의해서 그들이 데이터를 수집함으로써 그렇게 할 수 있다. 전통적으로, time-series 데이터 쿼리는 집계들이다. 이것은 데이터베이스 시스템으로부터 개별적인 레코드들을 검색하는 것과 대비된다.

DNF 사용하기

CentOS 8 로 넘어오면서 기본 패키지 매니지먼트로 dnf 가 되었다. 여전히 yum 을 지원하지만 앞으로는 dnf 로 쭉 간다고 하니 이참에 배워보자고 생각하지만….

겁나 빡치는게, 이제 그만 바꿨으면 한다. 뭔 yum 정도로도 충분히 잘 쓰고 있고 괜찮다고 싶다. 무슨 겁나 가볍네, 더 빠르네 어케 좋네… 응 yum 도 그렇게 느리고 그렇게 무겁지도 않아! 도대체 뭘 할때마다 갈아 엎고 이걸 새로 배우라고 하니.. 뭐 어쩌것나.. 그렇게 하겠다는데, 닥치고 배워야지!

dnf

햐.. 쓰기도 귀찮다… “DNF is the next upcoming major version of YUM, a package manager for RPM-based Linux distributions” 이렇게 맨 페이지에 설명이 나온다.

사용법

사용법은 아주 간단하다. yum 의 기본 사용법은 대동소이하다고 하겠다.

dnf사용법
ZSH
1
2
3
4
5
6
7
8
9
10
]# dnf check-update
]# dnf update
]# dnf install kernel
]# dnf remove kernel
]# dnf info kernel
]# dnf clean all
]# dnf history
 
]# dnf repolist
]# dnf repoinfo

이정도만 알아도 패키지를 다루는데는 문제가 없을 것이다.

Ubuntu, systemd-networkd 전환하기

Ubuntu 16.04 로 넘어오면서 SysV 의 Init 이 Systemd 로 변경되었다. 이런 변화에는 Network 관리에도 적용되고 있는데, 이에 대해서 알아보자.

기존의 Network 관련된, 정확하게는 Network Interface 와 관련된 일은 NetworkManager 가 담당했다. Network Interface 가 무엇인지, 아이피는 DHCP 혹은 Static 인지 등이 그것이다.

하지만 Ubuntu 16.04 로 넘어오면서 시스템에 관련된 일체가 systemd 로 통합되면서 네트워크 관련 작업도 systemd 로 통합되어지게 되는데, 이것이 systemd-networkd 이 이다.

하지만 Ubuntu 18.04 로 넘어온 시점에서도 NetworkManger 는 이전과 호환을 위해서 살려뒀고 살려둔김에 지금도 기본적인 네트워크 설정 프로그램으로 활약(?) 하고 있다.

Network Manager

Network Manager 의 동작은 다음의 명령어로 이루어진다.

NetworkManager사용법
ZSH
1
]# systemctl start/stop/status NetworkManger

관련 설정은 /etc/NetworkManger/NetworkManger.conf 파일이다. 위 프로그램을 실행하게 되면 기본적으로 이 파일을 읽게 되어 있다.

그리고 netplan 설정에서도 NetworkManager 를 기본으로 지정하도록 되어 있다.

Netplan설정
YAML
1
2
3
4
# 1-network-manager-all.yaml
network:
  version: 2
  renderer: NetworkManager

Network Manager 비활성화

비활성화는 다음과 같이 하면 된다.

1
2
3
]# systemctl stop NetworkManager
]# systemctl disable NetworkManager
]# systemctl mask NetworkManager

이렇게 하면 네트워크가 비활성화 됨으로 절대로 원격지 서버에서 하면 안된다.

systemd-networkd 활성화

1
2
3
]# systemctl unmask systemd-networkd.service
]# systemctl enable systemd-networkd.service
]# systemctl start systemd-networkd.service

netplan

systemd-networkd 를 활성화하면 이제 네트워크 작업은 netplan 명령어를 통해서 이루어진다. 이 netplan 명령어는 기본적으로 ‘/etc/netplan’ 디렉토리에 파일을 읽어서 네트워크 설정을 적용해 준다.

‘/etc/netplan’ 디렉토리에 설정파일은 기본적으로 yaml 파일형식을 가진다. 예를 들면 다음과 같다.

1
2
3
4
5
6
7
# 1-network-manager-all.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
   enp4s0:
    dhcp4: yes

파일을 수정한 후에는 다음과 같이 명령어만 주면 적용이 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
/etc/netplan# netplan --debug apply
** (generate:6597): DEBUG: 01:21:41.764: Processing input file /etc/netplan/1-network-manager-all.yaml..
** (generate:6597): DEBUG: 01:21:41.764: starting new processing pass
** (generate:6597): DEBUG: 01:21:41.764: enp4s0: setting default backend to 1
** (generate:6597): DEBUG: 01:21:41.765: Configuration is valid
** (generate:6597): DEBUG: 01:21:41.765: Generating output files..
** (generate:6597): DEBUG: 01:21:41.765: NetworkManager: definition enp4s0 is not for us (backend 1)
DEBUG:netplan generated networkd configuration changed, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:enp4s0 not found in {}
DEBUG:Merged config:
network:
  bonds: {}
  bridges: {}
  ethernets:
    enp4s0:
      dhcp4: true
  vlans: {}
  wifis: {}
 
DEBUG:Skipping non-physical interface: lo
DEBUG:device enp4s0 operstate is up, not changing
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for enp4s0

‘–debug’ 는 제외해도 된다.

Ubuntu 18.04, Static IP 할당하기

Ubuntu 18.04 의 경우 네트워크 인터페이스 관련 작업은 netplan 으로 바뀌었다. 만일 Static IP 를 할당하고 싶다면 netplan 의 설정 파일을 수정하고 적용하면 된다.

/etc/netplan/*.yml

여기서 파일을 수정하면 된다. 대략 다음과 같은 포맷을 갖는다.

1
2
3
4
5
6
7
8
9
10
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
      addresses: [192.168.96.14/20]
      gateway4: 192.168.96.1
      nameservers:
              addresses: [168.126.63.1, 168.126.63.2]

dhcp4: yes 로 되어 있는 경우에는 DHCP 로 아이피를 받아온다. 하지만 이것을 no 바꾸면 Static IP 를 할당할 수 있다.

netplan 적용

수정을 다 했다면 다음과 같이 적용해 준다.

1
2
]# netplan generate
]# netplan apply

Ubuntu 18.04 ethernet 이름 변경하기

Ubuntu 18.04 를 설치하면 ethernet 인터페이스 이름이 과거 eth0 가 아닌 ens3 과 같이 나온다. 하지만 아직도 많은 프로그램들이 기본적으로 eth0 를 기본으로 찾기도 한다. eth0 변경하는 방법에 대해 다룬다.

GRUB 파라메터 수정

다음과 같이 Grub 에 파라메터를 추가 한다. Grub 에 파라메터는 /etc/default/grub 파일에서 다음과 같이 추가할 수 있다.

1
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

수정된 사항이 Grub 에 반영하기 위해서 업데이트를 수행한다.

1
]# update-grub2

여기서 중요한 것이 바로 재부팅을 하면 안된다. 특히나 DHCP 환경에서는 다음의 단계를 수행한 후에 재부팅을 해야 한다.

netplan 수정

netplan 은 Ubuntu 17.04 에서 소개된 기능으로 네트워크 인터페이스 관련 작업을 해준다. 이 프로그램은 /etc/netplan/*.yml 파일을 참조하는데, Ubuntu 18.04 의 경우에 /etc/netplan/01-netcfg.yaml 파일을 참조 한다.

1
2
3
4
5
6
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: yes

eth0 부분이 수정한 것이다. 이렇게 수정을 다 했으면 다음과 같이 명령어를 수행해 준다.

1
]# netplan generate

이렇게 한 후에 재부팅을 하면 DHCP 환경에서 문제 없이 eth0 인터페이스 이름으로 네트워크가 정상 동작한다.

Trac 에서 Ticket 삭제하기

Trac 을 사용하다보면 Ticket 을 삭제하고 싶을때가 있다. Ticket 삭제 플러그인이 존재하지만 Ticket 이란게 자주 삭제를 하는 것이 아니여서 굳이 이것을 설치해서 사용해야할 만큼은 아닌듯 한데, 그런데도 잘못된 Ticket 을 삭제해야한다면 다음과 같이 하면 된다.

1
trac-admin /path/to/env ticket remove ticketID

trac-admin 을 활용하면 된다.

출처: Deleting trac tickets created since a certain date until today

두번째 방법으로 ‘ticket.deleter’ 를 활성화하면 된다. 이는 Trac 에서 공식지원하는 것으로 Ticket 웹화면에서 Reply 버튼 옆에 Delete 버튼이 나타난다. 이를 위해서는 trac.ini 설정파일에 다음과 같이 설정해준다.

1
2
[components]
tracopt.ticket.deleter.* = enabled

Grub2 에 기본 커널 지정하기

Grub2 은 리눅스 시스템의 부팅 메니져이다. 리눅스는 커널을 여러개를 설치하고 부팅시에 선택해서 원하는 커널로 부팅을 할 수 있도록 해준다. 비상 복구가 필요할 경우에도 부팅 메니져인 Grub2 에서 비상복구 모드를 선택하면 된다.

문제는 어떻게 기본 커널을 지정할 수 있을까?

먼저, 기본 부팅 커널은 다음과 같이 확인할 수 있다.

ZSH
1
2
]# cat /boot/grub2/grubenv | grep saved
saved_entry=CentOS Linux (5.0.2-1.el7.elrepo.x86_64) 7 (Core)

만일 부팅 상황이라면 위에 설정한 커널을 기본으로 부팅을 진행하게 된다. 만일 이 기본 커널을 변경하고자 할 경우에는 어떻게 할까?

우선, 현재 Grub2 에 등록된 커널 목록들을 알아야하는데 다음과 같이 하면 알 수 있다.

ZSH
1
2
3
4
5
]# awk -F\' /^menuentry/{print\$2} /etc/grub2-efi.cfg
CentOS Linux (5.0.8-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (5.0.2-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (4.20.11-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (0-rescue-9ee89927656147d5ab3501cc9c85f579) 7 (Core)

커널 목록을 확인할 수 있는데, 맨 위쪽부터 0 을 시작으로 번호를 붙일 수 있다. 이러한 번호는 기본 부팅 커널을 바꾸는데 유용하게 사용된다. 이제 기본 부팅 커널을 다음과 같이 바꿀 수 있다.

ZSH
1
]# grub2-set-default 0

확인을 한번 해보면 다음과 같다.

ZSH
1
2
]# cat /boot/grub2/grubenv | grep saved
saved_entry=0

이렇게 한 후에 다시 Grub 을 설치해줘야 한다.

ZSH
1
]# grub2-mkconfig -o /etc/grub2-efi.cfg

정상적으로 되었다면 기본 부팅 커널이 바꾼 것이다.

systemctl tomcat no bind 8005 port

Tomcat 을 설치하고 난후에 systemd 에 유닛으로 등록하고 나고 서비스를 시작하고 shutdown 을 하려고 할때에 다음과 같은 오류를 만날 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
Feb 26 12:17:40 ubuntu18 systemd[1]: Stopping Apache Tomcat Web Application Container...
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: Feb 26, 2019 12:17:40 PM org.apache.catalina.startup.Catalina stopServer
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: SEVERE: Could not contact [localhost:8005] (base port [8005] and offset [0]). Tomcat may not be running.
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: Feb 26, 2019 12:17:40 PM org.apache.catalina.startup.Catalina stopServer
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: SEVERE: Error stopping Catalina
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]: java.net.ConnectException: Connection refused (Connection refused)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.PlainSocketImpl.socketConnect(Native Method)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
Feb 26 12:17:40 ubuntu18 shutdown.sh[2798]:         at java.net.Socket.connect(Socket.java:589)

8005 포트로 접속을 할 수 없어서 셧다운시에 오류를 발생시키는 것이다. 왜 이런문제가 발생할까? systemd tomcat 유닛의 내용은 다음과 같다.

INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[Service]
Type=forking
 
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_BASE=/home/systemv/was1"
 
ExecStart=/opt/tomcat/bin/catalina.sh start
ExecStop=/opt/tomcat/bin/catalina.sh stop
 
User=systemv
Group=systemv
UMask=0007
RestartSec=10
Restart=on-failure

그리고 이 상태로 다음과 같이 tomcat 을 서비스로 시작 한다.

ZSH
1
]# systemctl start tomcat.service

이렇게 하고 난후에 netstat 명령어로 포트 리스닝 상태를 살펴보면 8005 포트가 보이지 않는다. 더 큰 문제는 shutdown 포트가 올라오지 않으면 Tomcat 이 작동하지 않는데 있다.

해결 방법은 의외로 간단하다. 다음과 같이 systemd tomcat 유닛 파일에 WorkingDirectory 를 CATALINA_BASE 로 해주면 된다.

diff
1
2
3
4
5
6
7
[Service]
Type=forking
 
+ WorkingDirectory=/home/systemv/was1
 
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_BASE=/home/systemv/was1"

이렇게 하게되면 tomcat 이 shutdown 포트까지 올라오면서 정상적으로 다 구동되게 된다.

ps, 이걸 몰라 3시간을 해멧다.

Ubuntu APT Could not get lock /var/lib/dpkg/lock 문제

우분투(Ubuntu) 를 부팅하고 난 후에 로그인을 하면 몇개의 새로운 업데이트가 있는지를 알려준다. 그래서 새로운 패키지 설치를 위해서 ‘apt upgrade’ 명령을 하게 되면 다음과 같은 오류 메시지를 만나곤 한다.

ZSH
1
2
3
# apt upgrade
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

패키지를 설치하는 명령어인 dpkg 명령어가 이미 실행중인 것으로 인해서 실행이 안된다는 것이다. 실행을 할때에 lock 파일을 생성하게 되는데, 이를 근거로 혹시 다른 것이 이미 실행되고 있는건 아닌지 추측하고 있다.

도대체 무슨 일이 벌어지고 있는 걸까? 다른 것이 이미 실행중일지도 모르니까 다음과 같이 프로세스를 체크해 본다.

ZSH
1
2
3
4
# ps aux | grep apt
root      1350  0.0  0.0   4504   736 ?        Ss   20:05   0:00 /bin/sh /usr/lib/apt/apt.systemd.daily install
root      1355  0.0  0.0   4504  1684 ?        S    20:05   0:00 /bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held install
root     12203  0.0  0.0  15504  1008 ttyS0    S+   20:06   0:00 grep --color=auto apt

보아하니 apt.systemd.daily 이것이 apt 명령어를 실행하고 그래서 dpkg 가 이미 실행되고 있는 것으로 보인다.

이것은 아마도 부팅과 동시에 패키지를 업데이트 해주는일을 하는 녀석인 것으로 보이는데, 자동으로 패키지를 업데이트를 해준다니 얼마나 고맙겠냐만은 때로는 어떤 것이 설치되는지를 직접 선택하거나 해야하는 경우에는 자동으로 알아서 해주는것이 큰 위험이 될 수도 있다.

이것을 멈추게 하는 방법이 있다.

ZSH
1
2
3
4
# systemctl disable apt-daily-upgrade.service
# systemctl disable apt-daily-upgrade.timer
# systemctl disable apt-daily.service
# systemctl disable apt-daily.timer

이렇게하면 부팅하면서 자동으로 apt 업데이트를 하는 건 막을 수 있다.

참고,

만일 부팅과장에서 각 서비스별 소비된 시간을 알고 싶다면 다음과 같이 확인해 볼 수 있다.

ZSH
1
2
# systemd-analyze
Startup finished in 2.903s (kernel) + 1min 56.476s (userspace) = 1min 59.379s

이렇게 보면 userspace 로 인한 시간이 1분이 넘어간다. 좀 더 자세하게 보기 위해서는 다음과 같이 확인해 볼수 있다.

ZSH
1
2
3
4
5
6
7
# systemd-analyze blame
    1min 13.990s apt-daily-upgrade.service
         34.654s apt-daily.service
          3.130s dev-sda1.device
          3.002s networking.service
          1.852s apparmor.service
          1.818s snmpd.service

Ubuntu18.04 호스트네임 영구 변경 설정

Ubuntu18.04 에서 호스트네임을 변경하기 위해서는 다음과 같이 해준다.

ZSH
1
]# hostnamectl set-hostname testserv1

이렇게 한 후에 리부팅을 하면 원래 변경전 호스트네임이 나온다. 이럴때 /etc/cloud/cloud.cfg 파일에서 다음과 같이 변경을 해주면 된다.

diff
1
2
- 15 preserve_hostname: false
+ 15 preserve_hostname: true

이렇게 바꾼후에 다음과 같이 로그인 서비스를 재시작 해준다.

ZSH
1
]# systemctl restart systemd-logind.service