Gérer les tests de disponibilité

Un test de disponibilité est une requête envoyée à une ressource pour voir si elle répond. Vous pouvez utiliser des tests de disponibilité pour déterminer la disponibilité d'une instance de VM, d'un service App Engine, d'une URL ou d'un équilibreur de charge AWS.

Vous pouvez surveiller la disponibilité d'une ressource en créant une règle d'alerte qui crée un incident en cas d'échec du test de disponibilité. Vous pouvez configurer la règle d'alerte pour vous avertir par e-mail ou via un autre canal. Cette notification peut inclure des détails sur la ressource qui n'a pas pu répondre. Vous avez également la possibilité d'observer les résultats des tests de disponibilité dans les tableaux de bord des tests de disponibilité Monitoring.

Cette page vous explique comment :

• créer un test de disponibilité ;
• afficher le tableau de bord d'un test de disponibilité ;
• modifier un test de disponibilité ;
• supprimer un test de disponibilité.

Consultez la section Étape suivante pour obtenir des liens vers des pages de tarification et des pages décrivant la surveillance de vos tests de disponibilité.

Avant de commencer

1. Les pare-feu qui protègent votre service ont une incidence sur votre utilisation des tests de disponibilité.

   • Si la ressource que vous testez n'est pas accessible en mode public, vous devez configurer son pare-feu de façon à autoriser le trafic entrant à partir des serveurs de tests de disponibilité. Pour télécharger la liste des adresses IP, consultez la section Obtenir des adresses IP.
   • Si la ressource que vous testez n'a pas d'adresse IP externe, les tests de disponibilité ne peuvent pas l'atteindre.

2. Le test de disponibilité ne charge pas les éléments de page et n'exécute pas JavaScript. La configuration par défaut d'un test de disponibilité n'inclut pas l'authentification.

   Pour HTTP et HTTPS, si la réponse est une redirection vers une autre URL, la vérification récupère les données de cette URL. Enfin, le test de disponibilité évalue les données pour déterminer s'il a réussi ou échoué.

   Pour réussir, les conditions suivantes doivent être remplies :

   • L'état HTTP est Success.
   • Les données n'ont pas de contenus obligatoires, ou les contenus obligatoires sont présents.

Créer un test de disponibilité

Cette section explique comment créer et configurer des tests de disponibilité.

Remarque : Tous les tests de disponibilité utilisent des requêtes GET ou POST HTTP ou des requêtes TCP. Pour émettre une requête HTTP POST pour un test de disponibilité, vous devez créer le test de disponibilité à l'aide de l'API Cloud Monitoring.

Utiliser l'API

API

Appelez la méthode projects.uptimeCheckConfigs.create. Définissez les paramètres de la méthode comme suit :

• parent : obligatoire. Il doit s'agir du nom du projet dans lequel créer le test de disponibilité. Remplacez [PROJECT_ID] par l'ID de votre projet Google Cloud. Il a le format suivant :

  projects/[PROJECT_ID]
  

• Le corps de la requête doit contenir un objet UptimeCheckConfig pour le nouveau test de disponibilité. Cette page ne contient que des informations sur quelques champs. Pour obtenir une documentation complète sur cet objet et ses champs, consultez la page UptimeCheckConfig :

  • Laissez le champ name de l'object de configuration vide. Le système définit ce champ lors de la construction de l'objet de configuration de la réponse.

  • Si vous configurez une vérification HTTP ou HTTPS, vous devez renseigner le champ HttpCheck de l'objet UptimeCheckConfig. Dans cet objet, définissez le champ requestMethod sur GET ou POST. Si ce champ est omis ou défini sur METHOD_UNSPECIFIED, une requête GET est émise.

    Si vous configurez une requête POST, renseignez les champs contentType et body.

La méthode create renvoie l'objet UptimeCheckConfig pour la nouvelle configuration.

Si la configuration du test de disponibilité créé ne fonctionne pas comme prévu, consultez la section Échec du test de cette page.

C#

Afficher sur GitHub Commentaires

public static object CreateUptimeCheck(string projectId, string hostName,
    string displayName)
{
    // Define a new config.
    var config = new UptimeCheckConfig()
    {
        DisplayName = displayName,
        MonitoredResource = new MonitoredResource()
        {
            Type = "uptime_url",
            Labels = { { "host", hostName } }
        },
        HttpCheck = new UptimeCheckConfig.Types.HttpCheck()
        {
            Path = "/",
            Port = 80,
        },
        Timeout = TimeSpan.FromSeconds(10).ToDuration(),
        Period = TimeSpan.FromMinutes(5).ToDuration()
    };
    // Create a client.
    var client = UptimeCheckServiceClient.Create();
    ProjectName projectName = new ProjectName(projectId);
    // Create the config.
    var newConfig = client.CreateUptimeCheckConfig(
        projectName,
        config,
        CallSettings.FromExpiration(
            Expiration.FromTimeout(
                TimeSpan.FromMinutes(2))));
    Console.WriteLine(newConfig.Name);
    return 0;
}

Java

Afficher sur GitHub Commentaires

private static void createUptimeCheck(
    String projectId, String displayName, String hostName, String pathName) throws IOException {
  CreateUptimeCheckConfigRequest request =
      CreateUptimeCheckConfigRequest.newBuilder()
          .setParent(ProjectName.format(projectId))
          .setUptimeCheckConfig(
              UptimeCheckConfig.newBuilder()
                  .setDisplayName(displayName)
                  .setMonitoredResource(
                      MonitoredResource.newBuilder()
                          .setType("uptime_url")
                          .putLabels("host", hostName))
                  .setHttpCheck(HttpCheck.newBuilder().setPath(pathName).setPort(80))
                  .setTimeout(Duration.newBuilder().setSeconds(10))
                  .setPeriod(Duration.newBuilder().setSeconds(300)))
          .build();
  try (UptimeCheckServiceClient client = UptimeCheckServiceClient.create()) {
    UptimeCheckConfig config = client.createUptimeCheckConfig(request);
    System.out.println("Uptime check created: " + config.getDisplayName());
  } catch (Exception e) {
    usage("Exception creating uptime check: " + e.toString());
    throw e;
  }
}

Go

Afficher sur GitHub Commentaires

// createGet creates an example uptime check on a GET request.
func createGet(w io.Writer, projectID string) (*monitoringpb.UptimeCheckConfig, error) {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return nil, fmt.Errorf("NewUptimeCheckClient: %v", err)
	}
	defer client.Close()
	req := &monitoringpb.CreateUptimeCheckConfigRequest{
		Parent: "projects/" + projectID,
		UptimeCheckConfig: &monitoringpb.UptimeCheckConfig{
			DisplayName: "new GET uptime check",
			Resource: &monitoringpb.UptimeCheckConfig_MonitoredResource{
				MonitoredResource: &monitoredres.MonitoredResource{
					Type: "uptime_url",
					Labels: map[string]string{
						"host": "example.com",
					},
				},
			},
			CheckRequestType: &monitoringpb.UptimeCheckConfig_HttpCheck_{
				HttpCheck: &monitoringpb.UptimeCheckConfig_HttpCheck{
					RequestMethod: monitoringpb.UptimeCheckConfig_HttpCheck_GET,
					Path:          "/",
					Port:          80,
				},
			},
			Timeout: &duration.Duration{Seconds: 10},
			Period:  &duration.Duration{Seconds: 300},
		},
	}
	config, err := client.CreateUptimeCheckConfig(ctx, req)
	if err != nil {
		return nil, fmt.Errorf("CreateUptimeCheckConfig GET: %v", err)
	}
	fmt.Fprintf(w, "Successfully created GET uptime check %q\n", config.GetDisplayName())
	return config, nil
}

