Membuat multi cek blueprint canary

Cetak biru multi pemeriksaan Amazon CloudWatch Synthetics membantu Anda membuat kenari Synthetics dengan menyediakan konfigurasi JSON sederhana. Anda dapat menghemat biaya dengan menggabungkan hingga 10 jenis HTTP/DNS/SSL/TCP pemeriksaan yang berbeda secara berurutan berbasis langkah. Setiap pemeriksaan mencakup pernyataan yang memberikan verifikasi dasar terhadap hasil pemeriksaan.

Multi cek kenari dirancang untuk kasus penggunaan sederhana yang hanya memerlukan pemeriksaan dasar tanpa browser tanpa kepala. Untuk kasus penggunaan yang lebih kompleks, tinjau jenis kenari lain yang disediakan Amazon CloudWatch Synthetics.

Prasyarat

• Harus menggunakan syn-nodejs-3.0+ untuk membuat kenari multi cek

• Saat menggunakan konfigurasi Autentikasi dan Secrets Manager, Anda harus memastikan kenari ExecutionRoleArnmemungkinkan izin untuk mengakses rahasia ini

• Saat menggunakan Otentikasi untuk Sigv4, Anda harus memastikan kenari ExecutionRoleArnmengizinkan izin untuk mengakses peran terkait

Batasan

• Ukuran Respons HTTP tidak boleh lebih besar dari 1 MB

• Maksimal 10 variabel yang ditentukan.

• Saat menggunakan JSON RFC, Checks JSON mungkin memiliki bidang duplikat yang disediakan namun hanya bidang sekuensial terakhir yang akan digunakan

• DalamKonsol Manajemen AWS, kenari multi cek akan default untuk menampilkan metrik langkah multi cek untuk dengan mudah mengidentifikasi ketersediaan setiap pemeriksaan. Saat cek dihapus, grafik ini mungkin masih menampilkan pemeriksaan dalam grafik ketersediaan hingga metrik berhenti aktif setidaknya selama 3 jam

Struktur kemasan, skema JSON, dan pengaturan konfigurasi

Konfigurasi JSON Checks yang akan digunakan untuk kenari harus diberi nama. blueprint-config.json Konfigurasi harus mengikuti skema dan mengikuti instruksi di bawahMenulis konfigurasi JSON untuk cetak biru Node.js multi Checks.

Kompres blueprint-config.json ke dalam file ZIP dan sediakan di salah satu alur kerja pembuatan berikut. Ketika ada synthetics.json konfigurasi, maka itu juga dikompresi dalam file ZIP yang sama. Berikut ini adalah contoh file zip yang disebutmulti-checks.zip.

multi-checks.zip
├── blueprint-config.json
└── synthetics.json
    

Membuat kenari multi cek di Konsol Manajemen AWS

1. Buka konsol CloudWatch sintetis Amazon.

2. Pilih Buat Canary.

3. Di bawah Gunakan cetak biru, pilih multi cek.

   Di bawah Configure Checks, Anda akan melihat dua tab, Checks dan Canary configuration.

4. Pilih versi runtime syn-nodejs-3.0 atau yang lebih baru.

5. Ikuti prosedur di bawah ini Menulis konfigurasi JSON untuk cetak biru Node.js multi Checks untuk menjelaskan pemeriksaan yang ingin Anda lakukan. Atau, konsol memberi Anda konfigurasi JSON default yang dapat Anda bangun.

6. Pilih Buat Canary.

Membuat kenari multi cek menggunakan AWS Synthetics APIs

Gunakan CreateCanary API dan di dalam Code parameter, berikan field/value BlueprintTypes="multi-checks" alih-alihHandler. Ketika Handler keduanya BlueprintTypes dan ditentukan, a ValidationException ditampilkan. Versi runtime yang disediakan harus. syn-nodejs-3.0 or later

