L'API Observability utilise des ressources personnalisées Kubernetes et s'appuie sur le modèle de ressources Kubernetes (KRM) pour provisionner et gérer les ressources de journalisation et de surveillance.
Utilisez l'API Observability pour gérer le cycle de vie des services d'observabilité dans une organisation ou un projet personnalisé donné. Le cycle de vie des services d'observabilité inclut des opérations telles que l'installation, la mise à niveau et la désinstallation. Vous devez déployer une ressource personnalisée dans votre projet en fonction du service d'observabilité que vous souhaitez gérer.
De nombreux services d'observabilité sont disponibles automatiquement pour un projet provisionné, par exemple la journalisation, la surveillance et les alertes.
Point de terminaison de service
Les URL suivantes sont les points de terminaison de l'API KRM d'observabilité :
Groupe de journalisation :
https://MANAGEMENT_API_SERVER_ENDPOINT/apis/logging.gdc.goog/v1Groupe de surveillance :
https://MANAGEMENT_API_SERVER_ENDPOINT/apis/monitoring.gdc.goog/v1Groupe d'observabilité :
https://MANAGEMENT_API_SERVER_ENDPOINT/apis/observability.gdc.goog/v1
Remplacez MANAGEMENT_API_SERVER_ENDPOINT par le point de terminaison du serveur de l'API Management.
Document de découverte
Utilisez la commande kubectl proxy --port=8001 pour ouvrir un proxy vers le serveur d'API sur votre ordinateur local. Vous pouvez ensuite accéder au document de découverte à l'une des URL suivantes :
http://127.0.0.1:8001/apis/logging.gdc.goog/v1http://127.0.0.1:8001/apis/monitoring.gdc.goog/v1http://127.0.0.1:8001/apis/observability.gdc.goog/v1
Exemples de ressources
Cette section contient des exemples de ressources qui utilisent l'API KRM d'observabilité.
Groupe de journalisation
Voici un exemple de ressource personnalisée LoggingTarget permettant de collecter les journaux de services spécifiques dans le projet project-1 :
# Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
# Choose a namespace that matches the namespace of the workload pods
namespace: project-1
name: my-service-logging-target
spec:
# Choose a matching pattern that identifies the pods for this job
# Optional
# Relationship between different selectors: 'AND'
selector:
# The clusters to collect logs from.
# The default configuration is to collect logs from all clusters.
# The relationship between different clusters is an 'OR' relationship.
# For example, the value '["admin", "system"]' indicates to consider
# the admin cluster 'OR' the system cluster.
# Optional
matchClusters:
- cluster-1
- cluster-2
# The pod name prefixes to collect logs from.
# The Observability platform scrapes all pods with names
# that start with the specified prefixes.
# The values must contain '[a-z0-9-]' characters only.
# The relationship between different list elements is an 'OR' relationship.
# Optional
matchPodNames:
- pod-1
- pod-2
# The container name prefixes to collect logs from.
# The Observability platform scrapes all containers with names
# that start with the specified prefixes.
# The values must contain '[a-z0-9-]' characters only.
# The relationship between different list elements is an 'OR' relationship.
# Optional
matchContainerNames:
- container-1
- container-2
# Choose the predefined parser for log entries.
# Use parsers to map the log output to labels and extract fields.
# Specify the log format.
# Optional
# Options: klog_text, klog_json, klogr, gdch_json, json
parser: klog_text
# Specify an access level for log entries.
# The default value is 'ao'.
# Optional
# Options: ao, pa, io
logAccessLevel: ao
# Specify a service name to be applied as a label
# For user workloads consider this field as a workload name
# Required
serviceName: service-name
# The additional static fields to apply to log entries.
# The field is a key-value pair, where the field name is the key and
# the field value is the value.
# Optional
additionalFields:
app: workload2
key: value
Groupe de surveillance
Voici un exemple de ressource personnalisée MonitoringTarget permettant de collecter des métriques à partir de charges de travail sur le projet project-1 :
apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
# Choose the same namespace as the workload pods
namespace: project-1
name: string
spec:
# Choose matching pattern that identifies pods for this job
# Optional
# Relationship between different selectors: AND
selector:
# Choose clusters to consider for this job
# Optional
# List
# Default: All clusters applicable to this project.
# Relationship between different list elements: OR
matchClusters:
- string
# Choose pod-labels to consider for this job
# Optional: Map of key-value pairs.
# Default: No filtering by label.
# Relationship between different pairs: AND
matchLabels:
key1: value1
# Choose annotations to consider for this job
# Optional: Map of key-value pairs
# Default: No filtering by annotation
# Relationship between different pairs: AND
matchAnnotations:
key1: value1
# Configure the endpoint exposed for this job
podMetricsEndpoints:
# Choose port either via static value or annotation
# Optional
# Annotation takes priority
# Default: static port 80
port:
value: integer
annotation: string
# Choose path either via static value or annotation
# Optional
# Annotation takes priority
# Default: static path /metrics
path:
value: string
annotation: string
# Choose scheme either via static value (http or https) or annotation
# Optional
# Annotation takes priority
# Default: static scheme http
scheme:
value: string
annotation: string
# Choose the frequency to scrape the metrics endpoint defined in podMetricsEndpoints
# Optional
# Default: 60s
scrapeInterval: string
# Dynamically rewrite the label set of a target before it gets scraped.
# https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config
# Optional
# Default: No filtering by label
metricsRelabelings:
- sourceLabels:
- string
separator: string
regex: string
action: string
targetLabel: string
replacement: string
Groupe d'observabilité
Voici un exemple de ressource personnalisée ObservabilityPipeline permettant de mettre à jour la taille de stockage des tableaux de bord dans l'espace de noms du projet platform-obs :
# Configure observability pipeline
apiVersion: observability.gdc.goog/v1
kind: ObservabilityPipeline
metadata:
# Don't change the namespace or name.
namespace: platform-obs
name: observability-config
spec:
...
monitoring:
grafana:
storageSize: 1Gi # Configure the new storage size for dashboards in the project.
...