// createPost creates an example uptime check on a POST request.
func createPost(w io.Writer, projectID string) (*monitoringpb.UptimeCheckConfig, error) {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return nil, fmt.Errorf("NewUptimeCheckClient: %v", err)
	}
	defer client.Close()
	req := &monitoringpb.CreateUptimeCheckConfigRequest{
		Parent: "projects/" + projectID,
		UptimeCheckConfig: &monitoringpb.UptimeCheckConfig{
			DisplayName: "new POST uptime check",
			Resource: &monitoringpb.UptimeCheckConfig_MonitoredResource{
				MonitoredResource: &monitoredres.MonitoredResource{
					Type: "uptime_url",
					Labels: map[string]string{
						"host": "example.com",
					},
				},
			},
			CheckRequestType: &monitoringpb.UptimeCheckConfig_HttpCheck_{
				HttpCheck: &monitoringpb.UptimeCheckConfig_HttpCheck{
					RequestMethod: monitoringpb.UptimeCheckConfig_HttpCheck_POST,
					ContentType:   monitoringpb.UptimeCheckConfig_HttpCheck_URL_ENCODED,
					Path:          "/",
					Port:          80,
					Body:          []byte(base64.URLEncoding.EncodeToString([]byte("key: value"))),
				},
			},
			Timeout: &duration.Duration{Seconds: 10},
			Period:  &duration.Duration{Seconds: 300},
		},
	}
	config, err := client.CreateUptimeCheckConfig(ctx, req)
	if err != nil {
		return nil, fmt.Errorf("CreateUptimeCheckConfig POST: %v", err)
	}
	fmt.Fprintf(w, "Successfully created POST uptime check %q\n", config.GetDisplayName())
	return config, nil
}

Node.js

Afficher sur GitHub Commentaires

// Imports the Google Cloud client library
const monitoring = require('@google-cloud/monitoring');

// Creates a client
const client = new monitoring.UptimeCheckServiceClient();

/**
 * TODO(developer): Uncomment and edit the following lines of code.
 */
// const projectId = 'YOUR_PROJECT_ID';
// const hostname = 'mydomain.com';

const request = {
  // i.e. parent: 'projects/my-project-id'
  parent: client.projectPath(projectId),
  uptimeCheckConfig: {
    displayName: 'My Uptime Check',
    monitoredResource: {
      // See the Uptime Check docs for supported MonitoredResource types
      type: 'uptime_url',
      labels: {
        host: hostname,
      },
    },
    httpCheck: {
      path: '/',
      port: 80,
    },
    timeout: {
      seconds: 10,
    },
    period: {
      seconds: 300,
    },
  },
};

// Creates an uptime check config for a GCE instance
const [uptimeCheckConfig] = await client.createUptimeCheckConfig(request);
console.log('Uptime check created:');
console.log(`ID: ${uptimeCheckConfig.name}`);
console.log(`Display Name: ${uptimeCheckConfig.displayName}`);
console.log('Resource: %j', uptimeCheckConfig.monitoredResource);
console.log('Period: %j', uptimeCheckConfig.period);
console.log('Timeout: %j', uptimeCheckConfig.timeout);
console.log(`Check type: ${uptimeCheckConfig.check_request_type}`);
console.log(
  'Check: %j',
  uptimeCheckConfig.httpCheck || uptimeCheckConfig.tcpCheck
);
console.log(
  `Content matchers: ${uptimeCheckConfig.contentMatchers
    .map(matcher => matcher.content)
    .join(', ')}`
);
console.log(`Regions: ${uptimeCheckConfig.selectedRegions.join(', ')}`);

PHP

Afficher sur GitHub Commentaires

use Google\Cloud\Monitoring\V3\UptimeCheckServiceClient;
use Google\Cloud\Monitoring\V3\UptimeCheckConfig;
use Google\Api\MonitoredResource;

/**
 * Example:
 * ```
 * create_uptime_check($projectId, 'myproject.appspot.com', 'Test Uptime Check!');
 * ```
 *
 * @param string $projectId Your project ID
 * @param string $hostName
 * @param string $displayName
 */
function create_uptime_check($projectId, $hostName = 'example.com', $displayName = 'New uptime check')
{
    $uptimeCheckClient = new UptimeCheckServiceClient([
        'projectId' => $projectId,
    ]);

    $monitoredResource = new MonitoredResource();
    $monitoredResource->setType('uptime_url');
    $monitoredResource->setLabels(['host' => $hostName]);

    $uptimeCheckConfig = new UptimeCheckConfig();
    $uptimeCheckConfig->setDisplayName($displayName);
    $uptimeCheckConfig->setMonitoredResource($monitoredResource);

    $uptimeCheckConfig = $uptimeCheckClient->createUptimeCheckConfig(
        $uptimeCheckClient->projectName($projectId),
        $uptimeCheckConfig
    );

    printf('Created an uptime check: %s' . PHP_EOL, $uptimeCheckConfig->getName());
}

Python

Afficher sur GitHub Commentaires

def create_uptime_check_config_get(project_name, host_name=None, display_name=None):
    config = monitoring_v3.types.uptime_pb2.UptimeCheckConfig()
    config.display_name = display_name or "New GET uptime check"
    config.monitored_resource.type = "uptime_url"
    config.monitored_resource.labels.update({"host": host_name or "example.com"})
    config.http_check.request_method = (
        monitoring_v3.enums.UptimeCheckConfig.HttpCheck.RequestMethod.GET
    )
    config.http_check.path = "/"
    config.http_check.port = 80
    config.timeout.seconds = 10
    config.period.seconds = 300

    client = monitoring_v3.UptimeCheckServiceClient()
    new_config = client.create_uptime_check_config(project_name, config)
    pprint.pprint(new_config)
    return new_config

def create_uptime_check_config_post(project_name, host_name=None, display_name=None):
    config = monitoring_v3.types.uptime_pb2.UptimeCheckConfig()
    config.display_name = display_name or "New POST uptime check"
    config.monitored_resource.type = "uptime_url"
    config.monitored_resource.labels.update({"host": host_name or "example.com"})
    config.http_check.request_method = (
        monitoring_v3.enums.UptimeCheckConfig.HttpCheck.RequestMethod.POST
    )
    config.http_check.content_type = (
        monitoring_v3.enums.UptimeCheckConfig.HttpCheck.ContentType.URL_ENCODED
    )
    config.http_check.body = "foo=bar".encode("utf-8")
    config.http_check.path = "/"
    config.http_check.port = 80
    config.timeout.seconds = 10
    config.period.seconds = 300

    client = monitoring_v3.UptimeCheckServiceClient()
    new_config = client.create_uptime_check_config(project_name, config)
    pprint.pprint(new_config)
    return new_config

Ruby

Afficher sur GitHub Commentaires

def create_uptime_check_config project_id: nil, host_name: nil, display_name: nil
  require "google/cloud/monitoring"

  client = Google::Cloud::Monitoring.uptime_check_service
  project_name = client.project_path project: project_id
  config = {
    display_name:       display_name.nil? ? "New uptime check" : display_name,
    monitored_resource: {
      type:   "uptime_url",
      labels: { "host" => host_name.nil? ? "example.com" : host_name }
    },
    http_check:         { path: "/", port: 80 },
    timeout:            { seconds: 10 },
    period:             { seconds: 300 }
  }
  new_config = client.create_uptime_check_config \
    parent:              project_name,
    uptime_check_config: config
  puts new_config.name
  new_config
end

Il peut s'écouler jusqu'à 5 minutes avant que les résultats du test de disponibilité ne commencent à parvenir à Monitoring. Pendant ce temps, le tableau de bord du test de disponibilité indique l'état "aucune donnée disponible".

Utiliser Cloud Console