aws synthetics create-canary \
    --name my-multi-check-canary \
    --code ZipFile="ZIP_BLOB",BlueprintTypes="multi-checks" \
    --runtime-version syn-nodejs-3.0 \
    ...

// Or if you wanted to use S3 to provide your code.

aws synthetics create-canary \
    --name my-multi-check-canary \
    --code S3Bucket="my-code-bucket",S3Key="my-zip-code-key",BlueprintTypes="multi-checks" \
    ...
    

Membuat kenari multi cek di CloudFormation

Dalam CloudFormation template Anda untuk kenari multi cek, di dalam Code parameter, berikan field/value BlueprintTypes="multi-checks" alih-alih. Handler Ketika Handler keduanya BlueprintTypes dan ditentukan, a ValidationException ditampilkan. Versi runtime yang disediakan harus. syn-nodejs-3.0 or later

Contoh template:

SyntheticsCanary:
    Type: 'AWS::Synthetics::Canary'
    Properties:
      Name: MyCanary
      RuntimeVersion: syn-nodejs-3.0
      Schedule: {Expression: 'rate(5 minutes)', DurationInSeconds: 3600}
      ...
      Code:
        S3Bucket: "my-code-bucket"
        S3Key: "my-zip-code-key"
        BlueprintTypes: ["multi-checks"]
      ...
    

Konfigurasi autentikasi

Saat kenari Anda membuat permintaan HTTP ke titik akhir yang diautentikasi, Anda dapat mengonfigurasi langkah-langkah canary cetak biru Anda untuk menggunakan salah satu dari empat jenis otentikasi: Dasar, Kunci API, Kredensyal Klien, dan SigV4. OAuth Daripada menyiapkan header permintaan sendiri, Anda dapat menentukan jenis otentikasi dalam definisi cetak biru Anda, dan Synthetics mengikuti jenis otentikasi yang ditentukan untuk mengisi komponen permintaan HTTP Anda dengan informasi otentikasi yang disediakan.

Anda menentukan jenis otentikasi dalam langkah cetak biru Anda dengan bagian Otentikasi. Anda menentukan skema otentikasi yang ingin Anda gunakan, properti yang diperlukan untuk skema otentikasi yang Anda pilih, dan Synthetics menggunakan informasi yang diberikan untuk membuat header otentikasi untuk permintaan HTTP Anda.

Karena menyimpan rahasia (seperti kata sandi atau kunci API) dalam teks biasa adalah masalah keamanan, Synthetics mendukung integrasi dengan. AWS Secrets Manager Saat Anda ingin mengautentikasi permintaan HTTP dalam canary cetak biru Synthetics, Anda dapat merujuk ke rahasia yang menyimpan informasi otentikasi Anda dan Synthetics menangani pengambilan rahasia dan menyimpannya di kenari Anda. Pendekatan ini memberikan rahasia kepada Synthetics sambil menyimpan rahasia Anda dengan aman, tanpa menentukannya dalam teks biasa dalam konfigurasi cetak biru Anda.

Untuk informasi lebih lanjut tentangAWS Secrets Manager, lihat Apa ituAWS Secrets Manager?

Autentikasi dasar

Synthetics mengimplementasikan skema otentikasi HTTP Dasar yang didefinisikan dalam RFC 7617. Prosesnya bekerja sebagai berikut:

• Pasangan nama pengguna dan kata sandi disediakan dari konfigurasi cetak biru.

• User-pass dibuat dengan menggabungkan nama pengguna, satu karakter titik dua (“:”), dan kata sandi.

• User-pass dikodekan UTF-8, kemudian diubah menjadi string yang dikodekan base64.

• User-pass yang disandikan base64 ini disediakan di header “Otorisasi” dengan format berikut: Authorization: Basic {base64-} encoded-user-pass

Misalnya, jika agen pengguna ingin mengirim id pengguna “Aladdin” dan kata sandi “buka wijen”, ia menggunakan bidang header berikut: Otorisasi: FtzQ Dasar == QWxh ZGRpbjpvc GVu IHNlc2

