Visão Geral do Serviço Monitoring
Use o serviço Oracle Cloud Infrastructure Monitoring para monitorar ativa e passivamente os recursos da nuvem usando as funcionalidades Métricas e Alarmes. Saiba como o serviço Monitoring funciona.
Como o Serviço Monitoring Funciona
O serviço Monitoring usa métricas para monitorar recursos e alarmes para notificá-lo quando essas métricas atenderem aos acionadores especificados pelo alarme.
As métricas são emitidas para o serviço Monitoring como pontos de dados brutos ou pares de timestamp-valor, juntamente com dimensões e metadados. As métricas vêm de várias fontes:
- Métricas de recursos postadas automaticamente pelos recursos . do Oracle Cloud Infrastructure. Por exemplo, o serviço Compute posta métricas para monitorar instâncias de computação ativadas por monitoramento por meio do namespace oci_computeagent. Uma dessas métricas é
CpuUtilization
. Consulte Serviços Suportados e Exibindo Gráficos de Métrica Padrão. - Métricas personalizadas publicadas usando a API do serviço Monitoring.
- Dados enviados para métricas novas ou existentes usando o Connector Hub (com o serviço Monitoring como serviço de destino para um conector).
Você pode transferir métricas do serviço Monitoring usando o Connector Hub. Para obter mais informações, consulte Criando um Conector com uma Origem de Monitoramento.
Os dados de métricas publicados para o serviço Monitoring só são apresentados a você ou consumidos pelos recursos do Oracle Cloud Infrastructure que você ativa para usar dados de métricas.
Quando você consulta uma métrica, o serviço Monitoring retorna dados agregados de acordo com os parâmetros especificados. Você pode especificar um intervalo (como as últimas 24 horas), uma estatística e um intervalo . A Console exibe um gráfico de monitoramento por métrica para os recursos selecionados. Os dados agregados em cada gráfico refletem a estatística e o intervalo selecionados. As solicitações de API podem, opcionalmente, filtrar por dimensão e especificar uma resolução . As respostas da API incluem o nome da métrica juntamente com seu compartimento de origem e namespace de métricas . Você pode alimentar os dados agregados em uma visualização ou biblioteca de gráficos.
Os dados de métrica e alarme são acessíveis na Console, na CLI e na API. Para períodos de retenção, consulte Limites de Armazenamento.
O recurso Alarmes do serviço Monitoring publica mensagens de alarme em destinos configurados, como tópicos no serviço Notifications e streams no serviço Streaming.
Visão Geral do Recurso de Métricas
O recurso Métricas retransmite os dados da métrica sobre a integridade, a capacidade e o desempenho dos recursos de nuvem.
Uma métrica é uma medida relacionada à integridade, capacidade ou desempenho de um recurso . Recursos, serviços e aplicativos emitem métricas para o serviço Monitoring. Métricas comuns refletem dados relacionados a:
- Disponibilidade e latência
- Período de disponibilidade e inatividade do aplicativo
- Transações concluídas
- Operações com falha e bem-sucedidas
- Indicadores chave de desempenho (KPIs), como quantificadores de vendas e engajamento
Ao consultar o serviço Monitoring para obter esses dados, você pode entender como os sistemas e processos estão trabalhando para alcançar os níveis de serviço submetidos para seus clientes. Por exemplo, você pode monitorar a utilização da CPU e leituras de disco de instâncias de computação. Em seguida, você pode usar esses dados para decidir quando provisionar mais instâncias a fim de lidar com o aumento de carga, solucionar problemas com a instância ou compreender melhor o comportamento do sistema.
Exemplo de Métrica: Taxa de Falha
Para a integridade do aplicativo, um dos KPIs comuns é a taxa de falha, para a qual uma definição comum é o número de transações com falha dividido pelo total de transações. Esse KPI geralmente é fornecido por meio de software de monitoramento e gerenciamento de aplicativos.
Como desenvolvedor, você pode capturar esse KPI de aplicativos usando métricas personalizadas. Registre as observações sempre que uma transação do aplicativo ocorrer e, em seguida, publique esses dados no serviço Monitoring. Nesse caso, configure métricas para capturar transações com falha, transações bem-sucedidas e latência de transação (tempo gasto por transação concluída).
Visão Geral do Recurso de Alarmes
Use alarmes para monitorar a integridade, a capacidade e o desempenho dos recursos da nuvem.
O recurso Alarmes do serviço Monitoring funciona com o serviço de destino configurado para notificar você quando as métricas atendem aos triggers especificados pelo alarme. A ilustração anterior representa o fluxo, começando com recursos que emitem pontos de dados de métrica para o serviço Monitoring. Quando acionado, um alarme envia uma mensagem de alarme para o destino configurado. Para o serviço Notifications, as mensagens são enviadas para assinaturas no tópico configurado. Para o serviço Streaming, as mensagens são enviadas ao stream configurado. (Esta ilustração não abrange dados de métrica brutos e agregados. Para obter esses detalhes, consulte a ilustração "Visão Geral do Serviço Monitoring" na parte superior desta página.)
Quando configurado, as notificações repetidas lembram um estado de acionamento contínuo no intervalo de repetição configurado. Você também é notificado quando um alarme retorna ao estado OK ou quando um alarme é redefinido.
Avaliações de Alarme
O serviço Monitoring avalia alarmes uma vez por minuto para localizar o status do alarme.
Quando o alarme separa as notificações, o serviço Monitoring avalia cada stream de métrica rastreado. Se a avaliação desse stream de métrica indicar um novo status FIRING
ou outro evento de qualificação, o serviço Monitoring enviará uma mensagem de alarme.
O serviço Monitoring rastreia streams de métrica por alarme para eventos de qualificação, mas as mensagens estão sujeitas aos limites do serviço de destino.
Ilustração da Avaliação de Alarme
Considere um alarme que meça o percentil 90 da métrica CpuUtilization
.
{
"compartmentId": "ocid1.compartment.oc1..exampleuniqueID",
"destinations": ["ocid1.onstopic.exampleuniqueID"],
"displayName": "High CPU Utilization",
"id": "ocid1.alarm.oc1..exampleuniqueID",
"lifecycleState": "ACTIVE",
"metricCompartmentId": "ocid1.compartment.oc1..exampleuniqueID",
"namespace": "oci_computeagent",
"pendingDuration": "PT3M",
"query": "CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85",
"repeatNotificationDuration": "PT2H",
"severity": "WARNING",
"isEnabled": true,
"timeCreated": "2023-02-01T01:02:29.600Z",
"timeUpdated": "2023-02-03T01:02:29.600Z"
}
Observações sobre este alarme de exemplo:
- O percentil é especificado na consulta como a estatística (negrito):
CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85
- Cada ponto de dados é o percentil 90 (
percentile(0.9)
) de uma janela de um minuto, especificado na consulta como o intervalo (negrito):CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85
- Os valores dos pontos de dados dessa estatística poderiam variar de nulo (ausente) a 100.
- Avaliações de pontos de dados:
- Para qualquer valor de ponto de dados maior que 85, a avaliação é verdadeira (
1
). Uma avaliação verdadeira significa que a condição da regra de acionamento foi atendida. - Para qualquer valor de ponto de dados que não seja maior que 85, a avaliação é falsa (
0
).
- Para qualquer valor de ponto de dados maior que 85, a avaliação é verdadeira (
- O alarme não será acionado até que a condição regra de acionamento seja atendida por três minutos sucessivos. Essa configuração é o atraso do acionador do alarme (
pendingDuration
), definido comoPT3M
. - O alarme atualiza seu estado para OK quando a condição de violação está clara no minuto mais recente.
A imagem a seguir mostra um stream de métrica agregado para o alarme de exemplo. Cada ponto de dados é indicado por um quadrado.
A tabela a seguir mostra avaliações de alarme consecutivas para o exemplo de alarme. O alarme é avaliado em uma janela móvel de três intervalos de um minuto.
Data e hora do período de avaliação | Minutos no período | Avaliações de ponto de dados* | Status |
---|---|---|---|
3 | [1 2 3] | [0 0 0] | OK |
4 | [2 3 4] | [0 0 1] | OK |
5 | [3 4 5] | [0 1 1] | OK |
6 | [4 5 6] | [1 1 1] | ACIONAMENTO |
7 | [5 6 7] | [1 1 1] | ACIONAMENTO |
8 | [6 7 8] | [1 1 0] | OK |
9 | [7 8 9] | [1 0 0] | OK |
10 | [8 9 10] | [0 0 0] | OK |
*Um valor de um (1) significa que a condição da regra de acionamento foi atendida.
Sobre o Período de Redefinição Interno
O período de redefinição interna determina quando um alarme para de verificar se há uma métrica ausente que acionou o estado Firing na avaliação anterior. Quando a métrica estiver ausente durante todo o período, as avaliações de alarme posteriores ignorarão o fluxo de métricas indicado. Se nenhum outro stream de métrica estiver causando o estado Firing do alarme, o alarme fará a transição para OK e enviará uma mensagem RESET. Por padrão, a mensagem RESET chega após 13 minutos (período de redefinição interno mais o período de folga padrão de 3 minutos). É possível personalizar o período de folga.
A duração do período de redefinição interna é globalmente configurada em 10 minutos, o que faz com que o histórico de alarmes mostre uma diferença de 10 minutos.
O início de um período de redefinição interno depende do tipo de alarme. Para alarmes de limite, o período de redefinição interno começa quando a primeira ausência é detectada. Para alarmes de ausência, o período de redefinição interno começa após a conclusão do período de detecção de ausência (2 horas).
Pontos de Dados Coletados Durante um Período de Redefinição Interno
Cada avaliação durante o período de redefinição interna de dez minutos representa todos os pontos de dados desse período.
Por exemplo, considere um stream de métrica (A
) que exceda o limite (linha vermelha tracejada nos diagramas a seguir). O alarme dispara (F
). Quando uma falta de pontos de dados emitidos é detectada, um período de redefinição interno começa.
O diagrama a seguir mostra um único período de redefinição interno para o stream de métrica A
, dos horários t5
a t15
. No momento t16
, o stream de métrica A
não é mais avaliado.
O diagrama a seguir mostra dois períodos de redefinição internos para o stream de métrica A
, dos horários t3
a t5
e de t6
a t16
. A
emite um ponto de dados em t6
, iniciando outro período de redefinição interno. No momento t17
, o stream de métrica A
não é mais avaliado.
Exemplo de Alarme de Limite
Um alarme de limite reporta streams de métrica que ocorrem fora do limite. Quando um stream de métrica anteriormente problemático está ausente, o alarme inicia o período de redefinição interno do stream de métrica.
Neste exemplo, quatro streams de métrica são avaliados por um alarme de limite. A Console mostra os estados de transição inicial Firing (1:30) e Ok (1:51). O período de redefinição interno ocorre enquanto o alarme está no estado Firing.
O período de redefinição interno e outros eventos significativos neste exemplo são descritos na tabela a seguir.
Horário | Estado | Transição | Eventos | Notificações (consulte Tipos de Mensagem) |
---|---|---|---|---|
12:0 | OK | OK | Todas as emissões estão dentro do limite. | FIRING_TO_OK |
1:30 | Acionamento | Acionamento | A emissão de resource1 excede o limite. | OK_TO_FIRING |
1:35 | Acionamento | -- | Nenhuma emissão foi detectada para resource1. O alarme inicia o período de redefinição interno para resource1. | -- |
1:38 | Acionamento | -- | Nenhuma emissão foi detectada para resource2. O alarme inicia o período de redefinição interno para resource2. | -- |
1:45 | Acionamento | -- | O período de redefinição interno termina para resource1; portanto, o alarme não verifica mais as emissões de resource1. No entanto, o alarme ainda está sendo acionado porque resource2 ainda está em seu próprio período de redefinição interno. | -- |
1:48 | OK | OK | O período de redefinição interno termina para resource2; portanto, o alarme não verifica mais as emissões de resource2. As emissões dos recursos restantes (resource3 e resource4) estão dentro do limite. | RESET (enviado após o período de folga de três minutos, por volta de 1:51) |
Exemplo de Alarme de Ausência
Um alarme de ausência reporta streams de métrica ausentes. Quando um stream de métrica está ausente, o alarme inicia o período de detecção de ausência para o stream de métrica (o padrão é duas horas, pode ser personalizado). Após a conclusão do período de detecção de ausência, o alarme inicia o período de redefinição interno do stream de métrica.
Neste exemplo, um stream de métrica é avaliado por um alarme de ausência que usa o período de detecção de ausência padrão de duas horas e o período de folga padrão de três minutos. A Console mostra os estados de transição inicial Firing (2:00) e Ok (4:10). O período de redefinição interno ocorre enquanto o alarme está no estado Firing.
O período de redefinição interno e outros eventos significativos neste exemplo são descritos na tabela a seguir.
Horário | Estado | Transição | Eventos | Notificações (consulte Tipos de Mensagem) |
---|---|---|---|---|
1:00 | OK | -- | Emissões são detectadas. | |
2:00 | Acionamento | Acionamento | Nenhuma emissão foi detectada para resource-z. O alarme inicia o período de detecção de ausência para resource-z. | OK_TO_FIRING |
4:0 | Acionamento | -- | O período de detecção de ausência para resource-z termina. O alarme inicia o período de redefinição interno do resource-z. | -- |
4:10 | OK | OK | O período de redefinição interno termina para resource-z, de modo que o alarme não verifica mais as emissões de resource-z. Nenhum stream de métrica é monitorado pelo alarme, portanto, o alarme faz a transição para o estado Ok. | RESET (enviado após o período de folga de três minutos, por volta de 4:13) |
Tempo Necessário para Refletir Atualizações de Alarme
As atualizações de alarmes levam até cinco minutos para serem refletidas em todos os lugares.
Por exemplo, se você atualizar um alarme para dividir notificações, poderá levar até cinco minutos para que o status do stream de métrica seja preenchido na Console.
Procurando Alarmes
Pesquise alarmes usando atributos suportados.
Para obter mais informações sobre o serviço Search, consulte Visão Geral do Serviço Search. Para obter descrições de atributos, consulte Referência de Alarme.
-
id
-
displayName
-
compartmentId
-
metricCompartmentId
-
namespace
-
query
-
severity
-
destinations
-
suppression
-
isEnabled
-
lifecycleState
-
timeCreated
-
timeUpdated
-
tags
O tipo de mensagem indica o motivo pelo qual a mensagem foi enviada.
O tipo de mensagem especificado é enviado no momento indicado mais o atraso do trigger configurado do alarme, se houver.
Mensagens repetidas também são enviadas se configuradas no alarme.
A tabela a seguir lista o estado e a transição do alarme para cada tipo de mensagem.
Tipo de mensagem | Estado | Transição | Comentários |
---|---|---|---|
OK_TO_FIRING |
FIRING |
de OK a FIRING |
|
FIRING_TO_OK |
OK |
de FIRING a OK |
|
REPEAT |
FIRING |
-- | Esse tipo de mensagem é enviado quando o alarme mantém o estado FIRING e o alarme é configurado para notificações repetidas. |
RESET |
OK |
de FIRING a OK |
Importante: Quando ocorrer uma alteração do status Esse tipo de mensagem é enviado quando o alarme faz a transição para o estado Possíveis causas para um fluxo de métricas ausente: O recurso que estava emitindo a métrica pode ter sido movido ou encerrado ou a métrica só pode ser emitida em caso de falha. Para obter mais informações sobre o período de redefinição interno, consulte Sobre o período de redefinição interno. |
Formato e Exemplos de Mensagem
Conceitos do Serviço Monitoring
Os conceitos a seguir são essenciais para trabalhar com o serviço Monitoring.
- dados agregados
- O resultado da aplicação de uma estatística e de um intervalo a uma seleção de pontos de dados básicos para uma métrica. Por exemplo, você pode aplicar a estatística
max
e o intervalo1h
(uma hora) às últimas 24 horas de pontos de dados brutos para a métricaCpuUtilization
. Os dados agregados são exibidos nos gráficos de métricas padrão na Console. Você também pode criar consultas de métricas para conjuntos específicos de dados agregados. Para obter instruções, consulte Exibindo Gráficos de Métricas Padrão e Criando Consultas de Métricas. - alarme
- A consulta de alarme para avaliar e o destino da notificação a ser usado quando o alarme estiver no estado de acionamento, com outras propriedades de alarme.
- consulta de alarme
- A expressão Monitoring Query Language (MQL) a ser avaliada para o alarme. Uma consulta de alarme deve especificar uma métrica, uma estatística, um intervalo e uma regra de acionamento (limite ou ausência). O recurso Alarmes do serviço Monitoring interpreta resultados de cada série de tempo retornada como um valor Booliano, em que zero representa falso e um valor diferente de zero representa verdadeiro. Um valor verdadeiro significa que a condição da regra de acionamento foi atendida.
- ponto de dados
- Um par de timestamp/valor para a métrica especificada. Exemplo:
2022-05-10T22:19:00Z, 10.4
- dimensão
- Um qualificador fornecido em uma definição de métrica. Exemplo: Identificador de Recurso (
resourceId
), fornecido nas definições de métricas do oci_computeagent. Use dimensões para filtrar ou agrupar dados de métricas. Exemplo de par de nome/valor da dimensão para filtragem por domínio de disponibilidade:availabilityDomain = "VeBZ:PHX-AD-1"
- frequência
- O período entre cada ponto de dados brutos publicado para uma métrica. (Pontos de dados brutos são publicados pelo namespace de métricas para o serviço Monitoring.) Enquanto a frequência varia por métrica, as métricas de serviço padrão normalmente têm uma frequência de 60 segundos (um ponto de dados publicado por minuto). Consulte também resolução.
- intervalo
- A janela de tempo usada para converter o conjunto de pontos de dados básicos.
- mensagem
- O conteúdo que o recurso Alarmes do serviço Monitoring publica em tópicos nos destinos de notificação configurados do alarme. Uma mensagem é enviada quando o alarme muda para outro estado, como de
OK
paraFIRING
. - metadados
- Uma referência fornecida em uma definição de métrica. Exemplo: unidade (bytes), fornecida na definição da métrica
DiskBytesRead
do oci_computeagent. Use metadados para determinar informações adicionais sobre uma métrica. Para definições de métricas, consulte Serviços Suportados. - métrica
- Uma medida relacionada à integridade, capacidade ou desempenho de um recurso. Exemplo: A métrica
CpuUtilization
oci_computeagent
, que mede o uso de uma instância de computação. Para definições de métricas, consulte Serviços Suportados. - definição de métrica
- Um conjunto de referências, qualificadores e outras informações fornecidas por um namespace de métricas para uma métrica. Por exemplo, a métrica oci_computeagent
DiskBytesRead
é definida por dimensões (como identificador do recurso) e metadados (especificando bytes para a unidade), bem como pela identificação de seu namespace de métricas (oci_computeagent). Cada conjunto publicado de pontos de dados contém essas informações. Use a operação de API ListMetricData para obter definições de métricas. Para definições de métricas, consulte Serviços Suportados. - namespace de métricas
- Indicador do recurso , serviço ou aplicativo que emite a métrica. Fornecido na definição da métrica. Por exemplo, a definição de métrica
CpuUtilization
emitida pelo software Oracle Cloud Agent nas instâncias de computação lista o namespace de métricaoci_computeagent
como origem da métricaCpuUtilization
. Para definições de métricas, consulte Serviços Suportados. - stream da métrica
- Um conjunto individual de dados agregados para uma métrica e zero ou mais valores de dimensão.
- destino da notificação
- Detalhes para enviar mensagens quando o alarm muda para outro estado, como de
OK
paraFIRING
. Os detalhes e a configuração podem variar de acordo com o serviço de destino. Os serviços de destino disponíveis incluem Notifications e Streaming. - SoftwareOracle Cloud Agent
- Software usado por uma instância de computação para publicar pontos de dados brutos para o serviço Monitoring. Instalado automaticamente com as versões mais recentes das imagens suportadas. Consulte Ativando o Monitoramento de Instâncias do Serviço Compute.
- query
- A expressão MQL (Monitoring Query Language) e as informações associadas (como namespace de métrica) a serem avaliadas para retornar dados agregados. A consulta deve especificar uma métrica, uma estatística e um intervalo.
- resolução
-
O período entre janelas de tempo ou a regularidade com que as janelas de tempo mudam. Por exemplo, use uma resolução de
1m
para recuperar agregações a cada minuto.Observação
Para consultas de métrica, o intervalo selecionado conduz à resolução padrão da solicitação, que determina o intervalo de tempo máximo dos dados retornados.Para consultas de alarme, o intervalo especificado não tem efeito na resolução da solicitação. O único valor válido da resolução de uma solicitação de consulta de alarme é
1m
. Para obter mais informações sobre o parâmetro de resolução como usado em consultas de alarme, consulte Alarme.Como mostrado na ilustração a seguir, a resolução controla o horário inicial de cada janela de agregação em relação à janela anterior, enquanto o intervalo controla o tamanho das janelas. As duas solicitações aplicam a estatística
max
aos dados em cada janela de cinco minutos (do intervalo), resultando em um único ponto de dados agregado que representa o maior contadorCPUutilization
para essa janela. Somente o valor da resolução é diferente. Essa resolução altera a regularidade com que as janelas de agregação mudam ou os horários iniciais das sucessivas janelas de agregação. A solicitação A não especifica uma resolução e, portanto, usa o valor padrão igual ao intervalo (5 minutos). As janelas de agregação de cinco minutos dessa solicitação são obtidas dos conjuntos de pontos de dados emitidos de 0:n a 5:00, 5:n a 10:00, e assim por diante. A solicitação B especifica uma resolução de 1 minuto; portanto, suas janelas de agregação de cinco minutos são obtidas do conjunto de pontos de dados emitidos a cada minuto, de 0:n a 5:00, 1:n a 6:00, e assim por diante.Para especificar uma resolução não padrão diferente do intervalo, consulte Selecionando uma Resolução Não Padrão para uma Consulta e Criando um Alarme.
- grupo de recursos
- Uma string personalizada fornecida com uma métrica personalizada que pode ser usada como um filtro ou para agregar resultados. O grupo de recursos deve existir na definição da métrica publicada. Somente um grupo de recursos pode ser aplicado por métrica.
- estatística
- A função de agregação aplicada ao conjunto de pontos de dados brutos.
- suppression
- Uma configuração para deixar de publicar mensagens durante o intervalo de tempo especificado. Útil para suspender notificações de alarme durante a manutenção do sistema.
- intervalo de tempo
- Os limites (timestamps) dos dados de métrica que você deseja. Por exemplo, a última hora.
- regra do acionador
- A condição que deve ser atendida para que o alarme esteja no estado de acionamento. Uma regra do acionador pode ser baseada em um limite ou na ausência de uma métrica.
Disponibilidade
O serviço Monitoring está disponível em todas as regiões comerciais do Oracle Cloud Infrastructure. Consulte Sobre Regiões e Domínios de Disponibilidade para obter a lista de regiões disponíveis, juntamente com locais associados, identificadores de região, chaves de região e domínios de disponibilidade.
Serviços Suportados
Os serviços a seguir têm recursos ou componentes que podem emitir métricas para o serviço Monitoring:
- Analytics Cloud - consulte Sobre as Métricas do Oracle Analytics Cloud
- API Gateway - consulte Métricas do Serviço API Gateway
- Application Performance Monitoring - consulte Métricas do Serviço Application Performance Monitoring
- Autonomous Recovery Service - consulte Métricas do Recovery Service
- Bastion - consulte Métricas do Serviço Bastion
- Big Data Service - consulte Exibir Métricas do Cluster
- Block Volume - consulte Métricas do Serviço Block Volume
- Blockchain Platform - consulte Monitorar Métricas (Blockchain Platform)
-
Compute - consulte estas páginas:
-
Compute Cloud@Customer - consulte Métricas do Compute Cloud@Customer
- Hub do Conector - consulte Métricas do Hub do Conector
- Container Instances - consulte Métricas do Serviço Container Instances
- Data Catalog - consulte Métricas do Serviço Data Catalog
- Data Flow - consulte Métricas do Serviço Data Flow
- Data Integration - consulte Métricas do Serviço Data Integration
- Data Science - consulte Sobre métricas de sessão de notebook
- Data Transfer - consulte estas páginas:
- Importação de Dados Baseada em Disco: Exibindo Métricas Baseadas em Disco do Serviço Data Transfer
- Importação de Dados Baseada em Appliance: Exibindo Métricas Baseadas na Importação do Data Transfer Appliance
- Exportação de Dados: Exibindo Métricas Baseadas na Exportação do Data Transfer Appliance
- Banco de Dados - consulte estas páginas:
- Monitorar Desempenho com Métricas do Autonomous Database (Autonomous Database Serverless)
- Monitorar Bancos de Dados com Métricas do Autonomous Database (Autonomous Database on Dedicated Exadata Infrastructure)
- Métricas do Oracle Exadata Database Service on Dedicated Infrastructure no Serviço Monitoring (em Guias de Referência do Exadata Cloud Infrastructure)
- Métricas do Base Database Service no Database Management Service: Monitorar um Banco de Dados Usando Métricas do Database Management
- Métricas do Banco de Dados Externo
- Database Management - consulte Métricas do Serviço Database Management
- Database Migration - consulte Métricas do Serviço Database Migration
- OCI Database com PostgreSQL - consulte OCI Database com Métricas PostgreSQL
- DevOps - consulte Métricas do Serviço DevOps
- Digital Assistant - consulte Métricas do Serviço Digital Assistant
- DNS - consulte Métricas de DNS
- Email Delivery - consulte Métricas do Serviço Email Delivery
- Events - consulte Métricas do Serviço Events
- File Storage - consulte Métricas do Sistema de Arquivos
- Functions - consulte Métricas de Função
- Autonomous Database Distribuído Globalmente - consulte Monitorar o Desempenho com Métricas do Autonomous Database
- GoldenGate - consulte Métricas do Oracle Cloud Infrastructure GoldenGate
- Health Checks - consulte Métricas do Serviço Health Checks
- Integração - consulte estas páginas:
- Integration Generation 2: Exibir Métricas de Mensagem
- Integração 3: Exibir Métricas de Mensagem e Mensagens Faturáveis
- Java Management - consulte Métricas do Serviço Java Management
- Kubernetes Engine - consulte Métricas do Serviço Container Engine for Kubernetes
- Load Balancer - consulte Métricas do Serviço Load Balancer
- Logging - consulte Métricas do Serviço Logging
- Logging Analytics - consulte Monitorar o Serviço Logging Analytics Usando Métricas de Serviço
- Serviço Media Streams - consulte Métricas do Serviço Media Streams
- Management Agent - consulte Métricas do Serviço Management Agent
- HeatWave - consulte Métricas
-
Rede - consulte estas páginas:
- NoSQL Database Cloud - consulte Métricas do Serviço
- Notifications - consulte Métricas do Serviço Notifications
- Network Firewall - consulte Métricas do Serviço Network Firewall
- Object Storage - consulte Métricas do Serviço Object Storage
- Ops Insights - consulte Métricas do Serviço Operations Insights
- Oracle APEX Application Development - consulte Monitorar o Desempenho do APEX Service
- OS Management - consulte Métricas do Serviço OS Management
- OS Management Hub - consulte Métricas do OS Management Hub
- Automação de Processos - consulte Métricas de Automação de Processos
- Queue - consulte Métricas do Serviço Queue
- Service Mesh - consulte Métricas do Service Mesh
- Stack Monitoring - consulte Referência de Métrica do Serviço Stack Monitoring
- Streaming - consulte Métricas do Serviço Streaming
- Vault - consulte Monitorando Recursos do Serviço Vault
- Verificação de Vulnerabilidade - consulte Métricas de Verificação
- WAF - consulte Métricas de Política de Borda
Identificadores de Recursos
A maioria dos tipos de recursos do Oracle Cloud Infrastructure tem um identificador exclusivo designado pela Oracle chamado OCID (Oracle Cloud ID). Para obter informações sobre o formato OCID e outras maneiras de identificar seus recursos, consulte Identificadores de Recursos., consulte Identificadores de Recursos.
Os recursos métricos não possuemOCIDs.
Maneiras de Acessar o Serviço Monitoring
Você pode acessar o OCI (Oracle Cloud Infrastructure) usando a Console (uma interface baseada em browser), a API REST ou a CLI do OCI. Instruções para usar a Console, API e CLI estão incluídas em tópicos ao longo deste guia. Para ver uma lista de SDKs disponíveis, consulte Software Development Kits e Interface de Linha de Comando.
Console: Para acessar o serviço Monitoring usando a Console, use um browser suportado. Para ir até a página de acesso da Console, abra o menu de navegação na parte superior desta página e clique em Console de Infraestrutura. Você é solicitado a digitar seu tenant na nuvem, seu nome de usuário e sua senha. Abra o menu de navegação e clique em Observabilidade & Gerenciamento. No serviço Monitoring, clique em Métricas do Serviço.
API: Para acessar o serviço Monitoring por meio de APIs, use a API do Serviço Monitoring para métricas e alarmes e a API do Serviço Notifications para notificações (usada com alarmes).
CLI: Consulte Referência de Linha de Comando para o Serviço Monitoring e Referência de Linha de Comando para o serviço Notifications.
Autenticação e Autorização
Cada serviço do Oracle Cloud Infrastructure se integra ao IAM para autenticação e autorização, para todas as interfaces (Console, SDK ou CLI e API REST).
Um administrador da sua organização precisa configurar grupos , compartimentos e políticas que controlem quais usuários podem acessar quais serviços, quais recursos e o tipo de acesso. Por exemplo, as políticas controlam quem pode criar novos usuários, criar e gerenciar a rede na nuvem, iniciar instâncias, criar buckets, fazer download de objetos e assim por diante. Para obter mais informações, consulte Conceitos Básicos de Políticas. Para ver detalhes específicos sobre a gravação de políticas para cada um dos diversos serviços, consulte Referência de Políticas.
Se você for um usuário convencional (não um administrador) que precisa usar os recursos do Oracle Cloud Infrastructure que sua empresa possui, entre em contato com o administrador para configurar um ID de usuário para você. O administrador pode confirmar qual compartimento ou quais compartimentos você deve usar.
Para obter mais informações sobre autorizações do usuário para monitoramento, consulte Políticas do Serviço IAM.
Administradores: Para políticas comuns que concedem aos grupos acesso a métricas, consulte Acesso a Métricas para Grupos. Para políticas comuns de alarme, consulte Acesso a Alarmes para Grupos. Para autorizar recursos, como instâncias, para fazer chamadas de API, adicione os recursos a um grupo dinâmico. Use as regras de correspondência do grupo dinâmico para adicionar os recursos e, em seguida, crie uma política que permita que esse grupo dinâmico acesse as métricas. Consulte Acesso a Métricas para Recursos.
Limites do Serviço Monitoring
Consulte Limites do Serviço Monitoring para obter uma lista dos limites e instruções aplicáveis para solicitar um aumento de limite.
Outros limites incluem o seguinte.
Limites de Armazenamento
Item | Intervalo de tempo de armazenamento |
---|---|
Definições de métrica | 90 dias |
Entradas do histórico de alarmes | 90 dias |
Limites de Dados Retornados (Métricas)
Quando você consulta métricas e exibe gráficos de métricas, os dados retornados estão sujeitos a determinados limites. As informações de limites para os dados retornados incluem o máximo de 100.000 pontos de dados e os máximos de intervalo de tempo (determinados pela resolução, relacionada ao intervalo).. Consulte MetricData.
Limites de Mensagem de Alarme
O número máximo de mensagens por avaliação de alarme depende do destino do alarme. Os limites estão associados ao serviço do Oracle Cloud Infrastructure usado para o destino.
O serviço Monitoring rastreia 200.000 streams de métrica por alarme para eventos de qualificação. Para obter mais informações sobre avaliações de alarme, consulte Avaliações de Alarme nesta página.
Destino do alarme | Entrega | Número máximo de mensagens de alarme por avaliação |
---|---|---|
tópico (Serviço Notifications) | Pelo menos uma vez | 60 |
stream (Streaming) | Pelo menos uma vez | 100,000 |
Por exemplo, considere as avaliações a seguir de um alarme que divide as notificações entre 200 streams de métrica, usando um tópico como seu destino.
Avaliação de alarme (tempo) | Transição do stream de métrica | Mensagens geradas | Mensagens enviadas | Mensagens eliminadas |
---|---|---|---|---|
00:01:00 | 110 streams de métrica mudam de OK para FIRING. | 110 | 60 | 50 |
00:02:00 | 90 streams de métrica mudam de OK para FIRING. | 90 | 60 | 30 |
Quando um tópico ou stream é usado intensivamente, isso pode resultar em notificações de alarme atrasadas. O uso intenso pode ocorrer quando vários recursos estão usando esse tópico ou stream.
Melhores Práticas para Trabalhar Dentro dos Limites
Quando você esperar um alto volume de notificações de alarme, siga essas melhores práticas para ajudar a evitar exceder os limites de mensagens de alarme e atrasos associados.
- Reserve um único tópico ou stream para uso com um alarme de alto volume. Não use um tópico ou stream para vários alarmes de alto volume.
- Se você esperar mais de 60 mensagens por minuto, especifique Streaming como destino do alarme.
- Streams:
- Crie partições com base na carga esperada. Consulte Limites de Recursos do Serviço Streaming.
- Se as mensagens de alarme excederem o espaço de stream, atualize o alarme para usar um stream diferente que tenha mais partições. Por exemplo, se o stream original contiver cinco partições, crie um stream com dez partições e, em seguida, atualize o alarme para usar o novo stream.Observação
Para evitar mensagens ausentes, continue consumindo o stream original até que nenhuma outra mensagem seja recebida.
- Aumente os limites da tenancy:
- Tópicos: Consulte Limites para publicação de mensagens (operação PublishMessage).
- Streams: Consulte Limites de Recursos do Serviço Streaming.
Limites de Diagnóstico e Solução de Problemas
Para solucionar problemas de um erro de consulta para muitos streams de métrica, consulte Erro: Número Máximo de Streams de Métrica Excedido.
Para obter informações sobre solução de problemas, consulte Diagnosticando e Solucionando Problemas do Serviço Monitoring.
Segurança
Este tópico descreve a segurança do serviço Monitoring.
Para obter informações sobre como proteger o serviço Monitoring, incluindo informações e recomendações de segurança, consulte Protegendo o Serviço Monitoring.