Le processus de création d'un test de disponibilité à l'aide de Cloud Console est en cours de mise à jour. Cette section explique comment créer un test de disponibilité à l'aide du nouveau flux et du flux classique. Les premières étapes des deux flux sont identiques. Vous pouvez vérifier si vous utilisez le nouveau flux ou le flux classique via le formulaire Créer un test de disponibilité.

Nouveau flux

1. Dans Cloud Console, sélectionnez Monitoring :

   Accéder à Monitoring

2. Cliquez sur Tests de disponibilité.

3. Cliquez sur Create Uptime Check (Créer un test de disponibilité).

4. Si la fenêtre Create uptime check (Créer un test de disponibilité) ressemble à la capture d'écran suivante, continuez la procédure ; sinon, cliquez sur l'onglet Flux classique de ce tableau et suivez les instructions ci-dessous :

   

5. Saisissez un titre descriptif pour le test de disponibilité, puis cliquez sur Suivant.

6. Spécifiez la cible du test de disponibilité :

   1. Sélectionnez le protocole. Vous disposez des options HTTP, HTTPS et TCP.

   2. Choisissez l'un des types de ressources suivants :

      • URL : tout nom d'hôte ou toute adresse IPv4. Le chemin d'accès et le port sont saisis séparément.
      • App Engine : applications App Engine (modules).
      • Instance : instances Compute Engine ou AWS EC2.
      • Elastic Load Balancer : équilibreur de charge AWS.

   3. Renseignez les champs spécifiques au protocole :

      • Pour les vérifications TCP, saisissez le port.

      • Pour les vérifications HTTP et HTTPS, vous avez la possibilité de saisir un chemin d'accès dans votre hôte ou votre ressource. Tous les tests de disponibilité qui utilisent ces protocoles envoient une requête à http://target/path. Dans cette expression, target est une nom d'hôte ou une adresse IP pour une ressource d'URL. Pour une ressource App Engine, target est un nom d'hôte dérivé du nom du service. Pour les ressources d'instance et d'équilibreur de charge, target est une adresse IP dérivée du nom que vous avez fourni pour la ressource ou le groupe de ressources.

        Si vous laissez le champ path vide ou si vous définissez la valeur sur /, la requête est envoyée à http://target/.

        Pour émettre un test de disponibilité sur la ressource d'URL example.com/tester, définissez le champ de nom d'hôte sur example.com et le champ du chemin d'accès sur /tester.

        Supposons que vous ayez déployé un serveur sur App Engine avec un coordinateur compatible avec / et /hello. Si vous laissez le champ de chemin vide, le test de disponibilité est envoyé au gestionnaire /. Pour émettre le test de disponibilité au gestionnaire /hello, définissez la valeur du champ de chemin sur /hello.

   4. Renseignez les champs spécifiques à la ressource :

      • Pour les ressources URL, saisissez le nom d'hôte dans le champ Nom d'hôte. Par exemple, saisissez example.com.

        Remarque : Lorsque vous créez des tests de disponibilité, tenez compte du fait que la redirection d'URL prend du temps et que le test des URL redirigées est donc plus long. Pour ce faire :

        • Lorsque cela est possible, créez des tests par rapport à des URL directes.
        • Si vous devez créer des tests par rapport à des URL de redirection, faites passer le délai avant expiration de la vérification de l'état de 10 secondes (valeur par défaut) à 30 secondes ou plus.

      • Pour les ressources App Engine, saisissez le nom du service dans le champ Service.

      • Pour les ressources Elastic Load Balancer et Instance, renseignez les champs suivants :

        • Pour émettre un test de disponibilité à une seule instance ou à un seul équilibreur de charge, dans le champ S'applique à, sélectionnez Simple, puis utilisez le menu pour sélectionner l'instance ou l'équilibreur de charge spécifique.
        • Pour émettre un test de disponibilité dans un groupe Monitoring, dans le champ Applicable à, sélectionnez Groupe, puis utilisez le menu pour sélectionner le nom du groupe.

   5. Le champ Fréquence de consultation contrôle la fréquence d'exécution du test de disponibilité. Vous pouvez conserver la valeur par défaut ou sélectionner une valeur dans le menu des options.

   6. Pour configurer des régions de vérification ou des certificats SSL, l'authentification, les en-têtes et les ports pour les vérifications HTTP et HTTPS, cliquez sur Autres options de cible :

      • Régions : sélectionnez les régions dans lesquelles les tests de disponibilité doivent recevoir des requêtes. Un test de disponibilité doit comporter au moins trois vérificateurs. Il existe un vérificateur dans toutes les régions, à l'exception des États-Unis, qui comporte trois vérificateurs. Le paramètre par défaut, Global, inclut toutes les régions.
      • Général : renseignez ce champ pour tester des hôtes virtuels. Ce champ n'est pas disponible pour les tests TCP.
      • Port : spécifiez un numéro de port.

      • En-têtes personnalisés : spécifiez des en-têtes personnalisés, puis chiffrez-les si souhaité. Le chiffrement masque les valeurs des en-têtes dans le formulaire. Utilisez le chiffrement pour les en-têtes liés à l'authentification que vous ne souhaitez pas voir visibles par les autres.

      • Authentification : indiquez un seul nom d'utilisateur et un mot de passe. Ces valeurs sont envoyées sous la forme d'un en-tête d'autorisation. Si vous définissez des valeurs dans ce champ, ne définissez pas un en-tête d'autorisation distinct. Inversement, si vous définissez un en-tête d'autorisation, ne définissez aucune valeur dans ce champ. Les mots de passe sont toujours masqués dans le formulaire. Ce champ n'est pas disponible pour les tests TCP.

      • Validation du certificat SSL : si vous avez sélectionné HTTPS pour une ressource d'URL, le service tente par défaut de se connecter via HTTPS et valide le certificat SSL. Le test de disponibilité échoue si une URL comporte un certificat non valide. Les raisons d'un certificat non valide incluent un certificat arrivé à expiration, un certificat autosigné, un certificat avec une erreur de nom de domaine et un certificat utilisant l'extension AIA.

        Pour forcer un test de disponibilité HTTPS à valider le certificat SSL, assurez-vous que l'option Valider les certificats SSL est sélectionnée.

        Pour désactiver la validation des certificats SSL, assurez-vous que l'option Valider les certificats SSL n'est pas sélectionnée.

        Si vous disposez de certificats SSL avec des extensions d'autorisation d'accès aux informations (AIA), vous devez désactiver la validation des certificats SSL. Ces types de certificats ne sont pas compatibles et échouent à la séquence de validation. Généralement, le message d'erreur est "Réponse avec erreur handshake SSL en 10 000 ms".

        Vous pouvez utiliser la métrique monitoring.googleapis.com/uptime_check/time_until_ssl_cert_expires pour créer une alerte qui vous avertit avant l'expiration de votre certificat. Pour en savoir plus, consultez la section Exemples de règles : stratégie de test de disponibilité.

        Cochez la case Valider les certificats SSL.

   7. Cliquez sur Suivant.

7. Renseignez le volet Validation de réponse.

   • Sélectionnez le délai avant expiration de la réponse dans le menu des options. Vous pouvez choisir une valeur comprise entre 1 et 60 secondes. Un test de disponibilité échoue si aucune réponse n'est reçue de plusieurs emplacements dans ce délai. Le test de disponibilité réussit si un emplacement répond.

   • Pour la correspondance de contenu, assurez-vous que le libellé d'activation est La correspondance de contenu est activée :

     • Sélectionnez le type de correspondance du contenu de la réponse dans le menu des options. Ce champ détermine comment le contenu de la réponse est comparé aux données renvoyées. Par exemple, si le contenu de la réponse est abcd et que le type de correspondance du contenu est Contient, le test de disponibilité réussit si les données de réponse contiennent abcd. Le test de disponibilité échoue si la réponse ne contient pas abcd.
     • Saisissez le contenu de la réponse. Il doit s'agir d'une chaîne qui ne dépasse pas 1 024 octets. Dans l'API, il s'agit de l'objet ContentMatcher.
     Remarque : Si vous avez sélectionné un protocole TCP, activez la correspondance du contenu de la réponse.

   • Si vous ne souhaitez pas que les tests de disponibilité soient envoyés à Cloud Logging, décochez la case Consigner les échecs de vérification.

   • Cliquez sur Suivant.