Contoh konfigurasi:

"Authentication": {
    "type": "BASIC",
    "username": MY_USERNAME, // Required
    "password": MY_PASSWORD // Required
}
      

Otentikasi kunci API

Anda dapat memberikan kunci API untuk mengautentikasi permintaan HTTP Anda. Saat Anda menggunakan autentikasi kunci API, kunci API yang Anda berikan dimasukkan ke dalam header HTTP “X-API-key”. Jika Anda memiliki sumber daya khusus yang mencari header kunci API di header selain yang ini, Anda dapat secara opsional menentukan nama header yang berbeda agar Synthetics memasukkan kunci API ke dalamnya.

Contoh konfigurasi:

"Authentication": {
    "type": "API_KEY",
    "apiKey": S0A1M2P3L4E5, // Required
    "header": X-Specific-Header // Optional, defaults to "X-API-Key"
}
      

Otentikasi SiGv4

AWSSigV4 (Signature Version 4) adalah protokol AWS penandatanganan untuk menambahkan informasi otentikasi ke AWS permintaan API. Untuk membuat permintaan yang diautentikasi SIGV4, Anda perlu menentukan wilayah dan layanan yang Anda minta, serta ARN (Nama AWS Sumber Daya) yang mengidentifikasi peran IAM yang ingin diasumsikan oleh kenari saat membuat permintaan SigV4 ini. Synthetics mengasumsikan peran IAM yang disediakan di RoLearn, dan menggunakannya untuk mengautentikasi permintaan API Anda. AWS

Contoh konfigurasi:

"Authentication": {
    "type": "SIGV4",
    "region": us-west-2, // Required
    "service": s3, // Required
    "roleArn": arn:AWS:iam:12345678912:role/SampleRole // Required
}
      

Pertimbangan SiGv4

Agar Synthetics dapat mengambil peran yang Anda berikan di bagian otentikasi SigV4, kebijakan kepercayaan yang dilampirkan pada peran tersebut harus dikonfigurasi agar kenari dapat mengambil RoLearn yang disediakan. Prinsip AWS utama yang perlu Anda percayai adalah peran yang diasumsikan oleh kenari Anda. AWS STS Dibutuhkan format aws:sts::{account_running_the_canary}:assumed-role/<canary_name>/<assumed_role_name> arn:.

Misalnya, jika Anda memiliki kenari yang berjalan di akun 0123456789012, bernama test-canary, dan peran yang diasumsikan diberi nama canary-assume-role, maka kebijakan kepercayaan perlu menyertakan pernyataan ini agar kenari mengasumsikan otentikasi RoLearn untuk sigV4 dengan benar:

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:AWS:sts::123456789012:assumed-role/test-canary/"
    },
    "Action": "sts:AssumeRole"
}
        

OAuth kredensi klien

Synthetics mengimplementasikan jenis hibah OAuth Client Credentials seperti yang didefinisikan dalam RFC 6479 Bagian 4.4. Jika Anda ingin membuat permintaan HTTP ke titik akhir yang diautentikasi dengan Token Pembawa yang dikeluarkan oleh titik akhir OAuth token, Synthetics dapat meminta dan mengelola token pembawa atas nama Anda. Bila Anda menggunakan OAuth skema, Synthetics melakukan langkah-langkah berikut:

• Menggunakan skema otentikasi Dasar dengan clientID dan clientSecret untuk mengautentikasi permintaan ke TokenUrl, titik akhir yang mengeluarkan token pembawa

• Jika Anda menyediakan cakupan opsional, audiens, dan parameter sumber daya, parameter tersebut disertakan dalam permintaan token

• Menggunakan token akses yang dikembalikan oleh TokenUrl untuk mengautentikasi permintaan HTTP Anda

• Menyimpan token penyegaran yang dikembalikan dari TokenUrl dengan aman untuk permintaan token masa depan

