Ce document présente l'utilisation de l'API Telemetry (OTLP), telemetry.googleapis.com, pour l'ingestion de journaux au format OTLP dans Cloud Logging, où ils sont stockés sous forme d'entrées de journal.
Pour obtenir un exemple, consultez Écrire des journaux au format OTLP dans l'API Telemetry.
Vous pouvez également envoyer des journaux à l'API Telemetry à partir d'applications qui utilisent des SDK ou à l'aide d'un collecteur OpenTelemetry.
Pour en savoir plus sur l'API Telemetry pour les journaux, les métriques et les traces, consultez la documentation de référence sur l'API Telemetry (OTLP).
Compatibilité avec le protocole
Le point de terminaison OTLP est compatible avec tous les protocoles OTLP, y compris http/protobuf, http/json et grpc. Lorsque vous exportez des données à partir d'un collecteur OpenTelemetry, vous pouvez utiliser n'importe quel protocole. Toutefois, en raison du manque de prise en charge de l'actualisation dynamique des jetons dans la plupart des exportateurs de SDK, si vous exportez directement à partir de SDK, nous vous recommandons d'utiliser uniquement l'exportateur OTLP gRPC, et non les exportateurs HTTP.
Facturation
Lorsque vous utilisez l'API Telemetry pour ingérer des journaux, vous pouvez constater une modification des valeurs de stockage et de facturation de Cloud Logging. Une requête de journal au format OTLP en JSON présente la structure générale suivante :
"resourceLogs": [
{
"resource": {
"attributes": [...]
},
"scopeLogs": [
{
"scope": { ...}
"logRecords": [...]
}
]
}
]
Chaque élément de chaque tableau logRecords devient une entrée de journal Cloud Logging. Les changements les plus importants apportés au stockage et à la facturation de votre projet Google Cloud se produisent lorsque les deux conditions suivantes sont remplies :
Le champ
resourcecontient un grand nombre d'attributs obligatoires pour les clés et les valeurs. Ces attributs de ressource permettent de déterminer la ressource surveillée dans leLogEntryrésultant.La ressource surveillée se compose d'un type de ressource surveillée Cloud Logging et des valeurs de ses libellés associés. Certains types de ressources surveillées ne comportent que quelques libellés, tandis que d'autres en comportent de nombreux. Pour savoir quels attributs sont requis pour l'ingestion de journaux au format OTLP, consultez Mappage des attributs OTLP aux types de ressources.
Le champ
scopeLogscontient un grand nombre d'éléments dans les tableauxlogRecords.
Pour prendre en charge l'ingestion de journaux au format OTLP, la structure LogEntry de Cloud Logging contient un champ supplémentaire, otel. Les modèles de données OTLP et Cloud Logging ne sont pas parfaitement compatibles. Le champ otel contient donc une copie des ressources, des portées et des entités OTLP de la requête OTLP entrante.
Par exemple, si vous envoyez un resourceLog OTLP comme celui ci-dessous à l'API Telemetry, chaque entrée de journal résultante contient un champ resource (pour la ressource surveillée) et un champ otel, comme indiqué dans les autres onglets :
resourceLog
{
"resourceLogs": [
{
"resource": {
"attributes": [
{
"key": "gcp.project_id",
"value": { "stringValue": "PROJECT_ID" }
},
{
"key": "gcp.resource_type",
"value": { "stringValue": "global" }
}
]
},
"scopeLogs": [
{
"scope": {
"name": "my.library",
"version": "1.0.0",
"attributes": [
{
"key": "my.scope.attribute",
"value": { "stringValue": "some scope attribute" }
}
]
},
"logRecords": [ ... ]
}
]
}
]
}
resource
{
...
"resource": {
"labels": {
"project_id": "PROJECT_ID"
},
"type": "global"
},
...
}
otel
{
...
"otel": {
"resource": {
"attributes": {
"gcp.project_id": "PROJECT_ID",
"gcp.resource_type": "global"
}
},
"scope": {
"attributes": {
"my.scope.attribute": "some scope attribute"
},
"name": "my.library",
"version": "1.0.0"
}
},
...
}
Cloud Logging n'a aucun moyen d'associer d'autres ressources à une entrée de journal. Toutes les informations sur les ressources, les champs d'application et les entités OTLP doivent donc être copiées dans chaque entrée de journal.
Cette duplication permet de conserver autant d'informations que possible de la demande d'origine dans l'entrée de journal résultante. Toutefois, la duplication signifie également que le champ otel répète les informations sur les ressources qui sont également utilisées dans le champ monitored-resource (resource) de l'entrée de journal. Le champ resource de l'entrée de journal est facturable, mais les informations sur les ressources dupliquées dans le champ otel ne le sont pas.
Lorsque vous incluez un grand nombre d'enregistrements de journaux dans la requête OTLP, les informations OTLP doivent être copiées dans chaque entrée de journal résultante, dans les champs resource et otel. Bien que le stockage des copies du champ otel ne soit pas facturable, celui des copies supplémentaires du champ resource l'est. Lorsque vous incluez un grand nombre de logRecords OTLP dans une requête, le nombre de champs resource facturables dans vos entrées de journal augmente proportionnellement au nombre de logRecords OTLP par resource par requête.
Pour minimiser les informations supplémentaires stockées, nous vous recommandons d'envoyer un élément logRecord par requête.
Limites et quotas
Pour en savoir plus sur les limites et les quotas associés à l'utilisation de l'API Telemetry pour la journalisation, consultez Limites et quotas pour l'ingestion des journaux.
Les quotas et limites de Cloud Logging s'appliquent également lorsque vous utilisez l'API Telemetry pour l'ingestion de journaux.