회사에서 모니터링을 위해 Datadog를 사용하여 특정 매트릭을 수집하고 있는데, 과금 체계가 조금 독특(?) 해서 토막글로 남겨놓는다. 원본 출처는 여기.
우선, Datadog에서 정의하는 Metric은 2가지가 있다.
- Ingested Custom Metric: 수집된 태그의 각 차원별로 정리된 매트릭 (설정한 코드(?)로 보내짐)
- Indexed Custom Metric: Datadog에서 조회 가능한 일반적인 매트릭
요금을 부과하는 방식이 2가지가 있는데, 먼저 어플리케이션단에서 메트릭을 보내는 경우. 가장 일반적인 경우이다. 이 경우는 Indexed Custom Metric 개수에 따라 요금이 부과된다. 아래와 같은 예를 들면,
- endpoint:X, status:200
- endpoint:X, status:400
- endpoint:Y, status:200
2차원 Tag이고, 각 차원이 2가지의 값을 가질 수 있다. 하지만 고유한 조합은 3개가 나오기 때문에, 3개의 인덱스 값이 생긴다. 따라서 3만큼의 Indexed Custom Metric을 소요한다.
과금 방식에 따라 약간 다르지만, 보통 Custom Metric은 100 단위로 과금이 이루어진다. 따라서, 한 Metric의 가능한 고유 값이 100가지가 넘을 수 있는지를 반드시 잘 생각해 봐야 한다.
그런데 Datadog에서는 어플리케이션단 메트릭 이외에도, 기존 매트릭으로부터 필요한 태그만을 묶어서 새롭게 매트릭을 생성하는 기능을 제공한다. 이를 사용할 경우 Indexed Custom Metric 개수에 따라서도 요금이 부과되는데, 이 경우에는 4만큼의 Indexed Custom Metric이 소요된다. 이것도 Indexed Custom Metric과 마찬가지로 100 단위로 요금을 부과하는 듯 하다.
다소 불만이라면 이런 모니터링 툴뿐만 아니라, 외부 서비스(SaaS)들은 하나같이 쓰기는 참 쉽지만, 그만큼 잘못 설정했을 경우 요금이 폭탄으로 떨어질 수 있다는 게 큰 차이점이자 Downside중 하나인 것 같다. On-premise는 인프라가 죽기라도 하지 (?)
'개발 > Developing' 카테고리의 다른 글
[정리] Super Mario Bros. 스피드런 조합 비디오 제작과정 (0) | 2023.06.22 |
---|---|
Coroutines in C (0) | 2023.05.07 |
Golang의 defer의 변수 캡쳐, 그리고 동작 원리 (0) | 2023.04.02 |
Python에서의 yield와 실행 순서 (0) | 2023.03.28 |
Git Rebase된 브랜치에 또 Rebase 하기 (0) | 2022.08.24 |