TL;DR: O OCI PostgreSQL expõe métricas automáticas sob o namespace oci_postgresql, abrangendo CPU, memória, armazenamento, conexões, I/O, cache, concorrência e replicação. Elas podem ser visualizadas no console, consultadas via MQL e usadas para alarmes. A integração com ferramentas como Datadog via Connector Hub e OCI Functions permite um observability centralizado. Para empresas brasileiras, isso significa maior previsibilidade operacional e redução de riscos em ambientes críticos.
1. Overview
O OCI PostgreSQL expõe um conjunto abrangente de métricas através do serviço OCI Monitoring, sob o namespace oci_postgresql. Elas estão disponíveis diretamente no Console do OCI PostgreSQL, em Monitoring → Metrics, com acesso fácil para visualização e análise.
Essas métricas oferecem visibilidade sobre aspectos-chave como desempenho do banco de dados, utilização de armazenamento, comportamento de conexões e status da replicação. São coletadas automaticamente e podem ser visualizadas em dashboards, consultadas usando MQL (Monitoring Query Language) ou usadas para configurar alarmes. Isso permite um monitoramento consistente e integração com os workflows de observabilidade do OCI.
As métricas são coletadas automaticamente e podem ser:
- Visualizadas em dashboards
- Consultadas usando MQL
- Usadas para configurar alarmes e notificações
Supported Dimensions
Todas as métricas suportam as seguintes dimensões:
resourceTyperesourceNameresourceIddbInstanceRoledbInstanceId
Essas dimensões permitem filtragem e agregação em nível de instância, papel (primary/replica) e recursos.
2. Metrics Chart
As métricas do OCI PostgreSQL estão disponíveis tanto para instâncias Primary quanto Replica, permitindo monitoramento em todo o nó do DBSystem.
- Filtrar métricas por papel da instância (Primary/Replica)
- Comparar desempenho entre nós
- Analisar distribuição de workload
3. Metrics Description by Category
As métricas são organizadas em categorias para fornecer uma visão estruturada do comportamento do banco de dados em computação, armazenamento, sessões e replicação. Essa organização facilita a navegação e compreensão dentro do dashboard do OCI Monitoring.
🧩 Resource Utilization Metrics
3.1. 🔹 CPU Utilization
Representa o uso da CPU em relação à capacidade de computação alocada. Reflete como as workloads do banco de dados utilizam os recursos de processamento ao longo do tempo.
Ajuda a: entender padrões de consumo de computação; observar a eficiência do uso da CPU.
X-axis: DateTime
Y-axis: Percentage (%)
Exemplo: CPU utilization indicando uso de recursos de CPU disponíveis.
3.2. 🔹 Memory Utilization
Indica a porcentagem da memória total atualmente em uso. Inclui memória consumida por processos do banco, buffers e operações.
Ajuda a: acompanhar o comportamento do consumo de memória; fornecer visibilidade sobre como os recursos de memória estão sendo utilizados.
X-axis: DateTime
Y-axis: Percentage (%)
Exemplo: Memory utilization mostrando que a maior parte da memória alocada está em uso.
OCI Memory Management: o OCI PostgreSQL pré-aloca aproximadamente 50% da memória total para o page cache e 25% para shared_buffers. Como resultado, cerca de 75% da memória total é alocada por padrão, e observar aproximadamente 80% de utilização de memória imediatamente após o provisionamento é um comportamento normal em todas as shapes.
🧩 Connection & Session Metrics
3.3. 🔹 DB Connections
Representa o número total de conexões de clientes ativas. Inclui todas as sessões estabelecidas por aplicações ou usuários externos.
Ajuda a: monitorar a carga de conexões no banco; fornecer insight sobre padrões de acesso simultâneo.
X-axis: DateTime
Y-axis: Count
Exemplo: 150 connections indicam 150 clientes conectados simultaneamente.
3.4. 🔹 Active Sessions
Mostra o número de sessões atualmente executando queries. Essas sessões representam a workload ativa do banco.
Ajuda a: entender a concorrência e a intensidade da workload; indicar quantas operações estão rodando em um dado momento.
X-axis: DateTime
Y-axis: Count
Exemplo: 20 active sessions indicam 20 queries rodando ao mesmo tempo.
3.5. 🔹 Idle Sessions
Representa sessões que estão conectadas mas não executando queries. Essas sessões permanecem abertas sem realizar trabalho ativo.
Ajuda a: identificar conexões não utilizadas ou ociosas; útil para entender a eficiência de utilização de conexões.
X-axis: DateTime
Y-axis: Count
Exemplo: 40 idle sessions indicam muitas conexões abertas, mas inativas.
3.6. 🔹 Idle In Transaction
Representa sessões ociosas enquanto mantêm transações abertas. Essas sessões podem ainda reter locks ou recursos do banco.
Ajuda a: acompanhar o comportamento de sessões transacionais; indicar sessões inativas que ainda seguram recursos.
X-axis: DateTime
Y-axis: Count
Exemplo: 5 sessions idle in transaction indicam transações abertas sem atividade.
🧩 Storage Metrics
3.7. 🔹 Used Storage
Representa o armazenamento total consumido por dados e índices do banco. Inclui todos os componentes de armazenamento alocados e utilizados.
Ajuda a: acompanhar o uso do armazenamento ao longo do tempo; fornecer visibilidade sobre padrões de crescimento do banco.
X-axis: DateTime
Y-axis: Gigabytes (GB)
Exemplo: 400 GB indica o uso total de armazenamento do banco.
3.8. 🔹 WAL Storage
Representa o armazenamento consumido pelos Write-Ahead Logs. Inclui dados de log gerados para durabilidade e replicação.
Ajuda a: monitorar o acúmulo de dados WAL; fornecer insight sobre a utilização do armazenamento de log.
X-axis: DateTime
Y-axis: Gigabytes (GB)
Exemplo: 30 GB WAL storage indica dados de log acumulados.
🧩 I/O & Throughput Metrics
3.9. 🔹 Read IOPS
Representa o número de operações de leitura por segundo. Indica com que frequência os dados são acessados no armazenamento.
Ajuda a: observar padrões de workload de leitura; útil para entender a frequência de acesso a dados.
X-axis: DateTime
Y-axis: Count (operations/sec)
Exemplo: 900 read IOPS indica 900 operações de leitura por segundo.
3.10. 🔹 Write IOPS
Representa o número de operações de escrita por segundo. Indica com que frequência os dados são gravados no armazenamento.
Ajuda a: monitorar a atividade de escrita; fornecer insight sobre padrões de modificação de dados.
X-axis: DateTime
Y-axis: Count (operations/sec)
Exemplo: write IOPS indica atividade intensa de escrita.
3.11. 🔹 Read Latency
Representa o tempo necessário para concluir operações de leitura. Indica a responsividade do sistema de armazenamento para leituras.
Ajuda a: medir características de desempenho de leitura; útil para entender o timing de recuperação de dados.
X-axis: Date Time
Y-axis: Milliseconds (ms)
Exemplo: 1 ms read latency indica recuperação rápida de dados.
3.12. 🔹 Write Latency
Representa o tempo necessário para concluir operações de escrita. Indica a responsividade do sistema de armazenamento para escritas.
Ajuda a: medir características de desempenho de escrita; fornecer visibilidade sobre o timing das operações de escrita.
X-axis: Date Time
Y-axis: Milliseconds (ms)
Exemplo: 5 ms write latency indica um atraso moderado em escritas.
3.13. 🔹 Average Read Latency
Representa o tempo médio para operações de leitura. Fornece uma visão agregada da latência de leitura ao longo do tempo.
Ajuda a: observar tendências gerais de desempenho de leitura; útil para analisar o comportamento médio de resposta.
X-axis: Date Time
Y-axis: Milliseconds (ms)
Exemplo: 1.5 ms average read latency mostra o timing típico de leitura.
3.14. 🔹 Read Kilobytes
Representa o volume de dados lidos por segundo. Indica a throughput de operações de leitura em kilobytes.
Ajuda a: analisar o volume de acesso a dados; fornecer insight sobre padrões de leitura.
X-axis: Date Time
Y-axis: Kilobytes/sec (KB/s)
Exemplo: 6000 KB/s indica throughput de leitura.
3.15. 🔹 Write Kilobytes
Representa o volume de dados escritos por segundo. Indica a throughput de operações de escrita em kilobytes.
Ajuda a: analisar o volume de escrita de dados; fornecer insight sobre padrões de modificação.
X-axis: Date Time
Y-axis: Kilobytes/sec (KB/s)
Exemplo: 8000 KB/s indica throughput de escrita.
🧩 Cache & Efficiency Metrics
3.16. 🔹 Buffer Cache Hit Ratio
Representa a porcentagem de leituras servidas da memória. Indica com que frequência os dados são recuperados do cache em vez do disco.
Ajuda a: avaliar a eficiência do cache; fornecer visibilidade sobre o uso de memória versus disco.
X-axis: Date Time
Y-axis: Percentage (%)
Exemplo: 95% hit ratio indica que a maioria dos dados foi servida do cache.
🧩 Concurrency & Query Metrics
3.17. 🔹 Deadlocks
Representa o número de eventos de deadlock entre transações. Ocorre quando transações se bloqueiam mutuamente indefinidamente.
Ajuda a: identificar conflitos transacionais; fornecer visibilidade sobre problemas de concorrência.
X-axis: DateTime
Y-axis: Count
Exemplo: deadlocks indicam conflitos entre transações.
3.18. 🔹 Number of Blocked Queries
Representa queries aguardando devido a locks retidos por outras sessões. Indica condições de bloqueio no banco.
Ajuda a: monitorar contenção de queries; fornecer insight sobre comportamento de locks.
X-axis: DateTime
Y-axis: Count
Exemplo: blocked queries indicam operações em espera.
3.19. 🔹 Number of Long-running Queries (Over 5 Minutes)
Representa queries rodando por mais de cinco minutos. Indica operações de execução prolongada.
Ajuda a: identificar workloads de longa duração; fornecer visibilidade sobre tempo de execução de queries.
X-axis: DateTime
Y-axis: Count
Exemplo: long-running queries indicam operações prolongadas.
🧩 Replication Metrics
3.20. 🔹 Replication Lag
Representa o lag entre primary e replica em dados WAL. Indica quanto dados estão pendentes para serem aplicados na replica.
Ajuda a: acompanhar a sincronização da replicação; fornecer visibilidade sobre o status da replicação.
X-axis: DateTime
Y-axis: Megabytes (MB)
Exemplo: 200 MB lag indica atraso na replicação.
4. Metrics Options Menu (⋯)
O Metrics Options Menu (⋯) fornece acesso rápido a ações adicionais para cada painel de métrica. Capacidades-chave:
- Explorar queries avançadas
- Compartilhar visualizações de métricas
- Criar alarmes diretamente
4.1. View Query in Metrics Explorer
Abre a métrica selecionada no Metrics Explorer, fornecendo uma interface mais avançada para análise. Permite refinar queries, aplicar filtros adicionais, alterar agregações e analisar tendências usando MQL.
4.2. Copy Chart URL
Gera uma URL compartilhável para o gráfico atual. O link preserva o intervalo de tempo selecionado, filtros e configurações de visualização, facilitando o compartilhamento de insights.
4.3. Copy Query (MQL)
Copia a expressão MQL subjacente usada para a métrica. Essa query pode ser reutilizada no Metrics Explorer, alarmes ou workflows de automação para monitoramento consistente.
4.4. Create an Alarm on this Query
Permite criar rapidamente um alarme usando a métrica atual e configuração de query. A query é pré-preenchida, acelerando a configuração de alertas baseados em thresholds e integração com OCI Notifications.
5. Alarms & Notifications
O OCI Monitoring permite criar alarmes baseados nas métricas do PostgreSQL definindo condições de threshold usando MQL. Quando uma métrica ultrapassa a condição definida, o alarme é acionado e envia notificações através de canais configurados como email ou webhooks.
Componentes do alarme:
- Metric query (MQL)
- Threshold condition
- Evaluation interval
- Trigger rule
Você pode seguir a documentação oficial do OCI para configurar alarmes: Create an Alarm in OCI Monitoring.
6. Notifications Integration
O serviço OCI Notifications é usado para entregar mensagens quando alarmes são acionados no OCI PostgreSQL Monitoring. Você pode criar um topic de notificação e adicionar assinaturas como email, HTTPS/webhooks ou integrações como Slack e Message. Uma vez configurado, alarmes podem ser vinculados a um topic para notificar automaticamente os assinantes quando condições são atendidas. Isso permite alertas contínuos e integração com sistemas externos.
- Criar um Topic
- Adicionar assinaturas:
- HTTPS/Webhook
- Integrações externas
- Notificações são acionadas automaticamente quando condições de alarme são atendidas.
Documentação oficial: Notification setup.
7. Third-Party Monitoring Tool Integration
As métricas do OCI PostgreSQL podem ser integradas com ferramentas de observabilidade de terceiros, como o Datadog, para permitir monitoramento centralizado em ambientes multi-cloud ou híbridos.
Como funciona:
- OCI Metrics → Connector Hub
- Connector → OCI Functions
- Functions → External tool (Datadog API)
Por exemplo, na integração com Datadog, métricas do namespace oci_postgresql são encaminhadas via Connector Hub para OCI Functions, que então enviam os dados para o Datadog usando ingestão baseada em API. Essa configuração permite dashboards, alertas e monitoramento em tempo real dentro do Datadog.
Tutorial para integração com Datadog: Tutorial OCI PostgreSQL using Datadog.
8. Summary
As métricas do OCI PostgreSQL fornecem uma estrutura de monitoramento abrangente e organizada para ambientes de banco de dados. Ao aproveitar as métricas nativas, os usuários ganham visibilidade sobre utilização de computação, comportamento de armazenamento, padrões de conexão e status de replicação.
A integração com OCI Monitoring, alarmes e notificações permite detecção proativa de problemas e alertas automatizados. Além disso, o suporte para monitoramento de instâncias primary e replica, juntamente com integrações de terceiros como Datadog, possibilita uma observabilidade flexível e escalável.
Em resumo, as métricas do OCI PostgreSQL ajudam as organizações a manter desempenho, confiabilidade e eficiência operacional através de uma abordagem centralizada de monitoramento.
9. Additional Resources
Perguntas Frequentes
-
Quais métricas de replicação estão disponíveis e como interpretá-las?
A métrica principal éReplication Lag, medida em MB, que indica a diferença de dados entre primary e replica no WAL. Lags elevados podem comprometer a consistência de leitura em réplicas; o ideal é manter abaixo de alguns MB para aplicações com requisitos de baixa latência. -
Como configurar alarmes para evitar custos inesperados com armazenamento?
Use a métricaUsed Storagecom MQL para definir thresholds (ex.: 80% do total provisionado). Associe o alarme a um tópico de notificação (email ou webhook) para alertar antes que o armazenamento se esgote, evitando impacto em produção e custos de expansão emergencial. -
É possível exportar as métricas do OCI PostgreSQL para o Datadog?
Sim. Através do OCI Connector Hub, as métricas são enviadas para OCI Functions, que as encaminha para a API do Datadog. Isso permite dashboards unificados em ambientes multi-cloud, sem expor dados sensíveis publicamente. -
O que significa a métrica Buffer Cache Hit Ratio e qual é um valor saudável?
Ela indica a porcentagem de leituras servidas do cache em vez do disco. Valores acima de 95% são considerados saudáveis; abaixo disso pode indicar necessidade de aumentar shared_buffers ou otimizar queries. -
Como diferenciar entre conexões idle comuns e idle in transaction?
A métricaIdle In Transactioné mais crítica, pois mantém locks e recursos.Idle Sessionsnormais não retêm recursos significativos. Monitorar ambas ajuda a identificar sessions que precisam ser encerradas para liberar conexões.
Artigo originalmente publicado por Arvind Yadav em cloud-infrastructure.