8. Renseignez le volet Alertes et notifications :

   Créez une règle d'alerte si vous souhaitez surveiller votre test de disponibilité. Si vous créez une règle d'alerte, un incident est créé lorsque votre test de disponibilité échoue et une notification est envoyée à tous les canaux de notification associés à la règle. Par exemple, si vous ajoutez une adresse e-mail à la règle, un e-mail est envoyé à cette adresse lorsqu'un incident est créé.

   Vous pouvez créer la règle d'alerte à cette étape ou ajouter la règle d'alerte après la création du test. La création d'une règle d'alerte pour le test de disponibilité est contrôlée par un bouton :

   • Si le texte du bouton est Ne pas créer d'alerte, aucune règle d'alerte n'est créée et tous les champs sont désactivés. Si vous souhaitez créer une règle d'alerte, cliquez sur le bouton.
   • Si le texte du bouton est Créer une alerte, une règle d'alerte doit être créée et tous les champs sont activés. Si vous ne souhaitez pas créer de règle d'alerte, cliquez sur le bouton.

   Pour créer une règle d'alerte dans le cadre de ce flux, procédez comme suit :

   1. Assurez-vous que le texte du bouton est Créer une alerte.
   2. Dans le champ du nom, saisissez un nom pour la règle d'alerte ou utilisez le nom par défaut.

   3. Pour ajouter un ou plusieurs canaux de notification à la règle d'alerte, dans la zone de texte intitulée Canaux de notification, cliquez sur Menu . Sélectionnez les canaux à ajouter, puis cliquez sur OK. Les canaux de notification sont classés par ordre alphabétique pour chaque type de canal.

      Si un canal de notification que vous souhaitez ajouter à la règle d'alerte n'est pas répertorié, cliquez sur Gérer les canaux de notification.

      

      La fenêtre Canaux de notification s'affiche dans un nouvel onglet du navigateur. Ajoutez les canaux de notification, puis revenez à cet onglet, cliquez sur Actualiser , puis sélectionnez les canaux de notification à ajouter à la règle d'alerte.

   4. Dans le champ de durée, sélectionnez la durée pendant laquelle les tests de disponibilité doivent échouer avant la création d'un incident. Par défaut, la règle d'alerte est configurée pour créer un incident si au moins deux régions signalent des échecs de test pendant une minute.

   Consultez la section Gérer les règles pour en savoir plus sur la désactivation, la modification et la suppression des règles d'alerte.

9. Pour vérifier la configuration du test disponibilité, cliquez sur Test (Tester). Si le résultat ne correspond pas à vos attentes, consultez la section Échec du test ci-dessous, corrigez votre configuration et effectuez à nouveau l'étape de vérification.

10. Cliquez sur Créer. Si les données requises sont manquantes, l'opération d'enregistrement échoue et la liste des champs nécessitant des données s'affiche à côté des boutons de la boîte de dialogue. Une fois les modifications enregistrées, la boîte de dialogue Uptime check created (Test de disponibilité créé) apparaît.

Flux classique

1. Dans Cloud Console, sélectionnez Monitoring :

   Accéder à Monitoring

2. Cliquez sur Tests de disponibilité.

3. Cliquez sur Create Uptime Check (Créer un test de disponibilité).

4. Si la fenêtre Create uptime check (Créer un test de disponibilité) ressemble à la capture d'écran suivante, continuez la procédure ; sinon, cliquez sur l'onglet Nouveau flux de ce tableau et suivez les instructions ci-dessous :

   

5. Dans la fenêtre New uptime check (Nouveau test de disponibilité), renseignez les champs pour le test, comme décrit dans la section Options de base.

6. (Facultatif) Cliquez sur Show advanced options (Afficher les options avancées). Pour en savoir plus sur les options avancées, consultez la section Options avancées.

7. Pour vérifier la configuration du test disponibilité, cliquez sur Test (Tester). Si le résultat ne correspond pas à vos attentes, consultez la section Échec du test ci-dessous, corrigez votre configuration et effectuez à nouveau l'étape de vérification.

8. Cliquez sur Save (Enregistrer). Si les données requises sont manquantes, l'opération d'enregistrement échoue et la liste des champs nécessitant des données s'affiche à côté des boutons de la boîte de dialogue. Une fois les modifications enregistrées, la boîte de dialogue Uptime check created (Test de disponibilité créé) apparaît.

9. (Facultatif) Si vous souhaitez être averti de l'échec du test de disponibilité, cliquez sur Créer une règle d'alerte. Si vous ne souhaitez pas créer de règle d'alerte pour l'instant, cliquez sur Non, merci. Vous pouvez créer une règle d'alerte pour un test de disponibilité à tout moment. Pour en savoir plus, consultez la section Surveiller les tests de disponibilité.

   

Il peut s'écouler jusqu'à 5 minutes avant que les résultats du test de disponibilité ne commencent à parvenir à Monitoring. Pendant ce temps, le tableau de bord du test de disponibilité indique l'état "aucune donnée disponible".

Options de base pour l'interface classique

Cette section décrit les champs que vous utilisez lorsque vous créez un test de disponibilité lorsque vous utilisez l'interface classique de Cloud Console ou l'API. Lorsque vous utilisez l'API, vous fournissez les valeurs correspondantes dans un objet UptimeCheckConfig.

1. Titre : nom permettant d'identifier votre test. Exemple : Example.com uptime check.

2. Type de test : sélectionnez le protocole HTTP, HTTPS ou TCP.

   Si vous utilisez l'API et que le type de vérification est HTTP ou HTTPS, vous pouvez configurer la vérification pour qu'elle émette une requête POST. Consultez l'exemple d'API ci-dessus.

   Si vous sélectionnez HTTPS, le service tente de se connecter via HTTPS et valide le certificat SSL. Par défaut, un certificat arrivé à expiration ou auto-signé entraîne l'échec du test de disponibilité.

   Pour désactiver la validation du certificat SSL, décochez Valider les certificats SSL.

3. Type de ressource : choisissez l'un des types de ressources suivants.

   • App Engine : applications App Engine (modules).
   • Elastic Load Balancer : équilibreur de charge AWS.
   • Instance : instances Compute Engine ou AWS EC2. Dans l'API, ce type est divisé en gce_instance et aws_ec2_instance.
   • URL : tout nom d'hôte ou toute adresse IPv4. Le chemin d'accès et le port sont saisis séparément.

4. Renseignez les champs spécifiques au protocole :

   • Pour les vérifications TCP, saisissez le port.

   • Pour les vérifications HTTP et HTTPS, vous avez la possibilité de saisir un chemin d'accès dans votre hôte ou votre ressource. Tous les tests de disponibilité qui utilisent ces protocoles envoient une requête à http://target/path. Dans cette expression, target est une nom d'hôte ou une adresse IP pour une ressource d'URL. Pour une ressource App Engine, target est un nom d'hôte dérivé du nom du service. Pour les instances et équilibreurs de charge, target est une adresse IP dérivée du nom que vous avez fourni pour la ressource ou le groupe de ressources.

     Si vous laissez le champ path vide ou si vous définissez la valeur sur /, la requête HTTP est envoyée à http://target/.

     Pour émettre un test de disponibilité sur la ressource d'URL example.com/tester, définissez le champ de nom d'hôte sur example.com et le champ du chemin d'accès sur /tester.

     Supposons que vous ayez déployé un serveur sur App Engine avec un coordinateur compatible avec / et /hello. Si vous laissez le champ de chemin vide, le test de disponibilité est envoyé au gestionnaire /. Pour émettre le test de disponibilité au gestionnaire /hello, définissez la valeur du champ de chemin sur /hello.

