Execução fora de Google Cloud
Se o cluster não estiver em execução no Google Cloud, configure manualmente os valores dos identificadores project_id
e location
. É recomendável:
Definir
project_id
com base na forma como o cluster se encaixa no modelo de monitoramento de vários locatários. A conta de serviço precisa ser configurada com as permissões corretas para oproject_id
escolhido.Defina
location
com base na região Google Cloud mais próxima da implantação.
Não é possível regravar esses identificadores com uma regra de remarcação.
Ter mais de 3.500 projetos na sua organização
O número máximo permitido de projetos em um escopo de métricas é 375, mas o número máximo não permitido de projetos em um escopo é 3.500.
Se você tem mais de 3.500 projetos,
a solução alternativa recomendada é configurar os coletores para usar um project_id
central em vez do ID do projeto em que estão sendo executados. Em seguida, as métricas
de todos os projetos são armazenadas no Monarch com
esse ID central do projeto. Basta colocar o projeto central em um
escopo de métricas.
Se você optar por essa abordagem, lembre-se das desvantagens:
- Perda de granularidade da multilocação, já que as permissões só podem ser definidas por projeto. É recomendável agrupar logicamente os projetos em algumas categorias e usar um projeto central diferente para cada um deles.
- Não é possível substituir o valor
project_id
das métricas do sistema Google Cloud . Essa solução alternativa não permite ver métricas gratuitas do Google Kubernetes Engine no projeto central, já que essas métricas permanecem dentro de cada projeto de origem. - O uso de um projeto central pode complicar o uso de Rules e ClusterRules, porque essas regras ficam no escopo do projeto em que estão instaladas, e é improvável que você tenha o mesmo conjunto de nomes de clusters e namespaces em cada projeto. Talvez seja necessário usar GlobalRules.
Como localizar dados manualmente em uma única região Google Cloud
Por padrão, o Managed Service para Prometheus armazena dados na regiãoGoogle Cloud de origem dos dados, e as consultas são naturalmente globais. Isso significa que você não precisa colocar geograficamente os dados para consultar dados em várias regiões Google Cloud .
Na maioria das situações, esse comportamento padrão é suficiente. No entanto, pode haver algumas situações em que você queira armazenar todos os dados de métricas em uma única região do Google Cloud , por exemplo, se estiver em um ambiente altamente regulamentado.
Para armazenar todos os dados de métricas em uma única região, configure os coletores para usar um único location
em vez do local detectado automaticamente pelo cluster em que estão sendo executados.
Armazenar dados em uma única região Google Cloud pode complicar o uso de Rules e ClusterRules, porque eles têm como escopo o local em que são instalados, e é improvável que você tenha o mesmo conjunto de clusters e nomes de namespace em cada região Google Cloud . Talvez seja necessário usar GlobalRules.