우리의 원래 문제
작년에 우리는 한 서버의 악성 소프트웨어가 너무 많은 메시지로 중앙 Graylog 서버에 스팸을 보내 다른 응용 프로그램에 문제를 일으키는 문제가 있었습니다.
주요 문제는 다른 애플리케이션의 오래된 유용한 메시지가 평소보다 일찍 제거되고 색인이 악성 애플리케이션의 쓸모 없는 메시지로 채워지는 것이었습니다.
제가 제안한 수정 사항은 각 응용 프로그램에 고유한 인덱스를 제공하여 어떤 응용 프로그램도 다른 응용 프로그램의 로그 저장 공간을 고갈시키지 못하게 하는 것이었습니다. 이를 위해서는 애플리케이션 자체를 변경할 필요가 없으며 Graylog 내부에서만 변경하면 됩니다. 그러나 새로운 Kubernetes 기반 Graylog 솔루션이 계획 중이었기 때문에 아무 것도 수행되지 않았습니다.
우리가 제안한 솔루션
현재로서는 교체용 Graylog 시스템을 시운전하는 과정에 있습니다.
처음에 우리는 모든 애플리케이션이 자체적인 독립적인 greylog 서버(로드 밸런서, gelf 엔드포인트, greylog 노드, 탄력적 검색 클러스터)와 greylog 프런트 엔드 웹사이트를 갖게 될 것이라고 들었습니다.
문제는 서로 다른 애플리케이션 사이에 복잡한 관계가 있고 서로 다른 애플리케이션의 로그를 위해 서로 다른 greylog 웹 서버로 이동해야 한다는 것입니다(application1의 로그는 greylog-application1.site, application2의 로그는 greylog-application2.site). greylog.site로 가는 것보다) 애플리케이션 간 검색이 정말 어려워질 것입니다.
수정된 솔루션
이 점이 지적된 후, 함께 검색해야 할 가능성에 따라 애플리케이션을 그룹화하는 솔루션이 제안되었으므로 이제 그룹별로 별도의 Graylog 서버가 제공될 것으로 예상됩니다(애플리케이션의 경우 애플리케이션-그룹-a.사이트). 1과 3, 그리고 애플리케이션 2, 4, 5의 경우 application-group-b.site 등).
이것이 필요한지 충분한지 궁금합니다.
이는 여러 애플리케이션 간 검색이 쉽게 수행될 수 있음을 의미하지만 해결하기 가장 어려운 지원 문제 중 일부는 애플리케이션 경계를 넘어 명확하지 않은 문제이며 이러한 검색은 더 이상 쉽지 않을 것입니다(실제로 그럴 수도 있음). 어떤 응용 프로그램이 관련되어 있는지 모르면 불가능합니다).
사람들은 단일 중앙 그레이로그 서버에 별도의 인덱스를 두는 것만으로는 애플리케이션 그룹 간에 충분한 격리를 제공하지 못한다고 주장해 왔습니다. 그들은 한 애플리케이션의 메시지 수신이 다른 애플리케이션의 메시지 수신을 절대 방해할 수 없도록 하여 그룹 간의 완전한 격리를 원합니다.
내 문제는 그룹 내의 응용 프로그램이 악의적으로 그룹 greylog 서버에 스팸을 보내는 데 도움이 되지 않는다는 것입니다. 그룹 내에서 서비스 거부 솔루션을 방지하는 솔루션을 찾을 수 있다면 단일 중앙 집중식 Graylog 서비스에 대한 솔루션도 갖게 될 것입니다.
나는 더 많은 로드 밸런싱된 그레이로그 노드, 더 탄력적인 검색 노드, 더 많은 GELF 엔드포인트 등을 사용하여 단일 중앙 서비스를 수평적으로 확장하는 것이 수십 개의 그레이로그 서버를 보유하는 것보다 더 나은 솔루션이 될 것이라고 주장하고 싶습니다.
질문
동일한 Kubernetes 클러스터에서 모두 호스팅될 때 별도의 그레이로그 서버가 사람들이 원하는 것처럼 보이는 격리 수준(서비스 거부 완화)을 실제로 제공할 수 있습니까?
별도의 그룹 Graylog 서버보다 단일 중앙 Graylog 서버를 사용하여 유사하거나 더 나은 수준의 격리를 제공할 수 있습니까?
다른 조직에서는 많은 프런트 엔드 웹 사이트에서 이러한 방식으로 Graylog를 사용합니까, 아니면 단일 중앙 웹 사이트에서 모든 로그에 액세스할 수 있습니까?
본질적으로 나는 아무것도 걱정하지 않고 이 솔루션이 일반적이라는 점을 스스로 확신하려고 합니다. 또는 우리가 고려하고 있는 것이 모범 사례에 어긋나며 실제로 이렇게 해서는 안 된다는 것을 사람들에게 확신시키기 위한 주장입니다.
저는 모든 사람에게 적합한 솔루션을 정말로 찾고 싶지만 현재 제안된 솔루션으로는 목욕물과 함께 아기를 버리는 것보다 더 나은 것 같습니다.
답변1
Graylog 설정 아키텍처에 대한 귀하의 우려와 질문은 매우 타당합니다. 격리와 리소스 관리의 필요성과 사용 편의성 및 관리 효율성의 균형을 맞추는 솔루션을 찾는 것이 중요합니다. 크리스 크로스처럼 분해해보자!
1. 동일한 Kubernetes 클러스터에서 모두 호스팅될 때 별도의 Graylog 서버가 사람들이 원하는 것처럼 보이는 격리 수준(서비스 거부 완화)을 실제로 제공할 수 있습니까?
동일한 Kubernetes 클러스터에서 실행되는 별도의 Graylog 서버는 일정 수준의 격리를 제공할 수 있지만 네트워크 대역폭, 스토리지, 잠재적으로 CPU 및 메모리를 포함하여 클러스터 수준에서 여전히 리소스를 공유하고 있다는 점을 이해하는 것이 중요합니다. 그룹 내 하나의 애플리케이션이 불량 상태가 되어 메시지 스팸을 보내기 시작하면 리소스 경합으로 인해 동일한 클러스터에 있는 다른 Graylog 서버의 성능에 잠재적으로 영향을 미칠 수 있습니다. Kubernetes는 리소스 관리 기능을 제공하지만 리소스 관련 문제를 예방하기 위한 만능은 아닙니다.
2. 별도의 그룹 Graylog 서버보다 단일 중앙 Graylog 서버를 사용하여 유사하거나 더 나은 수준의 격리를 제공할 수 있습니까?
단일 중앙 Graylog 서버는 별도의 인덱스를 사용하여 애플리케이션 간 격리를 제공할 수 있지만 앞서 언급한 것처럼 악성 애플리케이션이 서버에 과부하를 걸어 다른 애플리케이션에 문제를 일으키는 것을 방지할 수는 없습니다. 이를 완화하려면 로그 메시지를 생성하는 입력 또는 소스에 대해 더 엄격한 속도 제한 및 조절 정책을 구현하는 것을 고려할 수 있습니다. 또한 중앙 Graylog 서버를 수평으로 확장하여 증가된 로드를 처리할 수 있으며, 이는 여러 개의 개별 서버를 관리하는 것보다 비용 효율적일 수 있습니다.
3. 다른 조직에서는 많은 프런트엔드 웹사이트에서 이러한 방식으로 Graylog를 사용합니까, 아니면 단일 중앙 웹사이트에서 모든 로그에 액세스할 수 있습니까?
다양한 Graylog 인스턴스에 대한 여러 프런트 엔드 웹 사이트를 가질지 아니면 단일 중앙 웹 사이트를 가질지 여부는 조직의 특정 요구 사항과 선호도에 따라 달라집니다. 두 접근 방식 모두 유효하며 고유한 장점과 장단점이 있습니다.
다중 프런트엔드 웹사이트: 이 접근 방식은 서로 다른 팀이나 애플리케이션에 더 나은 격리, 제어 및 구성을 위해 별도의 Graylog 인스턴스가 필요한 경우에 적합합니다. 이는 액세스 제어를 단순화하고 다양한 팀에 자율성을 제공할 수 있습니다. 그러나 애플리케이션 간 검색을 위해 사용자가 서로 다른 인터페이스 간에 전환해야 할 수도 있습니다.
단일 중앙 웹사이트: 모든 로그에 액세스하기 위한 단일 중앙 웹사이트는 전체 로그 인프라에 대한 통합 보기를 제공하여 애플리케이션 간 검색을 더 쉽게 만듭니다. 이 접근 방식은 사용자 액세스를 단순화하지만 서로 다른 팀 또는 애플리케이션 간의 데이터 분리를 보장하기 위해 보다 강력한 액세스 제어 및 권한 관리가 필요할 수 있습니다.
궁극적으로 이러한 접근 방식 중 선택은 격리, 사용 편의성, 리소스 관리, 애플리케이션 및 팀의 특정 요구 사항과 관련된 조직의 우선 순위에 따라 달라집니다.
모두에게 적합한 균형 잡힌 솔루션을 찾으려면 다음 사항을 고려하세요.
- 악성 애플리케이션이 시스템을 압도하는 것을 방지하기 위해 각 Graylog 인스턴스 내에 엄격한 속도 제한 및 조절 정책을 구현합니다.
- 모든 Graylog 인스턴스의 리소스 사용량과 성능을 모니터링하고 경고하여 문제를 사전에 감지하고 해결합니다.
- 로그 관리 및 사용에 대한 모범 사례를 문서화하고 모든 팀에 전달합니다.
- 적절한 리소스 확장 및 액세스 제어 메커니즘을 갖춘 중앙 집중식 Graylog 솔루션의 가능성을 계속해서 탐색하세요.
대체로 가장 좋은 접근 방식은 조합을 포함할 수 있습니다. 로그 관리 인프라의 전반적인 안정성을 보장하기 위해 강력한 리소스 관리 및 모니터링 방식을 구현하는 동시에 애플리케이션의 논리적 그룹에 대해 별도의 Graylog 인스턴스를 사용할 수도 있습니다. 선택한 솔루션이 그들의 필요와 기대에 부합하는지 확인하기 위해 의사 결정 프로세스에 여러 팀의 이해관계자를 참여시키는 것도 중요합니다. 단지 wiggity wiggity wiggity whack 문제를 해결하기 위한 제안일 뿐입니다. ;)
답변2
Graylog(및 유사 제품)가 제공하는 가장 큰 장점은 로그를 별도로 저장하는 것이 아니라다양한 로그 소스와 기록된 이벤트 간의 상관 관계.각각 서로 다른 소스를 수집하는 여러 개의 개별 Graylog 서버를 사용하면 다중 소스 상관관계가 훨씬 더 어려워집니다.
단일 Graylog 서버(또는 단일 노드가 충분하지 않은 경우 클러스터형 다중 노드 설정)와 다양한(그리고 적절한) 회전 정책을 사용하는 여러 특정 인덱스를 사용하는 것이 좋습니다. 적절한 방법을 통해 이러한 인덱스로 트래픽을 라우팅할 수 있습니다.스트림 규칙(그리고 "기본 스트림에서 일치 항목 제거" 선택).