Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de tableaux de bord (colocalisés avec le cluster) avec Amazon Service OpenSearch

Les tableaux de bord (colocalisés avec le cluster) sont un outil de visualisation open source conçu pour fonctionner avec. OpenSearch Amazon OpenSearch Service fournit une installation de tableaux de bord pour chaque domaine OpenSearch de service. Les tableaux de bord s'exécutent sur les nœuds de données actifs du domaine. Si vous recherchez de la documentation sur la nouvelle interface OpenSearch utilisateur centralisée qui prend en charge plusieurs sources de données sur un seul point de terminaison, consultez la section OpenSearch Interface utilisateur centralisée (tableaux de bord).

Vous trouverez un lien vers les tableaux de bord sur le tableau de bord de votre domaine dans la console OpenSearch de service. Pour les domaines en cours d'exécution OpenSearch, URL c'estdomain-endpoint/_dashboards/. Pour les domaines exécutant l'ancienne version d'Elasticsearch, c'estURL. domain-endpoint/_plugin/kibana

Les requêtes utilisant cette installation par défaut de Dashboards ont un délai d'expiration de 300 secondes.

Contrôle de l'accès aux tableaux de bord

Les tableaux de bord ne prennent pas en charge nativement IAM les utilisateurs et les rôles, mais OpenSearch Service propose plusieurs solutions pour contrôler l'accès aux tableaux de bord :

Utilisation d'un proxy pour accéder au OpenSearch service à partir de tableaux de bord

Dashboards étant une JavaScript application, les demandes proviennent de l'adresse IP de l'utilisateur. Le contrôle d'accès basé sur l'adresse IP peut ne pas convenir en raison du grand nombre d'adresses IP que vous devriez autoriser afin que chaque utilisateur ait accès à Dashboards. Une solution consiste à placer un serveur proxy entre les tableaux de bord et OpenSearch le service. Ensuite, vous pouvez ajouter une stratégie d'accès basée sur IP qui n'autorise les demandes qu'à partir d'une seule adresse IP, celle du proxy. Le schéma suivant illustre cette configuration.

Pour activer ce type de configuration, il vous faut une politique basée sur les ressources, qui spécifie les rôles et les adresses IP. Voici un exemple de politique :

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Resource":"arn:aws:es:us-west-2:111111111111:domain/my-domain/*",
         "Principal":{
            "AWS":"arn:aws:iam::111111111111:role/allowedrole1"
         },
         "Action":[
            "es:ESHttpGet"
         ],
         "Effect":"Allow"
      },
      {
         "Effect":"Allow",
         "Principal":{
            "AWS":"*"
         },
         "Action":"es:*",
         "Condition":{
            "IpAddress":{
               "aws:SourceIp":[
                  "203.0.113.0/24",
                  "2001:DB8:1234:5678::/64"
               ]
            }
         },
         "Resource":"arn:aws:es:us-west-2:111111111111:domain/my-domain/*"
      }
   ]
}

Nous vous recommandons de configurer l'EC2instance exécutant le serveur proxy avec une adresse IP élastique. De cette manière, vous pouvez remplacer l'instance si nécessaire et continuer de lui attacher la même adresse IP publique. Pour en savoir plus, consultez la section Adresses IP élastiques dans le guide de EC2 l'utilisateur Amazon.

Si vous utilisez un serveur proxy et l'authentification Cognito, il peut être nécessaire d'ajouter des paramètres pour Dashboards et Amazon Cognito afin d'éviter les erreurs redirect_mismatch. Consultez l'exemple nginx.conf suivant :

server {
    listen 443;
    server_name $host;
    rewrite ^/$ https://$host/_plugin/_dashboards redirect;

    ssl_certificate           /etc/nginx/cert.crt;
    ssl_certificate_key       /etc/nginx/cert.key;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    location /_plugin/_dashboards {
        # Forward requests to Dashboards
        proxy_pass https://$dashboards_host/_plugin/_dashboards;

        # Handle redirects to Cognito
        proxy_redirect https://$cognito_host https://$host;

        # Update cookie domain and path
        proxy_cookie_domain $dashboards_host $host;
        proxy_cookie_path / /_plugin/_dashboards/;

        # Response buffer settings
        proxy_buffer_size 128k;
        proxy_buffers 4 256k;
        proxy_busy_buffers_size 256k;
    }

    location ~ \/(log|sign|fav|forgot|change|saml|oauth2) {
        # Forward requests to Cognito
        proxy_pass https://$cognito_host;

        # Handle redirects to Dashboards
        proxy_redirect https://$dashboards_host https://$host;

        # Update cookie domain
        proxy_cookie_domain $cognito_host $host;
    }
}

Configuration des tableaux de bord pour utiliser un serveur de WMS carte

L'installation par défaut de Dashboards for OpenSearch Service inclut un service de carte, à l'exception des domaines des régions de l'Inde et de la Chine. Le service de carte prend en charge jusqu'à 10 niveaux de zoom.

Quelle que soit votre région, vous pouvez configurer les tableaux de bord pour utiliser un autre serveur Web Map Service (WMS) pour les visualisations de cartes de coordonnées. Les visualisations de carte de région prennent uniquement en charge le service de carte par défaut.

Pour appliquer la nouvelle valeur par défaut aux visualisations, vous serez peut-être amené à recharger Dashboards. Si vous avez enregistré des visualisations, choisissez Options après l'ouverture de la visualisation. Vérifiez que le serveur de WMS carte est activé et que WMSl'URL contient votre serveur de carte préféré, puis choisissez Appliquer les modifications.

Connexion d'un serveur de tableaux de bord local au service OpenSearch

Si vous avez déjà investi beaucoup de temps dans la configuration de votre propre instance de tableaux de bord, vous pouvez l'utiliser à la place (ou en complément) de l'instance de tableaux de bord par défaut fournie par OpenSearch Service. La procédure suivante s'applique aux domaines qui utilisent le contrôle précis des accès avec une stratégie d'accès ouverte.

Pour voir les index OpenSearch de vos services, démarrez votre serveur de tableaux de bord local, accédez à Dev Tools et exécutez la commande suivante :

GET _cat/indices

Gestion des index dans les tableaux de bord

L'installation des tableaux de bord sur votre domaine de OpenSearch service fournit une interface utilisateur utile pour gérer les index des différents niveaux de stockage de votre domaine. Choisissez Index Management dans le menu principal des tableaux de bord pour afficher tous les index stockés à chaud ou à froid UltraWarm, ainsi que les index gérés par les politiques de gestion de l'état des index ()ISM. Utilisez la gestion des index pour déplacer les index entre les niveaux de stockage tiède et à froid et pour surveiller les migrations entre les trois niveaux.

Notez que vous ne verrez pas les options d'indice chaud, chaud et froid à moins que vous n'ayez activé UltraWarm et/ou que le stockage à froid soit activé.

Fonctionnalités supplémentaires

L'installation par défaut des tableaux de bord sur chaque domaine OpenSearch de service comporte quelques fonctionnalités supplémentaires :