5. Renseignez les champs spécifiques à la ressource :

   • Si vous sélectionnez URL pour le champ Type de ressource, saisissez le nom de l'hôte. Par exemple, saisissez example.com.

   • Si vous sélectionnez le Type de ressource App Engine, sélectionnez le nom du service.

   • Si vous sélectionnez un Type de ressource Elastic Load Balancer ou Instance, vous indiquez si le test de disponibilité s'applique à une seule ressource ou à un groupe. de ressources. Pour appliquer le test de disponibilité à une instance ou à un équilibreur de charge, cliquez sur Ressource unique, puis sélectionnez l'instance ou l'équilibreur de charge spécifique. Pour appliquer le test de disponibilité à un groupe d'instances ou à un groupe d'équilibreurs de charge, cliquez sur Groupe, puis sélectionnez le nom du groupe. Si vous utilisez l'API, spécifiez la ressource surveillée avec les libellés de ressource requis, comme décrit dans la liste des ressources surveillées.

6. Fréquence du test : choisissez 1, 5, 10 ou 15 minutes. Cette valeur détermine la fréquence des tests de disponibilité. Par exemple, si vous sélectionnez "5 minutes", chaque zone géographique effectuera un test de disponibilité toutes les cinq minutes.

Remarque : Lorsque vous créez des tests de disponibilité, tenez compte du fait que la redirection d'URL prend du temps et que le test des URL redirigées est donc plus long. Pour ce faire :

• Lorsque cela est possible, créez des tests par rapport à des URL directes, et non à des URL de redirection.
• Si vous devez créer des tests par rapport à des URL de redirection, faites passer le délai avant expiration de la vérification de l'état de 10 secondes (valeur par défaut) à 30 secondes ou plus. Pour en savoir plus, consultez la section Options avancées.

Options avancées pour l'interface classique

Cliquez sur Afficher les options avancées pour afficher tous les paramètres avancés. Les paramètres avancés disponibles dépendent du type de test :

• Général : renseignez ce champ pour tester des hôtes virtuels. Ce champ n'est pas disponible pour les tests TCP.
• Port : spécifiez un numéro de port.
• Type de correspondance du contenu de la réponse : définit comment la chaîne saisie dans le contenu de la réponse est comparée aux données renvoyées. Par exemple, si le contenu de la réponse est abcd et que vous sélectionnez le type de correspondance de contenu Contient, le test disponibilité est réussi si les données de la réponse contiennent abcd. Le test de disponibilité échoue si la réponse ne contient pas abcd.

• Contenu de la réponse : saisissez une chaîne de 1 024 octets maximum. Dans l'API, il s'agit de l'objet ContentMatcher.

• Emplacements : sélectionnez les régions géographiques applicables dans lesquelles le test doit recevoir des requêtes. Le paramètre par défaut est Mondial avec six vérificateurs. Vous devez disposer d'au moins trois vérificateurs. La région États-Unis comprend trois vérificateurs. Toutes les autres régions disposent d'un vérificateur.

• En-têtes personnalisés : spécifiez des en-têtes personnalisés, puis chiffrez-les si nécessaire. Le chiffrement masque les valeurs des en-têtes dans le formulaire. Utilisez un chiffrement pour les en-têtes liés à l'authentification si vous ne souhaitez pas que les autres membres de votre équipe les voient.

• Délai avant expiration de la vérification de l'état : spécifiez un délai avant expiration compris entre 1 et 60 secondes. Un test de disponibilité échoue si les vérifications d'état de plusieurs emplacements ne reçoivent pas de réponse dans le délai spécifié. Si une seule vérification d'état ne reçoit pas de réponse, le test de disponibilité n'échoue pas.

• Authentification : indiquez un seul nom d'utilisateur et un mot de passe. Ces valeurs sont envoyées sous la forme d'un en-tête "Authorization". Si vous définissez des valeurs dans cette option, ne définissez pas un en-tête "Authorization" distinct. Inversement, si vous définissez un en-tête "Authorization", ne définissez aucune valeur ici. Les mots de passe sont toujours masqués dans le formulaire. Ce champ n'est pas disponible pour les tests TCP.

• Validation des certificats SSL : cochez la case Valider les certificats SSL. Un test de disponibilité échoue si une URL comporte un certificat non valide. Un certificat peut ne pas être valide pour diverses raisons : il a expiré, a rencontré une erreur de correspondance du nom de domaine, il s'agit d'un certificat autosigné, etc. La validation des certificats SSL n'est disponible que pour les tests HTTPS sur les ressources d'URL.

  Les certificats SSL qui utilisent l'extension d'autorisation d'accès (AIA) ne sont pas compatibles et échouent la séquence de validation. Généralement, le message d'erreur est "Réponse avec erreur handshake SSL en 10 000 ms". Si vous disposez de ce type de certificat SSL, assurez-vous que la case Valider les certificats SSL est décochée.

  Vous pouvez utiliser la métrique monitoring.googleapis.com/uptime_check/time_until_ssl_cert_expires pour créer une alerte qui vous avertit avant l'expiration de votre certificat. Consultez la page Exemples de règles : test de disponibilité.

Identifiants pour les tests de disponibilité

Lorsque votre test de disponibilité est créé, Monitoring lui attribue un identifiant appelé ID de test de disponibilité. Cet identifiant est intégré au nom de la ressource pour le nouveau test de disponibilité :

projects/[PROJECT_ID]/uptimeCheckConfigs/[UPTIME_CHECK_ID]

Vous pouvez obtenir l'ID de test de disponibilité dans la réponse d'un appel de méthode pour créer ou répertorier les tests de disponibilité. Vous pouvez également trouver l'ID de test de disponibilité dans la fenêtre Détails du test, en dessous de la section Configuration.

Vérifier le test de disponibilité

Lorsque vous créez un test de disponibilité dans Cloud Console, vous pouvez tester la configuration avant d'enregistrer.

Succès du test

Pour qu'un test de disponibilité réussisse, deux conditions doivent être remplies :

• L'état HTTP est Success.
• La réponse n'a pas de contenus obligatoires, ou la recherche des contenus obligatoires dans la réponse a abouti.

Échec du test

Voici des causes possibles de l'échec d'un test de disponibilité :

• Erreur de connexion - Refusée : si vous utilisez le type de connexion HTTP par défaut, vérifiez qu'un serveur Web est installé et qu'il répond aux requêtes HTTP. Cette erreur peut se produire sur une nouvelle instance si vous n'avez pas installé de serveur Web. Consultez la page Démarrage rapide pour Compute Engine. Si vous utilisez le type de connexion HTTPS, vous devrez peut-être effectuer des étapes de configuration supplémentaires. Pour les problèmes de pare-feu, consultez la section Obtenir des adresses IP.
• Nom ou service introuvable : le nom d'hôte est peut-être incorrect.
• 403 (interdit) : le service renvoie un code d'erreur au vérificateur de tests de disponibilité. Par exemple, la configuration par défaut du serveur Web Apache renvoie ce code sous Amazon Linux, mais elle renvoie le code 200 (succès) sous d'autres versions de Linux. Consultez le tutoriel LAMP pour Amazon Linux ou la documentation de votre serveur Web.
• 404 (introuvable) : le chemin d'accès est peut-être incorrect.
• 408 (Délai avant expiration de la requête) ou absence de réponse : le numéro de port est peut-être incorrect, le service ne fonctionne peut-être pas ou est peut-être inaccessible, ou le délai avant expiration est peut-être trop court. Vérifiez que votre pare-feu autorise le trafic provenant de serveurs de tests de disponibilité. Consultez la section Obtenir des adresses IP. Le délai avant expiration est spécifié dans la partie Vérification de l'état des options avancées.

