In this article, we’ll explore how Oracle Database fits into the modern, open-source, and cloud-native observability stack.
What is OpenTelemetry?
OpenTelemetry is an open-source observability framework that provides a standardized way to collect and process telemetry data, including traces, metrics, and logs:
- Standardizes across tools and vendors, allowing you to send data to any backend that supports OpenTelemetry.
- Supports modern architectures, where cloud-native microservices greatly benefit from consistent telemetry collection.
- Provides end-to-end visibility in distributed systems, facilitating faster debugging, performance optimizations, and incident response.
OpenTelemetry is the de-facto standard for the modern observability stack, facilitating data exchange between a vast registry of components and systems.
The Oracle Database Metrics Exporter is part of the OpenTelemetry component registry, where you can find many other awesome observability components!
Extend and modify database metrics
The exporter ships with a set of default metrics, defined in TOML or YAML format. GV$ views and INST_ID labels are used whenever possible, effectively monitoring clustered databases (Oracle RAC).
[[metric]]
context = "sessions"
labels = [ "inst_id", "status", "type" ]
metricsdesc = { value= "Gauge metric with count of sessions by inst_id, status and type." }
request = '''
select inst_id, status, type, count(*) as value
from gv$session
group by inst_id, status, type
'''Metrics are exposed over HTTP in Prometheus/OpenTelemetry format.
Default database metrics are extensible with user-defined, custom metrics. The exporter dynamically loads custom metric files as metrics:
metrics:
## Optional, path to override default metrics.
default: default-metrics.toml
## Paths to any custom metrics files (TOML or YAML)
custom:
- /custom-metrics-example/custom-metrics.toml
- /metrics/my-metrics.tomlIf you define a metric more than once, the exporter uses the last definition provided. You can redefine any metric and automatically hot-reload it with the file-watcher feature.
Supplementing default and custom metrics, example Grafana dashboards are provided for inspiration and customization.
Monitor one or more databases
The exporter concurrently collects both metrics and alert logs from one or more Oracle Database servers, serving data over the /metrics HTTP endpoint.
Configure database connections in the exporter’s configuration file. Each database connected to the exporter will label metrics with the DB name (db1, db2, etc.):
databases:
db1:
# database config
db2:
# database config
db3:
# database configIf a metric applies only to specific databases, define an array of supported databases so the exporter collects that metric only from them:
[[metric]]
context = "db_platform"
labels = [ "platform_name" ]
metricsdesc = { value = "Database platform" }
request = '''
SELECT platform_name, 1 as value FROM gv$database
'''
# collect only from db2 and db3
databases = [ "db2", "db3" ]When the databases array is nil, the exporter collects the metric from all databases. When the databases array is non-nil but empty, the exporter disables the metric for all databases.
Run anywhere, with any database
The exporter runs as a standalone agent, with pre-built binaries and container images available for external consumption (linux arm64/amd64 and darwin arm64 provided) .
Plaintext, TLS, and mTLS database authentication with Oracle Wallet allows you to connect to any database, with optional database resident connection pool configuration. You may also securely load database credentials from Oracle Vault or Azure Vault.
While the exporter officially supports Oracle Database versions 19c and 23ai, older database versions may work with the appropriate instant client versions. Older databases are not officially supported nor recommended.
Leave a Reply