https://crema.github.io/2021/06/29/collect-kafka-consumer-metrics.html
이런 글을 썼었다.
글을 쓰는덴, 위 링크 본문에도 참조되어 있는
https://www.theteams.kr/teams/865/post/64574
이 글이 많이 동기가 되었다.
글을 처음 쓰기 시작할 때의 목표?는, 이러한 점을 말하고 싶었다: - 크리마는 Ansible 을 쓰고 있다. - 크리마는 Datadog 을 쓰고 있다. - 크리마는 Kafka 도 쫌 쓰고 있다.
누가 봤을진 모르지만(우리 회사 사람들은 봤을까 싶다..), 그래도 목표한 바는 글에 잘 쓴거 같다.
글 쓴 후 아쉬운 점을 복기하자면, 참고한 원 글에선 outlier detection 알람을 걸었다고 한다(정확히 알람일진 모르겠지만, 내 생각에 티켓 정도로 보내면 좋을거 같다). 하지만 우린 메트릭을 쌓아두기만 할 뿐 알람을 만들진 않았다. 그렇다. 인간 알람에 의존하고 있다!(“*** 처리 안되고 있는거 같은데요?”)
이건 내가 도입하려 anomaly 했던 알람이 실패했던 경험 때문에 그렇다. Anomaly detection 알람을 두개 달은적이 있다. 하지만 알람이 너무 많이 왔고 그건 나의 개인 메일에만 오도록 noti를 바꾼 후 나도 잘 쳐다보지 않게 되었다.
Anomaly 알람은 우리에게 적합하지 않는 것으로 치부되어 잊혀져 왔고, 우린 그냥 장애 또는 이슈 발생 시 안 보고 있던 메트릭은 추가 후 ‘경험상’ 이정도면 문제가 있다 싶은 것에만 threshold 알람을 달게 됐다.
… 내심 찜찜했다. 인간 알람이랑 뭐가 다르지?
그러나 이 글을 쓰며 새로운 outlier 모니터로 똑같이 kafka.consumer_lag 에 대하여 파티션 평균에 대해 DBSCAN 으로 만들어 보니 … 잘 동작하는것 같다(잘 된다는건 단순히 빨강 outlier 가 없다는 뜻이다).
언젠가부터 새로운 걸 배우는게 두렵고, 귀찮고 … 너무 도전하는 것 자체를 멀리하여 정확히 그거에 대해 어떤 감정인지도 모르는 상태가 됐다. 지금은 적어도 그런게 자각 되어 답답하고 부끄러움 정도를 느끼는 상태이다.
이 두서 없는 글은 두번째로 다시 시작하는 블로그의 출사표이다.
맨 처음 프로개발자가 됐을 땐, 블로그에 글 쓰는게 크게 중요치 않다고 생각했다. 체화되는 기술이 훨씬 중요하다고 생각했고 커밋과 커밋 메세지만 잘 쓰면 적어도 퍼블릭 레포에선 누구나 볼 수 있기 때문에 따로 문서화가 필요 없다고 생각했다(코드보다 주석을 더 많이 써야한다는 이상한 과제를 안해서 너무 좋았다).
하지만 devops 는 좀 다르다. 작업의 결과가 커밋 같은 형태로 잘 남지 않는 경우가 많고, 체득보단 기록을 잘 해야한다고 느낀다. 당장 파이프 두개만 넘어가는 쉘 커맨드도 검색 키워드를 다시 복기해서 구글링해 쓰거나 저장해둔걸 복붙한다.
블로그를 조금 재밌게 하기 위해, 너무 직무와 기술 관련한 이야기만 쓰지도 않으려고 한다. 글의 완성도가 블로깅 목적이 아니다. 미흡한 글일지라도 누군가에겐 도움이 된다. 또 그 도움은 기술적인 도움이 아니더라도 괜찮다.
그러나 이런 식의 넋두리만 하는 싸이월드 또한 지양해야한다. 시기적으로 연말이니깐 다른 분들이 하는 2021년 회고… 정도로 생각하고 봐주자 ㅎㅎ
DBSCAN 이나 MAD 가 뭔지 잘 모르기 때문에 바로 알람을 달지 않을 것이다. 이전의 anomaly 알람이 실패한 이유도 알람의 정확한 알고리즘을 몰라서 그런거 같다. 아니 적어도 기록하지 않았기 때문에 모르는게 맞고, ‘몰라서 그랬다’.
이젠 모르지 말자. 아는 것에 대해서 아는 척만 했고, 모르는 것도 조금 넘겨 짚어 버렸던 과거에 대해서도 그만 후회하자.
적당히 타협하지 말자. 정확히 안다면 설득할 수 있고, 그래도 안되면 개념증명으로 보여주자.