Afficher un test de disponibilité

Pour afficher un test de disponibilité, procédez comme suit :

Console

Pour afficher l'état détaillé d'un test de disponibilité, procédez comme suit :

1. Dans Cloud Console, sélectionnez Monitoring :

   Accéder à Monitoring

2. Cliquez sur Tests de disponibilité.

3. Pour afficher la fenêtre Uptime details (Détails du test), localisez le test de disponibilité que vous souhaitez afficher, puis cliquez sur son nom.

   La capture d'écran ci-dessous montre les détails du test de disponibilité "My Uptime Check" :

   

   La fenêtre Uptime details (Détails du test) contient les informations suivantes :

   • Intervalle de temps sélectionné. Par défaut, l'intervalle est défini sur 1 hour (1 heure).
   • Nom du test de disponibilité. Dans cet exemple, le nom est My Uptime Check.

   • Pourcentage de disponibilité et latence moyenne. La valeur Percent uptime (Pourcentage de disponibilité) est un pourcentage calculé comme suit : (S/T)*100, où S représente le nombre de réponses de test ayant abouti et T le nombre total de réponses de test, pour tous les emplacements. Pour les tests de groupe, les valeurs de S et T sont additionnées pour tous les membres actuels du groupe.

     Par exemple, sur une période de 25 minutes, un test de disponibilité d'une période d'une minute dans toutes les régions reçoit 25 requêtes de chacune des six zones, pour un total de 150 requêtes. Si le tableau de bord indique une disponibilité de 83,3 %, cela signifie que 125 requêtes sur 150 ont abouti.

   • Les volets Passed checks (Tests réussis) et Uptime check latency (Latence du test de disponibilité) fournissent une représentation graphique du nombre de tests réussis et de la latence de chaque test en fonction du temps.

   • Le volet Current Status (État actuel) affiche l'état des tests les plus récents. Un cercle vert avec une coche à côté d'une région indique que la dernière exécution du test a réussi dans cette région. En revanche, un cercle rouge avec un "X" signifie qu'elle a échoué.

   • Le volet Configuration affiche la configuration du test de disponibilité. Ces données sont attribuées lors de la création du test de disponibilité. La valeur Check ID (ID du test de disponibilité) correspond à la valeur [UPTIME_CHECK_ID] dans les appels d'API.

   • Le volet Alert Policies (Règles d'alerte) fournit des informations sur les règles d'alerte associées. Dans l'exemple de tableau de bord, une règle d'alerte est configurée.

C#

Afficher sur GitHub Commentaires

public static object GetUptimeCheckConfig(string configName)
{
    var client = UptimeCheckServiceClient.Create();
    UptimeCheckConfig config = client.GetUptimeCheckConfig(configName);
    if (config == null)
    {
        Console.Error.WriteLine(
            "No configuration found with the name {0}", configName);
        return -1;
    }
    Console.WriteLine("Name: {0}", config.Name);
    Console.WriteLine("Display Name: {0}", config.DisplayName);
    Console.WriteLine("Http Path: {0}", config.HttpCheck.Path);
    return 0;
}

Java

Afficher sur GitHub Commentaires

private static void getUptimeCheckConfig(String projectId, String checkName) throws IOException {
  try (UptimeCheckServiceClient client = UptimeCheckServiceClient.create()) {
    String fullCheckName = UptimeCheckConfigName.format(projectId, checkName);
    UptimeCheckConfig config = client.getUptimeCheckConfig(fullCheckName);
    if (config != null) {
      System.out.println(config.toString());
    } else {
      System.out.println(
          "No uptime check config found with name " + checkName + " in project " + projectId);
    }
  } catch (Exception e) {
    usage("Exception getting uptime check: " + e.toString());
    throw e;
  }
}

Go

Afficher sur GitHub Commentaires

// get is an example of getting an uptime check. resourceName should be
// of the form `projects/[PROJECT_ID]/uptimeCheckConfigs/[UPTIME_CHECK_ID]`.
func get(w io.Writer, resourceName string) (*monitoringpb.UptimeCheckConfig, error) {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return nil, fmt.Errorf("NewUptimeCheckClient: %v", err)
	}
	defer client.Close()
	req := &monitoringpb.GetUptimeCheckConfigRequest{
		Name: resourceName,
	}
	config, err := client.GetUptimeCheckConfig(ctx, req)
	if err != nil {
		return nil, fmt.Errorf("GetUptimeCheckConfig: %v", err)
	}
	fmt.Fprintf(w, "Config: %v", config)
	return config, nil
}

Node.js

Afficher sur GitHub Commentaires

// Imports the Google Cloud client library
const monitoring = require('@google-cloud/monitoring');

// Creates a client
const client = new monitoring.UptimeCheckServiceClient();

/**
 * TODO(developer): Uncomment and edit the following lines of code.
 */
// const projectId = 'YOUR_PROJECT_ID';
// const uptimeCheckConfigId = 'YOUR_UPTIME_CHECK_CONFIG_ID';

const request = {
  // i.e. name: 'projects/my-project-id/uptimeCheckConfigs/My-Uptime-Check
  name: client.projectUptimeCheckConfigPath(projectId, uptimeCheckConfigId),
};

console.log(`Retrieving ${request.name}`);

// Retrieves an uptime check config
const [uptimeCheckConfig] = await client.getUptimeCheckConfig(request);
console.log(`ID: ${uptimeCheckConfig.name}`);
console.log(`Display Name: ${uptimeCheckConfig.displayName}`);
console.log('Resource: %j', uptimeCheckConfig.monitoredResource);
console.log('Period: %j', uptimeCheckConfig.period);
console.log('Timeout: %j', uptimeCheckConfig.timeout);
console.log(`Check type: ${uptimeCheckConfig.check_request_type}`);
console.log(
  'Check: %j',
  uptimeCheckConfig.httpCheck || uptimeCheckConfig.tcpCheck
);
console.log(
  `Content matchers: ${uptimeCheckConfig.contentMatchers
    .map(matcher => matcher.content)
    .join(', ')}`
);
console.log(`Regions: ${uptimeCheckConfig.selectedRegions.join(', ')}`);

PHP

Afficher sur GitHub Commentaires

use Google\Cloud\Monitoring\V3\UptimeCheckServiceClient;

/**
 * Example:
 * ```
 * get_uptime_check($projectId, $configName);
 * ```
 *
 * @param string $projectId Your project ID
 * @param string $configName
 */
function get_uptime_check($projectId, $configName)
{
    $uptimeCheckClient = new UptimeCheckServiceClient([
        'projectId' => $projectId,
    ]);

    $uptimeCheck = $uptimeCheckClient->getUptimeCheckConfig($configName);

    print('Retrieved an uptime check:' . PHP_EOL);
    print($uptimeCheck->serializeToJsonString() . PHP_EOL);
}

Python

Afficher sur GitHub Commentaires

def get_uptime_check_config(config_name):
    client = monitoring_v3.UptimeCheckServiceClient()
    config = client.get_uptime_check_config(config_name)
    pprint.pprint(config)

Ruby

Afficher sur GitHub Commentaires

def get_uptime_check_config config_name
  require "google/cloud/monitoring"

  client = Google::Cloud::Monitoring.uptime_check_service
  config = client.get_uptime_check_config name: config_name
  pp config.to_h
  config
end

Modifier un test de disponibilité

Le protocole de test de disponibilité, le type de ressource et la ressource surveillée ne peuvent pas être modifiés. Si vous souhaitez modifier ces champs, vous devez créer un test de disponibilité avec la configuration appropriée. Cependant, tous les autres champs d'un test de disponibilité peuvent être modifiés après la création du test.

