Interrogation directe des données Amazon CloudWatch Logs dans Service OpenSearch

Les requêtes interactives sont utilisées pour renseigner le sélecteur de données et effectuer des analyses sur vos données dans CloudWatch Logs. OpenSearch Le service gère chaque requête avec une tâche préchauffée distincte, sans maintenir de session prolongée.

Les requêtes de vues indexées utilisent le calcul pour maintenir les vues indexées dans OpenSearch Service. Ces requêtes prennent généralement plus de temps car elles ingèrent une quantité variable de données dans un index nommé. Pour les sources de données connectées à CloudWatch Logs, les données indexées sont stockées dans une collection OpenSearch sans serveur où vous êtes facturé pour les données indexées (IndexingOCU), les données recherchées (SearchOCU) et les données stockées en Go.

L'intégration directe des requêtes avec CloudWatch Logs n'est disponible que sur les collections de OpenSearch services et sur OpenSearch l'interface utilisateur.

OpenSearch Les collections sans serveur ont des limites de charge utile en réseau de 100 MiB.

CloudWatch Logs prend en charge les intégrations de VPC Flow et AWS WAF de tableau de bord installées depuis la console. CloudTrail

AWS CloudFormation les modèles ne sont pas encore pris en charge.

OpenSearch Les instructions SQL et OpenSearch PPL présentent des limites différentes lors de l'utilisation d' OpenSearch index par rapport à l'utilisation de requêtes directes. La requête directe prend en charge les commandes avancées telles que JOINs les sous-requêtes et les recherches, tandis que la prise en charge de ces commandes sur les OpenSearch index est limitée, voire inexistante. Pour de plus amples informations, veuillez consulter Commandes SQL et PPL prises en charge.

Lorsque vous recherchez plusieurs groupes de journaux dans une seule requête, utilisez la syntaxe appropriée. Pour de plus amples informations, veuillez consulter Fonctions de groupe multilog.

Lorsque vous utilisez des commandes SQL ou PPL, entourez certains champs de backticks pour les interroger correctement. Les champs contenant des caractères spéciaux (non alphabétiques et non numériques) doivent être cochés. Par exemple, joignez Operation.Export, et @message insérez des Test::Field backticks. Il n'est pas nécessaire de placer des colonnes avec des noms purement alphabétiques en backticks.

Exemple de requête avec des champs simples :

SELECT SessionToken, Operation, StartTime  FROM `LogGroup-A`
LIMIT 1000;

Requête similaire avec backticks ajoutés :

SELECT `@SessionToken`, `@Operation`, `@StartTime` FROM `LogGroup-A`
LIMIT 1000;

Limitez vos requêtes pour vous assurer de ne pas récupérer trop de données.

Les requêtes contenant des noms de champs identiques mais ne différant que par des majuscules (tels que field1 etFIELD1) ne sont pas prises en charge.

Par exemple, les requêtes suivantes ne sont pas prises en charge :

Select AWSAccountId, AwsAccountId from LogGroup
Select a.@LogStream, b.@logStream from Table A INNER Join Table B ona.id = b.id

Cependant, la requête suivante est prise en charge car le nom du champ (@logStream) est identique dans les deux groupes de journaux :

Select a.@logStream, b.@logStream from Table A INNER Join Table B on a.id = b.id

Les fonctions et expressions doivent agir sur les noms de champs et faire partie d'une SELECT instruction avec un groupe de journaux spécifié dans la FROM clause.

Par exemple, cette requête n'est pas prise en charge :

SELECT cos(10) FROM LogGroup

Cette requête est prise en charge :

SELECT cos(field1) FROM LogGroup

Asie-Pacifique (Mumbai)

Asie-Pacifique (Hong Kong)

Asie-Pacifique (Osaka)

Asia Pacific (Seoul)

Asie-Pacifique (Singapour)

Asie-Pacifique (Sydney)

Asie-Pacifique (Tokyo)

Canada (Centre)

Europe (Francfort)

Europe (Irlande)

Europe (Stockholm)

Europe (Milan)

Europe (Espagne)

USA Est (Virginie du Nord)

USA Est (Ohio)

USA Ouest (Oregon)

USA Ouest (Californie du Nord)

Europe (Paris)

Europe (Londres)

Amérique du Sud (Sao Paulo)