Contoh konfigurasi:

"Authentication": {
    "type": "OAUTH_CLIENT_CREDENTIALS",
    "tokenUrl": ..., // Required
    "clientId": ..., // Required
    "clientSecret": ..., // Required
    "scope": ..., // Optional
    "audience": ..., // Optional
    "resource": ..., // Optional
}
      

OAuth pertimbangan

Synthetics menyegarkan OAuth token saat respons 401 atau 407 dikembalikan.

AWS Secrets Managerintegrasi

Untuk menghindari menyimpan nilai rahasia (seperti kata sandi atau kunci API) dalam teks biasa, Synthetics menyediakan integrasi dengan. AWS Secrets Manager Anda dapat mereferensikan seluruh nilai rahasia dalam konfigurasi cetak biru Anda dengan format${aws_SECRET:<secret_name>}, atau untuk mereferensikan kunci tertentu. ${aws_SECRET:<secret_name>:<secret_key>}

Misalnya, jika Anda memiliki rahasia bernama login/basic-auth-credentials, menyimpan nama pengguna dan kata sandi dengan struktur JSON berikut:

{
    "username": "Aladdin",
    "password": "open sesame"
}
      

Anda dapat mereferensikan nama pengguna dan kata sandi dalam konfigurasi cetak biru Anda sebagai berikut, dan Synthetics menangani pengambilan nilai rahasia dan menggunakan kuncinya untuk mengautentikasi permintaan Anda:

"Authentication": {
    "type": "BASIC",
    "username": ${AWS_SECRET:login/basic-auth-credentials:username},
    "password": ${AWS_SECRET:login/basic-auth-credentials:password}
}
      

Untuk memungkinkan Synthetics mengambil rahasia yang ditentukan, peran ARN yang diasumsikan oleh kenari harus memiliki izin SecretsManager:. GetSecretValue Jika rahasia dienkripsi menggunakan kunci yang dikelola pelanggan alih-alih kunci terkelola AWS /secretsmanager, maka Anda juga perlu Dekripsi izin untuk kunci itu. AWS kms:

Contoh izin:

{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:AWS:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf"
        },
        {
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": "arn:AWS:kms:us-east-1:123456789012:key/key-id"
        }
    ]
}
      

Pemecahan masalah

Kegagalan pemecahan masalah umum

Kode yang mendasari cetak biru multi cek ditulis dalam TypeScript. Lihat halaman pemecahan masalah kenari untuk kegagalan umum: Memecahkan masalah kenari yang gagal.

JSON memeriksa kesalahan sintaks konfigurasi

Ketika ada kesalahan sintaksis yang terkait dengan konfigurasi pemeriksaan JSON kenari, itu Konsol Manajemen AWS akan memberi Anda alasan kegagalan saat Anda mencoba membuat kenari. Jika Anda membuat kenari menggunakan API atauCloudFormation, Anda akan melihat kegagalan saat kenari dijalankan untuk pertama kalinya. Disarankan untuk menggunakan alur kerja pembaruan kenari yang aman untuk kenari multi cek. Untuk informasi selengkapnya, lihat Melakukan pembaruan kenari aman.

Kegagalan jaringan atau batas waktu

Untuk kegagalan intermiten atau konsisten yang terkait dengan batas waktu, kegagalan koneksi jaringan (misalnya, ENOTFOUND, ECONNRESET) pertimbangkan untuk mengaktifkan DEBUG log sehingga proses berikut akan memberikan rincian tambahan lebih lanjut tentang mengapa Cek gagal. Untuk melakukannya, berikan Variabel Lingkungan CW_SYNTHETICS_LOG_LEVEL: “DEBUG”.

Jika masih ada kegagalan yang tidak dapat Anda debug, pertimbangkan untuk menghubungi AWS Support atau memeriksa apakah ada jenis Canary lain yang disediakan dari CloudWatch Synthetics yang lebih cocok dengan kasus penggunaan Anda.