Pour modifier une règle d'alerte associée à un test de disponibilité, dans le volet de navigation Monitoring, cliquez sur Alertes, sélectionnez la règle à modifier, puis cliquez sur Modifier.

Pour modifier un test de disponibilité, procédez comme suit :

Console

1. Dans Cloud Console, sélectionnez Surveillance :

   Accéder à Monitoring

2. Cliquez sur Tests de disponibilité.

3. Localisez le test de disponibilité que vous souhaitez modifier, puis effectuez l'une des opérations suivantes :

   • Cliquez sur Plus et sélectionnez Modifier.
   • Affichez les détails du test de disponibilité, puis cliquez sur Modifier.

4. Modifiez les valeurs des champs selon vos besoins. Vous ne pouvez pas modifier tous les champs. Si les valeurs d'en-têtes personnalisés d'un test sont masquées, vous ne pouvez pas les rendre visibles.

5. Pour vérifier si le test fonctionne, cliquez sur Tester. Si le test échoue, consultez la section Échec du test pour identifier les causes possibles.

6. Cliquez sur Save.

API

Appelez la méthode projects.uptimeCheckConfigs.patch. Définissez les paramètres associés à la méthode comme suit :

• uptimeCheckConfig.name : obligatoire. Ce paramètre fait partie de l'URL REST. Il s'agit du nom de ressource du test de disponibilité à modifier :

  projects/[PROJECT_ID]/uptimeCheckConfigs/[UPTIME_CHECK_ID]
  

  Vous pouvez obtenir la valeur [UPTIME_CHECK_ID] à partir de la réponse d'une méthode create ou list. L'ID ne s'affiche pas dans Cloud Console.

• updateMask : facultatif. Il s'agit d'un paramètre de requête : ?updateMask=[FIELD_LIST]. [FIELD_LIST] est une liste de champs séparés par une virgule dans l'objet UptimeCheckConfig à modifier. Exemple :

  "resource.type,httpCheck.path"
  

• Le corps de la requête doit contenir un objet UptimeCheckConfig avec les nouvelles valeurs de champ.

Si updateMask est défini, seuls les champs répertoriés dans updateMask remplacent les champs correspondants dans la configuration existante. Si un champ comporte des sous-champs et qu'il est répertorié dans le masque de champ, mais qu'aucun de ses sous-champs ne l'est, tous les sous-champs remplacent les champs correspondants.

Si updateMask n'est pas défini, la configuration figurant dans le corps de la requête remplace l'ensemble de la configuration existante.

La méthode patch renvoie l'objet UptimeCheckConfig pour la configuration modifiée.

C#

Afficher sur GitHub Commentaires

public static object UpdateUptimeCheck(string configName,
    string newHttpPath, string newDisplayName)
{
    var client = UptimeCheckServiceClient.Create();
    var config = client.GetUptimeCheckConfig(configName);
    var fieldMask = new FieldMask();
    if (newDisplayName != null)
    {
        config.DisplayName = newDisplayName;
        fieldMask.Paths.Add("display_name");
    }
    if (newHttpPath != null)
    {
        config.HttpCheck.Path = newHttpPath;
        fieldMask.Paths.Add("http_check.path");
    }
    client.UpdateUptimeCheckConfig(config);
    return 0;
}

Java

Afficher sur GitHub Commentaires

private static void updateUptimeCheck(
    String projectId, String displayName, String hostName, String pathName) throws IOException {
  String fullCheckName = UptimeCheckConfigName.format(projectId, displayName);

  UpdateUptimeCheckConfigRequest request =
      UpdateUptimeCheckConfigRequest.newBuilder()
          .setUpdateMask(FieldMask.newBuilder().addPaths("http_check.path"))
          .setUptimeCheckConfig(
              UptimeCheckConfig.newBuilder()
                  .setName(fullCheckName)
                  .setMonitoredResource(
                      MonitoredResource.newBuilder()
                          .setType("uptime_url")
                          .putLabels("host", hostName))
                  .setHttpCheck(HttpCheck.newBuilder().setPath(pathName).setPort(80))
                  .setTimeout(Duration.newBuilder().setSeconds(10))
                  .setPeriod(Duration.newBuilder().setSeconds(300)))
          .build();
  try (UptimeCheckServiceClient client = UptimeCheckServiceClient.create()) {
    UptimeCheckConfig config = client.updateUptimeCheckConfig(request);
    System.out.println("Uptime check updated: \n" + config.toString());
  } catch (Exception e) {
    usage("Exception updating uptime check: " + e.toString());
    throw e;
  }
}

Go

Afficher sur GitHub Commentaires

// update is an example of updating an uptime check. resourceName should be
// of the form `projects/[PROJECT_ID]/uptimeCheckConfigs/[UPTIME_CHECK_ID]`.
func update(w io.Writer, resourceName, displayName, httpCheckPath string) (*monitoringpb.UptimeCheckConfig, error) {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return nil, fmt.Errorf("NewUptimeCheckClient: %v", err)
	}
	defer client.Close()
	getReq := &monitoringpb.GetUptimeCheckConfigRequest{
		Name: resourceName,
	}
	config, err := client.GetUptimeCheckConfig(ctx, getReq)
	if err != nil {
		return nil, fmt.Errorf("GetUptimeCheckConfig: %v", err)
	}
	config.DisplayName = displayName
	config.GetHttpCheck().Path = httpCheckPath
	req := &monitoringpb.UpdateUptimeCheckConfigRequest{
		UpdateMask: &field_mask.FieldMask{
			Paths: []string{"display_name", "http_check.path"},
		},
		UptimeCheckConfig: config,
	}
	config, err = client.UpdateUptimeCheckConfig(ctx, req)
	if err != nil {
		return nil, fmt.Errorf("UpdateUptimeCheckConfig: %v", err)
	}
	fmt.Fprintf(w, "Successfully updated %v", resourceName)
	return config, nil
}

Node.js

Afficher sur GitHub Commentaires

// Imports the Google Cloud client library
const monitoring = require('@google-cloud/monitoring');

// Creates a client
const client = new monitoring.UptimeCheckServiceClient();

/**
 * TODO(developer): Uncomment and edit the following lines of code.
 */
// const projectId = 'YOUR_PROJECT_ID';
// const uptimeCheckConfigId = 'YOUR_UPTIME_CHECK_CONFIG_ID';
// const displayName = 'A New Display Name';
// const path = '/some/path';

const request = {
  // i.e. name: 'projects/my-project-id/uptimeCheckConfigs/My-Uptime-Check
  name: client.projectUptimeCheckConfigPath(projectId, uptimeCheckConfigId),
};

console.log(`Updating ${request.name} to ${displayName}`);

// Updates the display name and path on an uptime check config
request.uptimeCheckConfig = {
  name: request.name,
  displayName: displayName,
  httpCheck: {
    path: path,
  },
};

request.updateMask = {
  paths: ['display_name', 'http_check.path'],
};

const [response] = await client.updateUptimeCheckConfig(request);
console.log(`${response.name} config updated.`);

PHP

Afficher sur GitHub Commentaires

use Google\Cloud\Monitoring\V3\UptimeCheckServiceClient;
use Google\Protobuf\FieldMask;

/**
 * Example:
 * ```
 * update_uptime_checks($projectId);
 * ```
 */
function update_uptime_checks($projectId, $configName, $newDisplayName = null, $newHttpCheckPath = null)
{
    $uptimeCheckClient = new UptimeCheckServiceClient([
        'projectId' => $projectId,
    ]);

    $uptimeCheck = $uptimeCheckClient->getUptimeCheckConfig($displayName);
    $fieldMask = new FieldMask();
    if ($newDisplayName) {
        $fieldMask->getPaths()[] = 'display_name';
        $uptimeCheck->setDisplayName($newDisplayName);
    }
    if ($newHttpCheckPath) {
        $fieldMask->getPaths()[] = 'http_check.path';
        $uptimeCheck->getHttpCheck()->setPath($newHttpCheckPath);
    }

    $uptimeCheckClient->updateUptimeCheckConfig($uptimeCheck, $fieldMask);

    print($uptimeCheck->serializeToString() . PHP_EOL);
}

Python

Afficher sur GitHub Commentaires

def update_uptime_check_config(
    config_name, new_display_name=None, new_http_check_path=None
):
    client = monitoring_v3.UptimeCheckServiceClient()
    config = client.get_uptime_check_config(config_name)
    field_mask = monitoring_v3.types.FieldMask()
    if new_display_name:
        field_mask.paths.append("display_name")
        config.display_name = new_display_name
    if new_http_check_path:
        field_mask.paths.append("http_check.path")
        config.http_check.path = new_http_check_path
    client.update_uptime_check_config(config, field_mask)

Ruby

Afficher sur GitHub Commentaires

def update_uptime_check_config config_name:         nil,
                               new_display_name:    nil,
                               new_http_check_path: nil
  require "google/cloud/monitoring"

  client = Google::Cloud::Monitoring.uptime_check_service
  config = { name: config_name }
  field_mask = { paths: [] }
  unless new_display_name.to_s.empty?
    field_mask[:paths].push "display_name"
    config[:display_name] = new_display_name
  end
  unless new_http_check_path.to_s.empty?
    field_mask[:paths].push "http_check.path"
    config[:http_check] = { path: new_http_check_path }
  end
  client.update_uptime_check_config uptime_check_config: config,
                                    update_mask:         field_mask
end

Il peut s'écouler jusqu'à 5 minutes avant que vous ne voyiez les résultats du nouveau test de disponibilité. Pendant ce temps, les résultats de l'ancien test de disponibilité sont affichés dans les tableaux de bord et utilisés dans les règles d'alerte.

Supprimer un test de disponibilité

Si vous essayez de supprimer un test de disponibilité à l'aide de Cloud Console et qu'une règle d'alerte dépend de ce test, l'opération de suppression échoue. Réessayez la suppression après avoir supprimé le test de disponibilité de toutes les règles d'alerte qui l'utilisent.

Si vous tentez de supprimer un test de disponibilité à l'aide de l'API Cloud Monitoring, le test de disponibilité est supprimé même si des règles d'alerte dépendent de la vérification. Aucune erreur n'est générée. Aucun incident n'est créé pour la vérification manquante. Avant de supprimer un test de disponibilité, assurez-vous qu'aucune règle d'alerte ne dépend de ce test.

Pour supprimer un test de disponibilité, procédez comme suit :

Console

1. Dans Cloud Console, sélectionnez Surveillance :

   Accéder à Monitoring

2. Cliquez sur Tests de disponibilité.

3. Localisez le test de disponibilité que vous souhaitez modifier, puis effectuez l'une des opérations suivantes :

   • Cliquez sur Plus et sélectionnez Supprimer.
   • Affichez les détails du test de disponibilité, puis cliquez sur Supprimer.

API

Appelez la méthode projects.uptimeCheckConfigs.delete. Spécifiez le paramètre comme suit :

• name : obligatoire. Il s'agit du nom de ressource de la configuration de test de disponibilité à supprimer :

  projects/[PROJECT_ID]/uptimeCheckConfigs/[UPTIME_CHECK_ID]
  

  Vous pouvez obtenir la valeur [UPTIME_CHECK_ID] à partir de la réponse d'une méthode create ou list. L'ID ne s'affiche pas dans Cloud Console.

C#

Afficher sur GitHub Commentaires

public static object DeleteUptimeCheckConfig(string configName)
{
    var client = UptimeCheckServiceClient.Create();
    client.DeleteUptimeCheckConfig(configName);
    Console.WriteLine($"Deleted {configName}");
    return 0;
}

Java

Afficher sur GitHub Commentaires

private static void deleteUptimeCheckConfig(String projectId, String checkName)
    throws IOException {
  try (UptimeCheckServiceClient client = UptimeCheckServiceClient.create()) {
    client.deleteUptimeCheckConfig(UptimeCheckConfigName.format(projectId, checkName));
  } catch (Exception e) {
    usage("Exception deleting uptime check: " + e.toString());
    throw e;
  }
}

Go

Afficher sur GitHub Commentaires

// delete is an example of deleting an uptime check. resourceName should be
// of the form `projects/[PROJECT_ID]/uptimeCheckConfigs/[UPTIME_CHECK_ID]`.
func delete(w io.Writer, resourceName string) error {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return fmt.Errorf("NewUptimeCheckClient: %v", err)
	}
	defer client.Close()
	req := &monitoringpb.DeleteUptimeCheckConfigRequest{
		Name: resourceName,
	}
	if err := client.DeleteUptimeCheckConfig(ctx, req); err != nil {
		return fmt.Errorf("DeleteUptimeCheckConfig: %v", err)
	}
	fmt.Fprintf(w, "Successfully deleted %q", resourceName)
	return nil
}

Node.js

Afficher sur GitHub Commentaires

// Imports the Google Cloud client library
const monitoring = require('@google-cloud/monitoring');

// Creates a client
const client = new monitoring.UptimeCheckServiceClient();

/**
 * TODO(developer): Uncomment and edit the following lines of code.
 */
// const projectId = 'YOUR_PROJECT_ID';
// const uptimeCheckConfigId = 'YOUR_UPTIME_CHECK_CONFIG_ID';

const request = {
  // i.e. name: 'projects/my-project-id/uptimeCheckConfigs/My-Uptime-Check
  name: client.projectUptimeCheckConfigPath(projectId, uptimeCheckConfigId),
};

console.log(`Deleting ${request.name}`);

// Delete an uptime check config
await client.deleteUptimeCheckConfig(request);
console.log(`${request.name} deleted.`);

PHP

Afficher sur GitHub Commentaires

use Google\Cloud\Monitoring\V3\UptimeCheckServiceClient;

/**
 * Example:
 * ```
 * delete_uptime_check($projectId, $configName);
 * ```
 *
 * @param string $projectId Your project ID
 * @param string $configName
 */
function delete_uptime_check($projectId, $configName)
{
    $uptimeCheckClient = new UptimeCheckServiceClient([
        'projectId' => $projectId,
    ]);

    $uptimeCheckClient->deleteUptimeCheckConfig($configName);

    printf('Deleted an uptime check: ' . $configName . PHP_EOL);
}

Python

Afficher sur GitHub Commentaires

# `config_name` is the `name` field of an UptimeCheckConfig.
# See https://cloud.google.com/monitoring/api/ref_v3/rest/v3/projects.uptimeCheckConfigs#UptimeCheckConfig.
def delete_uptime_check_config(config_name):
    client = monitoring_v3.UptimeCheckServiceClient()
    client.delete_uptime_check_config(config_name)
    print("Deleted ", config_name)

Ruby

Afficher sur GitHub Commentaires

def delete_uptime_check_config config_name
  require "google/cloud/monitoring"

  client = Google::Cloud::Monitoring.uptime_check_service
  client.delete_uptime_check_config name: config_name
  puts "Deleted #{config_name}"
end

Étape suivante

• Pour connaître les tarifs et les limites applicables aux tests de disponibilité, consultez la section Tarifs et limites.
• Pour afficher la liste de tous les tests de disponibilité, consultez la page Examiner les tests de disponibilité.
• Pour obtenir la liste des adresses IP pouvant être employées pour effectuer des tests de disponibilité, consultez la section Obtenir des adresses IP.
• Pour déterminer l'état de vos tests de disponibilité à l'aide de l'API, surveillez la métrique monitoring.googleapis.com/uptime_check/check_passed. Pour en savoir plus, consultez la liste des métriques Google Cloud.