

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Pemecahan masalah App Mesh
<a name="troubleshooting"></a>

**penting**  
Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini [Migrasi dari AWS App Mesh ke Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect). 

Bab ini membahas pemecahan masalah praktik terbaik dan masalah umum yang mungkin Anda temui saat menggunakan App Mesh. Pilih salah satu area berikut untuk meninjau praktik terbaik dan masalah umum untuk area tersebut.

**Topics**
+ [Praktik terbaik pemecahan masalah App Mesh](troubleshooting-best-practices.md)
+ [Pemecahan masalah pengaturan App Mesh](troubleshooting-setup.md)
+ [Pemecahan masalah konektivitas App Mesh](troubleshooting-connectivity.md)
+ [Pemecahan masalah penskalaan App Mesh](troubleshooting-scaling.md)
+ [Pemecahan masalah observabilitas App Mesh](troubleshooting-observability.md)
+ [Pemecahan masalah keamanan App Mesh](troubleshooting-security.md)
+ [Pemecahan masalah App Mesh Kubernetes](troubleshooting-kubernetes.md)

# Praktik terbaik pemecahan masalah App Mesh
<a name="troubleshooting-best-practices"></a>

**penting**  
Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini [Migrasi dari AWS App Mesh ke Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect). 

Kami menyarankan Anda mengikuti praktik terbaik dalam topik ini untuk memecahkan masalah saat menggunakan App Mesh.

## Aktifkan antarmuka administrasi proxy Envoy
<a name="ts-bp-enable-proxy-admin-interface"></a>

Proxy Envoy dikirimkan dengan antarmuka administrasi yang dapat Anda gunakan untuk menemukan konfigurasi dan statistik dan untuk melakukan fungsi administratif lainnya seperti pengeringan koneksi. Untuk informasi selengkapnya, lihat [Antarmuka administrasi](https://www.envoyproxy.io/docs/envoy/latest/operations/admin) dalam dokumentasi Utusan.

Jika Anda menggunakan managed[Gambar utusan](envoy.md), endpoint administrasi diaktifkan secara default pada port 9901. Contoh yang diberikan dalam [Pemecahan masalah pengaturan App Mesh](troubleshooting-setup.md) menampilkan URL endpoint administrasi contoh sebagai`http://my-app.default.svc.cluster.local:9901/`. 

**catatan**  
Titik akhir administrasi tidak boleh diekspos ke internet publik. Selain itu, kami merekomendasikan pemantauan log endpoint administrasi, yang ditetapkan oleh variabel `ENVOY_ADMIN_ACCESS_LOG_FILE` lingkungan secara `/tmp/envoy_admin_access.log` default. 

## Aktifkan integrasi Envoy DogStats D untuk pembongkaran metrik
<a name="ts-bp-enable-envoy-statsd-integration"></a>

Proxy Envoy dapat dikonfigurasi untuk membongkar statistik untuk lalu lintas OSI Layer 4 dan Layer 7 dan untuk kesehatan proses internal. Meskipun topik ini menunjukkan cara menggunakan statistik ini tanpa membongkar metrik ke sink seperti CloudWatch metrik dan Prometheus., memiliki statistik ini di lokasi terpusat untuk semua aplikasi Anda dapat membantu Anda mendiagnosis masalah dan mengonfirmasi perilaku lebih cepat. Untuk informasi selengkapnya, lihat [Menggunakan CloudWatch Metrik Amazon dan dokumentasi](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) [Prometheus](https://prometheus.io/docs/introduction/overview/). 

Anda dapat mengonfigurasi metrik DogStats D dengan mengatur parameter yang ditentukan. [DogStatsD variabel](envoy-config.md#envoy-dogstatsd-config) Untuk informasi lebih lanjut tentang DogStats D, lihat dokumentasi [DogStatsD](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent). Anda dapat menemukan demonstrasi pembongkaran metrik ke AWS CloudWatch metrik di [App Mesh dengan panduan dasar-dasar Amazon ECS.](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics) GitHub

## Aktifkan log akses
<a name="ts-bp-enable-access-logs"></a>

Sebaiknya aktifkan log akses pada Anda [Node virtual](virtual_nodes.md) dan [Gerbang virtual](virtual_gateways.md) untuk menemukan detail tentang lalu lintas transit di antara aplikasi Anda. Untuk informasi selengkapnya, lihat [Logging akses](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging) di dokumentasi Utusan. Log memberikan informasi rinci tentang perilaku lalu lintas OSI Layer 4 dan Layer 7. Saat menggunakan format default Envoy, Anda dapat menganalisis log akses dengan [Wawasan CloudWatch Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) menggunakan pernyataan parse berikut.

```
parse @message "[*] \"* * *\" * * * * * * * * * * *" as StartTime, Method, Path, Protocol, ResponseCode, ResponseFlags, BytesReceived, BytesSent, DurationMillis, UpstreamServiceTimeMillis, ForwardedFor, UserAgent, RequestId, Authority, UpstreamHost
```

## Aktifkan logging debug Envoy di lingkungan pra-produksi
<a name="ts-bp-enable-envoy-debug-logging"></a>

Sebaiknya atur level log proxy Envoy ke `debug` dalam lingkungan pra-produksi. Log debug dapat membantu Anda mengidentifikasi masalah sebelum Anda lulus konfigurasi App Mesh terkait ke lingkungan produksi Anda. 

Jika Anda menggunakan [gambar Envoy](envoy.md), Anda dapat mengatur level log ke `debug` melalui variabel `ENVOY_LOG_LEVEL` lingkungan. 

**catatan**  
Kami tidak merekomendasikan penggunaan `debug` level di lingkungan produksi. Menyetel level untuk `debug` meningkatkan pencatatan dan dapat memengaruhi kinerja dan biaya keseluruhan log yang diturunkan ke solusi seperti [CloudWatch Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). 

Saat menggunakan format default Envoy, Anda dapat menganalisis log proses dengan [Wawasan CloudWatch Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) menggunakan pernyataan parse berikut: 

```
parse @message "[*][*][*][*] [*] *" as Time, Thread, Level, Name, Source, Message
```

## Pantau Konektivitas Proxy Utusan dengan bidang kontrol App Mesh
<a name="ts-bp-monitor-envoy-proxy-connectivity-state"></a>

Sebaiknya Anda memantau metrik Envoy `control_plane.connected_state` untuk memastikan bahwa proxy Envoy berkomunikasi dengan bidang kontrol App Mesh untuk mengambil sumber daya konfigurasi dinamis. Untuk informasi selengkapnya, lihat [Server Manajemen](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server.html).

# Pemecahan masalah pengaturan App Mesh
<a name="troubleshooting-setup"></a>

**penting**  
Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini [Migrasi dari AWS App Mesh ke Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect). 

Topik ini merinci masalah umum yang mungkin Anda alami dengan penyiapan App Mesh.

## Tidak dapat menarik gambar wadah Utusan
<a name="ts-setup-cannot-pull-envoy"></a>

**Gejala**  
Anda menerima pesan galat berikut dalam tugas Amazon ECS. ECR Amazon *account ID* dan *Region* dalam pesan berikut mungkin berbeda, tergantung pada repositori Amazon ECR tempat Anda menarik gambar kontainer.

```
CannotPullContainerError: Error response from daemon: pull access denied for 840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy, repository does not exist or may require 'docker login'
```

**Resolusi**  
Kesalahan ini menunjukkan bahwa peran eksekusi tugas yang digunakan tidak memiliki izin untuk berkomunikasi ke Amazon ECR dan tidak dapat menarik gambar wadah Envoy dari repositori. Peran eksekusi tugas yang ditetapkan ke tugas Amazon ECS Anda memerlukan kebijakan IAM dengan pernyataan berikut:

```
{
  "Action": [
    "ecr:BatchCheckLayerAvailability",
    "ecr:GetDownloadUrlForLayer",
    "ecr:BatchGetImage"
  ],
  "Resource": "arn:aws:ecr:us-west-2:111122223333:repository/aws-appmesh-envoy",
  "Effect": "Allow"
},
{
  "Action": "ecr:GetAuthorizationToken",
  "Resource": "*",
  "Effect": "Allow"
}
```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat terhubung ke layanan manajemen App Mesh Envoy
<a name="ts-setup-cannot-connect-ems"></a>

**Gejala**  
Proxy Utusan Anda tidak dapat terhubung ke layanan manajemen Utusan App Mesh. Anda melihat:
+ Koneksi ditolak kesalahan
+ Batas waktu koneksi
+ Kesalahan saat menyelesaikan titik akhir layanan manajemen Utusan App Mesh
+ kesalahan gRPC

**Resolusi**  
Pastikan proxy Utusan Anda memiliki akses ke internet atau ke [titik akhir VPC](vpc-endpoints.md) pribadi dan [grup keamanan](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html) Anda mengizinkan lalu lintas keluar di port 443. Titik akhir layanan manajemen Utusan publik App Mesh mengikuti format nama domain (FQDN) yang sepenuhnya memenuhi syarat.

```
# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com

# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com
```

Anda dapat men-debug koneksi Anda ke EMS menggunakan perintah di bawah ini. Ini mengirimkan permintaan gRPC yang valid namun kosong ke Layanan Manajemen Utusan.

```
curl -v -k -H 'Content-Type: application/grpc' -X POST https://appmesh-envoy-management.Region-code.amazonaws.com:443/envoy.service.discovery.v3.AggregatedDiscoveryService/StreamAggregatedResources
```

Jika Anda menerima pesan ini kembali, koneksi Anda ke Layanan Manajemen Utusan berfungsi. Untuk men-debug kesalahan terkait gRPC, lihat kesalahan [di Utusan yang terputus dari layanan manajemen App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes) dengan teks kesalahan. 

```
grpc-status: 16
grpc-message: Missing Authentication Token
```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Utusan terputus dari layanan manajemen App Mesh Envoy dengan teks kesalahan
<a name="ts-setup-grpc-error-codes"></a>

**Gejala**  
Proxy Envoy Anda tidak dapat terhubung ke layanan manajemen App Mesh Envoy dan menerima konfigurasinya. Log proxy Envoy Anda berisi entri log seperti berikut ini.

```
gRPC config stream closed: gRPC status code, message
```

**Resolusi**  
Dalam kebanyakan kasus, bagian pesan dari log harus menunjukkan masalah. Tabel berikut mencantumkan kode status gRPC paling umum yang mungkin Anda lihat, penyebabnya, dan resolusinya.


| kode status gRPC | Penyebab | Resolusi | 
| --- | --- | --- | 
| 0 | Pemutusan hubungan yang anggun dari layanan manajemen Utusan. | Tidak ada masalah. App Mesh terkadang memutus proxy Envoy dengan kode status ini. Utusan akan terhubung kembali dan terus menerima pembaruan. | 
| 3 | Endpoint mesh (virtual node atau virtual gateway), atau salah satu sumber daya yang terkait, tidak dapat ditemukan. | Periksa kembali konfigurasi Envoy Anda untuk memastikan bahwa ia memiliki nama yang sesuai dari sumber daya App Mesh yang diwakilinya. Jika resource App Mesh Anda terintegrasi dengan AWS resource lain, seperti AWS Cloud Map ruang nama atau sertifikat ACM, pastikan sumber daya tersebut ada. | 
| 7 | Proxy utusan tidak berwenang untuk melakukan tindakan, seperti terhubung ke layanan manajemen utusan, atau mengambil sumber daya terkait. | Pastikan Anda [membuat kebijakan IAM yang memiliki pernyataan kebijakan](proxy-authorization.md#create-iam-policy) yang sesuai untuk App Mesh dan layanan lainnya dan lampirkan kebijakan tersebut ke pengguna IAM atau peran yang digunakan proxy Utusan Anda untuk terhubung ke layanan manajemen Utusan.  | 
| 8 | Jumlah proxy Utusan untuk resource App Mesh tertentu melebihi kuota layanan tingkat akun. | Lihat [Kuota layanan App Mesh](service-quotas.md) informasi tentang kuota akun default dan cara meminta kenaikan kuota. | 
| 16 | Proxy Envoy tidak memiliki kredensyal otentikasi yang valid untuk. AWS | Pastikan bahwa Utusan memiliki kredensyal yang sesuai untuk terhubung ke AWS layanan melalui pengguna atau peran IAM. Masalah yang diketahui, [\$124136](https://github.com/envoyproxy/envoy/issues/24136), di Utusan untuk versi v1.24 dan sebelumnya gagal mengambil kredensyal jika proses Envoy menggunakan lebih dari deskriptor file. 1024 Ini terjadi ketika Utusan melayani volume lalu lintas tinggi. Anda dapat mengonfirmasi masalah ini dengan memeriksa log Utusan di tingkat debug untuk teks "”. A libcurl function was given a bad argument Untuk mengurangi masalah ini, tingkatkan ke versi Envoy atau yang lebih baru. v1.25.1.0-prod | 

Anda dapat mengamati kode status dan pesan dari proxy Utusan Anda dengan [Amazon CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) menggunakan kueri berikut:

```
filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message
```

Jika pesan kesalahan yang diberikan tidak membantu, atau masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here).

## Pemeriksaan kesehatan wadah utusan, pemeriksaan kesiapan, atau penyelidikan keaktifan gagal
<a name="ts-setup-envoy-container-checks"></a>

**Gejala**  
Proxy Envoy Anda gagal dalam pemeriksaan kesehatan dalam tugas Amazon ECS, instans Amazon EC2, atau pod Kubernetes. Misalnya, Anda menanyakan antarmuka administrasi Utusan dengan perintah berikut dan menerima status selain. `LIVE`

```
curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'
```

**Resolusi**  
Berikut ini adalah daftar langkah-langkah remediasi tergantung pada status yang dikembalikan oleh proxy Utusan.
+ `PRE_INITIALIZING`atau `INITIALIZING` — Proxy Envoy belum menerima konfigurasi, atau tidak dapat menghubungkan dan mengambil konfigurasi dari layanan manajemen App Mesh Envoy. Utusan mungkin menerima kesalahan dari layanan manajemen utusan ketika mencoba untuk terhubung. Untuk informasi lebih lanjut, lihat kesalahan di[Utusan terputus dari layanan manajemen App Mesh Envoy dengan teks kesalahan](#ts-setup-grpc-error-codes).
+ `DRAINING`— Proxy utusan telah mulai menguras koneksi sebagai tanggapan `/drain_listeners` atas permintaan `/healthcheck/fail` atau pada antarmuka administrasi Utusan. Kami tidak menyarankan untuk menjalankan jalur ini pada antarmuka administrasi kecuali Anda akan menghentikan tugas Amazon ECS, instans Amazon EC2, atau pod Kubernetes.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Pemeriksaan kesehatan dari penyeimbang beban ke titik akhir mesh gagal
<a name="ts-setup-lb-mesh-endpoint-health-check"></a>

**Gejala**  
Titik akhir mesh Anda dianggap sehat oleh pemeriksaan kesehatan kontainer atau probe kesiapan, tetapi pemeriksaan kesehatan dari penyeimbang beban ke titik akhir mesh gagal.

**Resolusi**  
Untuk mengatasi masalah ini, selesaikan tugas-tugas berikut.
+ Pastikan bahwa [grup keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) yang terkait dengan titik akhir mesh Anda menerima lalu lintas masuk pada port yang telah Anda konfigurasi untuk pemeriksaan kesehatan Anda.
+ Pastikan bahwa pemeriksaan kesehatan berhasil secara konsisten ketika diminta secara manual; misalnya, dari [host benteng dalam VPC](https://aws.amazon.com/quickstart/architecture/linux-bastion/) Anda.
+ Jika Anda mengonfigurasi pemeriksaan kesehatan untuk node virtual, maka kami sarankan untuk menerapkan titik akhir pemeriksaan kesehatan di aplikasi Anda; misalnya, /ping untuk HTTP. Ini memastikan bahwa proxy Envoy dan aplikasi Anda dapat dirutekan dari penyeimbang beban.
+ Anda dapat menggunakan jenis penyeimbang beban elastis apa pun untuk simpul virtual, tergantung pada fitur yang Anda butuhkan. Untuk informasi selengkapnya, lihat fitur [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/features/#compare).
+ Jika Anda mengonfigurasi pemeriksaan kesehatan untuk [gateway virtual](virtual_gateways.md), maka sebaiknya gunakan [penyeimbang beban jaringan](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) dengan pemeriksaan kesehatan TCP atau TLS pada port pendengar gateway virtual. Ini memastikan bahwa pendengar gateway virtual di-bootstrap dan siap menerima koneksi.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Gateway virtual tidak menerima lalu lintas di port 1024 atau kurang
<a name="virtual-gateway-low-ports"></a>

**Gejala**  
Gateway virtual Anda tidak menerima lalu lintas di port 1024 atau kurang, tetapi menerima lalu lintas pada nomor port yang lebih besar dari 1024. Misalnya, Anda menanyakan statistik Utusan dengan perintah berikut dan menerima nilai selain nol.

```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"
```

Anda mungkin melihat teks yang mirip dengan teks berikut di log Anda yang menjelaskan kegagalan untuk mengikat ke port istimewa:

```
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) lds_ingress_0.0.0.0_port_<port num>: cannot bind '0.0.0.0:<port num>': Permission denied
```

**Resolusi**  
Untuk mengatasi masalah ini, pengguna yang ditentukan untuk gateway harus memiliki kemampuan linux`CAP_NET_BIND_SERVICE`. Untuk informasi selengkapnya, lihat [Capabilities](https://www.man7.org/linux/man-pages/man7/capabilities.7.html) in the Linux Programmer's Manual, [parameter Linux dalam parameter](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_linuxparameters) definisi Tugas ECS, dan [Menetapkan kapabilitas untuk sebuah container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) dalam dokumentasi Kubernetes.

**penting**  
Fargate harus menggunakan nilai port yang lebih besar dari 1024.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

# Pemecahan masalah konektivitas App Mesh
<a name="troubleshooting-connectivity"></a>

**penting**  
Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini [Migrasi dari AWS App Mesh ke Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect). 

Topik ini merinci masalah umum yang mungkin Anda alami dengan konektivitas App Mesh.

## Tidak dapat menyelesaikan nama DNS untuk layanan virtual
<a name="ts-connectivity-dns-resolution-virtual-service"></a>

**Gejala**  
Aplikasi Anda tidak dapat menyelesaikan nama DNS dari layanan virtual yang sedang dicoba untuk terhubung.

**Resolusi**  
Ini adalah masalah yang diketahui. Untuk informasi selengkapnya, lihat [Nama VirtualServices berdasarkan nama host atau masalah GitHub FQDN apa pun](https://github.com/aws/aws-app-mesh-roadmap/issues/65). Layanan virtual di App Mesh dapat diberi nama apa saja. Selama ada `A` catatan DNS untuk nama layanan virtual dan aplikasi dapat menyelesaikan nama layanan virtual, permintaan akan diproksi oleh Utusan dan diarahkan ke tujuan yang sesuai. Untuk mengatasi masalah ini, tambahkan `A` catatan DNS ke alamat IP non-loopback, seperti`10.10.10.10`, untuk nama layanan virtual. `A`Catatan DNS dapat ditambahkan dalam kondisi berikut:
+ Di Amazon Route 53, jika nama diakhiran dengan nama zona host pribadi Anda
+ Di dalam `/etc/hosts` file wadah aplikasi
+ Di server DNS pihak ketiga yang Anda kelola

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat terhubung ke backend layanan virtual
<a name="ts-connectivity-virtual-service-backend"></a>

**Gejala**  
Aplikasi Anda tidak dapat membuat koneksi ke layanan virtual yang didefinisikan sebagai backend pada node virtual Anda. Saat mencoba membuat koneksi, koneksi mungkin gagal sepenuhnya, atau permintaan dari perspektif aplikasi mungkin gagal dengan kode `HTTP 503` respons.

**Resolusi**  
Jika aplikasi gagal terhubung sama sekali (tidak ada kode `HTTP 503` respons yang dikembalikan), maka lakukan hal berikut:
+ Pastikan bahwa lingkungan komputasi Anda telah diatur agar berfungsi dengan App Mesh.
  + Untuk Amazon ECS, pastikan Anda mengaktifkan [konfigurasi proxy](proxy-authorization.md) yang sesuai. Untuk end-to-end penelusuran, lihat [Memulai dengan App Mesh dan Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/appmesh-getting-started.html).
  + Untuk Kubernetes, termasuk Amazon EKS, pastikan Anda memiliki pengontrol App Mesh terbaru yang diinstal melalui Helm. Untuk informasi selengkapnya, lihat [App Mesh Controller](https://hub.helm.sh/charts/aws/appmesh-controller) di Helm Hub atau [Tutorial: Konfigurasi integrasi App Mesh dengan Kubernetes](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html).
  + Untuk Amazon EC2, pastikan Anda telah menyiapkan instans Amazon EC2 untuk memproksi lalu lintas App Mesh. Untuk informasi selengkapnya, lihat [Memperbarui layanan](https://docs.aws.amazon.com/app-mesh/latest/userguide/appmesh-getting-started.html#update-services).
+ Pastikan bahwa container Envoy yang berjalan pada layanan komputasi Anda telah berhasil terhubung ke layanan manajemen App Mesh Envoy. Anda dapat mengonfirmasi ini dengan memeriksa statistik Utusan untuk bidang tersebut. `control_plane.connected_state` Untuk informasi selengkapnya`control_plane.connected_state`, lihat [Memantau Konektivitas Proksi Utusan](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state) di Praktik Terbaik **Pemecahan Masalah** kami.

  Jika Utusan dapat membuat koneksi pada awalnya, tetapi kemudian terputus dan tidak pernah terhubung kembali, lihat Utusan [terputus dari layanan manajemen App Mesh Envoy dengan teks kesalahan untuk memecahkan masalah mengapa itu terputus](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes).

Jika aplikasi terhubung tetapi permintaan gagal dengan kode `HTTP 503` respons, coba yang berikut ini:
+ Pastikan bahwa layanan virtual yang Anda sambungkan ada di mesh.
+ Pastikan bahwa layanan virtual memiliki penyedia (router virtual atau node virtual).
+ Saat menggunakan Envoy sebagai Proxy HTTP, jika Anda melihat lalu lintas keluar masuk `cluster.cds_egress_*_mesh-allow-all` alih-alih tujuan yang benar melalui statistik Envoy, kemungkinan besar Envoy tidak merutekan permintaan dengan benar. `filter_chains` Ini bisa disebabkan oleh penggunaan nama layanan virtual yang tidak memenuhi syarat. Kami menyarankan Anda menggunakan nama penemuan layanan dari layanan yang sebenarnya sebagai nama layanan virtual, karena proxy Envoy berkomunikasi dengan layanan virtual lainnya melalui nama mereka.

  Untuk informasi selengkapnya, lihat [layanan virtual](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html).
+ Periksa log proxy Envoy untuk salah satu pesan galat berikut:
  + `No healthy upstream`— Node virtual yang coba dirutekan oleh proxy Envoy tidak memiliki titik akhir yang diselesaikan, atau tidak memiliki titik akhir yang sehat. Pastikan bahwa node virtual target memiliki penemuan layanan dan pengaturan pemeriksaan kesehatan yang benar.

    Jika permintaan ke layanan gagal selama penerapan atau penskalaan layanan virtual backend, ikuti panduan di. [Beberapa permintaan gagal dengan kode status HTTP `503` ketika layanan virtual memiliki penyedia node virtual](#ts-connectivity-virtual-node-provider)
  + `No cluster match for URL`Ini kemungkinan besar disebabkan ketika permintaan dikirim ke layanan virtual yang tidak sesuai dengan kriteria yang ditentukan oleh salah satu rute yang ditentukan di bawah penyedia router virtual. Pastikan bahwa permintaan dari aplikasi dikirim ke rute yang didukung dengan memastikan jalur dan header permintaan HTTP sudah benar.
  + `No matching filter chain found`— Ini kemungkinan besar disebabkan ketika permintaan dikirim ke layanan virtual pada port yang tidak valid. Pastikan bahwa permintaan dari aplikasi menggunakan port yang sama yang ditentukan pada router virtual.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat terhubung ke layanan eksternal
<a name="ts-connectivity-external-service"></a>

**Gejala**  
Aplikasi Anda tidak dapat terhubung ke layanan di luar mesh, seperti`amazon.com`.

**Resolusi**  
Secara default, App Mesh tidak mengizinkan lalu lintas keluar dari aplikasi di dalam mesh ke tujuan mana pun di luar mesh. Untuk mengaktifkan komunikasi dengan layanan eksternal, ada dua opsi:
+ Atur [filter keluar](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) pada sumber daya mesh ke`ALLOW_ALL`. Pengaturan ini akan memungkinkan aplikasi apa pun di dalam mesh untuk berkomunikasi dengan alamat IP tujuan apa pun di dalam atau di luar mesh.
+ Model layanan eksternal di mesh menggunakan layanan virtual, router virtual, rute, dan node virtual. Misalnya, untuk memodelkan layanan eksternal`example.com`, Anda dapat membuat layanan virtual bernama `example.com` dengan router virtual dan rute yang mengirimkan semua lalu lintas ke node virtual dengan nama host penemuan layanan DNS dari. `example.com`

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat terhubung ke server MySQL atau SMTP
<a name="ts-connectivity-troubleshooting-mysql-and-smtp"></a>

**Gejala**  
Saat mengizinkan lalu lintas keluar ke semua tujuan (Mesh `EgressFilter type` =`ALLOW_ALL`), seperti server SMTP atau database MySQL menggunakan definisi node virtual, koneksi dari aplikasi Anda gagal. Sebagai contoh, berikut ini adalah pesan kesalahan dari mencoba untuk terhubung ke server MySQL.

```
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
```

**Resolusi**  
Ini adalah masalah yang diketahui yang diselesaikan dengan menggunakan gambar App Mesh versi 1.15.0 atau yang lebih baru. Untuk informasi selengkapnya, lihat masalah [Tidak dapat terhubung ke MySQL dengan App Mesh](https://github.com/aws/aws-app-mesh-roadmap/issues/62). GitHub Kesalahan ini terjadi karena listener keluar di Envoy yang dikonfigurasi oleh App Mesh menambahkan filter listener Envoy TLS Inspector. Untuk informasi selengkapnya, lihat [TLS Inspector](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector#config-listener-filters-tls-inspector) di dokumentasi Envoy. Filter ini mengevaluasi apakah koneksi menggunakan TLS atau tidak dengan memeriksa paket pertama yang dikirim dari klien. Dengan MySQL dan SMTP, bagaimanapun, server mengirimkan paket pertama setelah koneksi. Untuk informasi selengkapnya tentang MySQL, [lihat Jabat Tangan Awal](https://dev.mysql.com/doc/internals/en/initial-handshake.html) dalam dokumentasi MySQL. Karena server mengirimkan paket pertama, inspeksi pada filter gagal.

**Untuk mengatasi masalah ini tergantung pada versi Utusan Anda:**
+ Jika versi Envoy image App Mesh Anda adalah 1.15.0 atau yang lebih baru, jangan memodelkan layanan eksternal seperti MySQL, **SMTP**, ****MSSQL****, dll. sebagai backend untuk node virtual aplikasi Anda.
+ **Jika versi Envoy image App Mesh Anda sebelum 1.15.0, tambahkan port `3306` ke daftar nilai untuk layanan Anda untuk **MySQL** dan sebagai port yang Anda gunakan untuk STMP. `APPMESH_EGRESS_IGNORED_PORTS`**

**penting**  
Sementara port SMTP standar adalah`25`,, dan `587``465`, Anda hanya harus menambahkan port yang Anda gunakan `APPMESH_EGRESS_IGNORED_PORTS` dan tidak ketiganya.

Untuk informasi selengkapnya, lihat [Update services](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services) for Kubernetes, [Update services for](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html#update-services) Amazon ECS, atau [Update services for Amazon](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services) EC2. 

Jika masalah Anda masih belum teratasi, Anda dapat memberi kami detail tentang apa yang Anda alami menggunakan [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/62) yang ada atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat terhubung ke layanan yang dimodelkan sebagai node virtual TCP atau router virtual di App Mesh
<a name="ts-connectivity-virtual-node-router"></a>

**Gejala**  
Aplikasi Anda tidak dapat terhubung ke backend yang menggunakan pengaturan protokol TCP dalam definisi App Mesh. [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html)

**Resolusi**  
Ini adalah masalah yang diketahui. Untuk informasi selengkapnya, lihat [Perutean ke beberapa tujuan TCP pada port yang sama](https://github.com/aws/aws-app-mesh-roadmap/issues/195). GitHub App Mesh saat ini tidak mengizinkan beberapa tujuan backend yang dimodelkan sebagai TCP untuk berbagi port yang sama karena pembatasan informasi yang diberikan ke proxy Utusan di Lapisan OSI 4. Untuk memastikan bahwa lalu lintas TCP dapat dirutekan dengan tepat untuk semua tujuan backend, lakukan hal berikut: 
+ Pastikan bahwa semua tujuan menggunakan port yang unik. Jika Anda menggunakan penyedia router virtual untuk layanan virtual backend, Anda dapat mengubah port router virtual tanpa mengubah port pada node virtual yang dituju. Ini memungkinkan aplikasi untuk membuka koneksi pada port router virtual sementara proxy Envoy terus menggunakan port yang ditentukan dalam node virtual.
+ Jika tujuan yang dimodelkan sebagai TCP adalah server MySQL, atau protokol berbasis TCP lainnya di mana server mengirim paket pertama setelah koneksi, lihat. [Tidak dapat terhubung ke server MySQL atau SMTP](#ts-connectivity-troubleshooting-mysql-and-smtp)

Jika masalah Anda masih belum teratasi, Anda dapat memberi kami detail tentang apa yang Anda alami menggunakan [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/195) yang ada atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Konektivitas berhasil ke layanan yang tidak terdaftar sebagai backend layanan virtual untuk node virtual
<a name="ts-connectivity-not-virtual-service"></a>

**Gejala**  
Aplikasi Anda dapat menghubungkan dan mengirim lalu lintas ke tujuan yang tidak ditentukan sebagai backend layanan virtual pada node virtual Anda.

**Resolusi**  
Jika permintaan berhasil ke tujuan yang belum dimodelkan di App Mesh APIs, maka penyebab yang paling mungkin adalah bahwa jenis [filter keluar](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) mesh telah disetel ke. `ALLOW_ALL` Ketika filter keluar diatur ke`ALLOW_ALL`, permintaan keluar dari aplikasi Anda yang tidak cocok dengan tujuan model (backend) akan dikirim ke alamat IP tujuan yang ditetapkan oleh aplikasi. 

Jika Anda ingin melarang lalu lintas ke tujuan yang tidak dimodelkan di mesh, pertimbangkan untuk mengatur nilai filter keluar ke. `DROP_ALL`

**catatan**  
Mengatur nilai filter keluar mesh mempengaruhi semua node virtual di dalam mesh.  
Mengkonfigurasi `egress_filter` sebagai `DROP_ALL` dan mengaktifkan TLS tidak tersedia untuk lalu lintas keluar yang tidak ke domain. AWS 

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Beberapa permintaan gagal dengan kode status HTTP `503` ketika layanan virtual memiliki penyedia node virtual
<a name="ts-connectivity-virtual-node-provider"></a>

**Gejala**  
Sebagian dari permintaan aplikasi Anda gagal ke backend layanan virtual yang menggunakan penyedia node virtual, bukan penyedia router virtual. Saat menggunakan penyedia router virtual untuk layanan virtual, permintaan tidak gagal.

**Resolusi**  
Ini adalah masalah yang diketahui. Untuk informasi selengkapnya, lihat [Kebijakan coba lagi tentang penyedia Node Virtual untuk Layanan Virtual](https://github.com/aws/aws-app-mesh-roadmap/issues/194) di GitHub. Saat menggunakan node virtual sebagai penyedia layanan virtual, Anda tidak dapat menentukan kebijakan coba ulang default yang Anda inginkan untuk digunakan oleh klien layanan virtual Anda. Sebagai perbandingan, penyedia router virtual memungkinkan kebijakan coba ulang ditentukan karena mereka adalah properti dari sumber daya rute anak.

Untuk mengurangi kegagalan permintaan ke penyedia node virtual, gunakan penyedia router virtual sebagai gantinya, dan tentukan kebijakan coba lagi pada rutenya. Untuk cara lain untuk mengurangi kegagalan permintaan pada aplikasi Anda, lihat[Praktik terbaik App Mesh](best-practices.md). 

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat terhubung ke sistem file Amazon EFS
<a name="ts-connectivity-efs"></a>

**Gejala**  
Saat mengonfigurasi tugas Amazon ECS dengan sistem file Amazon EFS sebagai volume, tugas gagal dimulai dengan kesalahan berikut.

```
ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: mount.nfs4: Connection refused : unsuccessful EFS utils command execution; code: 32
```

**Resolusi**  
Ini adalah masalah yang diketahui. Kesalahan ini terjadi karena koneksi NFS ke Amazon EFS terjadi sebelum kontainer apa pun dalam tugas Anda dimulai. Lalu lintas ini dirutekan oleh konfigurasi proxy ke Envoy, yang tidak akan berjalan pada saat ini. Karena pemesanan startup, klien NFS gagal terhubung ke sistem file Amazon EFS dan tugas gagal diluncurkan. Untuk mengatasi masalah ini, tambahkan port `2049` ke daftar nilai untuk `EgressIgnoredPorts` pengaturan dalam konfigurasi proxy definisi tugas Amazon ECS Anda. Untuk informasi selengkapnya, lihat [Konfigurasi proxy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#proxyConfiguration).

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Konektivitas berhasil dilayani, tetapi permintaan yang masuk tidak muncul di log akses, jejak, atau metrik untuk Utusan
<a name="ts-connectivity-iptables"></a>

**Gejala**  
 Meskipun aplikasi Anda dapat menghubungkan dan mengirim permintaan ke aplikasi lain, Anda tidak dapat melihat permintaan masuk di log akses atau dalam melacak informasi untuk proxy Utusan.

**Resolusi**  
Ini adalah masalah yang diketahui. Dari informasi selengkapnya, lihat masalah [penyiapan aturan iptables](https://github.com/aws/aws-app-mesh-roadmap/issues/166) di Github. Proxy Envoy hanya mencegat lalu lintas masuk ke port tempat node virtual yang sesuai mendengarkan. Permintaan ke port lain akan melewati proxy Envoy dan mencapai layanan di belakangnya secara langsung. Untuk membiarkan proxy Envoy mencegat lalu lintas masuk untuk layanan Anda, Anda perlu mengatur node virtual dan layanan Anda untuk mendengarkan pada port yang sama.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Menyetel variabel`HTTP_PROXY`/`HTTPS_PROXY`environment pada level container tidak berfungsi seperti yang diharapkan.
<a name="http-https-proxy"></a>

**Gejala**  
Ketika HTTP\$1PROXY/HTTPS\$1PROXY disetel sebagai variabel lingkungan di:
+ Penampung aplikasi dalam definisi tugas dengan App Mesh diaktifkan, permintaan yang dikirim ke namespace layanan App Mesh akan mendapatkan respons `HTTP 500` kesalahan dari sespan Envoy.
+ Wadah utusan dalam definisi tugas dengan App Mesh diaktifkan, permintaan yang keluar dari sespan Envoy tidak akan melalui server `HTTPS` proxy`HTTP`/, dan variabel lingkungan tidak akan berfungsi.

**Resolusi**  
Untuk wadah aplikasi:

App Mesh berfungsi dengan memiliki lalu lintas dalam tugas Anda melalui proxy Envoy. `HTTP_PROXY`/`HTTPS_PROXY`konfigurasi mengesampingkan perilaku ini dengan mengonfigurasi lalu lintas kontainer untuk melewati proxy eksternal yang berbeda. Lalu lintas masih akan dicegat oleh Utusan, tetapi tidak mendukung proxy lalu lintas mesh menggunakan proxy eksternal.

Jika Anda ingin mem-proxy semua lalu lintas non-mesh, setel `NO_PROXY` untuk menyertakan CIDR/Namespace mesh Anda, localhost, dan titik akhir kredenal seperti pada contoh berikut.

```
NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16
```

Untuk wadah Utusan:

Utusan tidak mendukung proxy generik. Kami tidak menyarankan pengaturan variabel-variabel ini.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Batas waktu permintaan hulu bahkan setelah mengatur batas waktu untuk rute.
<a name="upstream-timeout-request"></a>

**Gejala**  
Anda menentukan batas waktu untuk:
+ Rute, tetapi Anda masih mendapatkan kesalahan batas waktu permintaan hulu.
+ Pendengar simpul virtual dan batas waktu serta batas waktu coba lagi untuk rute, tetapi Anda masih mendapatkan kesalahan batas waktu permintaan hulu.

**Resolusi**  
Agar permintaan latensi tinggi lebih dari 15 detik berhasil diselesaikan, Anda perlu menentukan batas waktu di tingkat pendengar rute dan node virtual.

Jika Anda menentukan batas waktu rute yang lebih besar dari default 15 detik, pastikan batas waktu juga ditentukan untuk pendengar untuk semua node virtual yang berpartisipasi. Namun, jika Anda mengurangi batas waktu ke nilai yang lebih rendah dari default, itu opsional untuk memperbarui batas waktu di node virtual. Untuk informasi selengkapnya tentang opsi saat menyiapkan node dan rute [virtual, lihat node](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html) dan [rute](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html) virtual.

**Jika Anda menetapkan **kebijakan coba lagi**, durasi yang Anda tentukan untuk batas waktu permintaan harus selalu lebih besar dari atau sama dengan batas *waktu coba lagi dikalikan dengan percobaan ulang* *maksimal yang Anda tentukan dalam kebijakan coba lagi*.** Ini memungkinkan permintaan Anda dengan semua percobaan ulang berhasil diselesaikan. Untuk informasi selengkapnya, lihat [rute](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Utusan merespons dengan permintaan HTTP Bad.
<a name="ts-http-bad-request"></a>

**Gejala**  
Utusan merespons dengan **HTTP 400 Bad request untuk semua permintaan** yang dikirim melalui Network Load Balancer (NLB). Saat kami memeriksa log Utusan, kami melihat:
+ Log debug:

  ```
  dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD
  ```
+ Akses log:

  ```
  "- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
  ```

**Resolusi**  
Resolusinya adalah menonaktifkan protokol proxy versi 2 (PPv2) pada atribut [grup target](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes) NLB Anda.

Sampai hari ini tidak PPv2 didukung oleh gateway virtual dan utusan node virtual yang dijalankan menggunakan bidang kontrol App Mesh. Jika Anda menerapkan NLB menggunakan pengontrol penyeimbang AWS beban di Kubernetes, maka nonaktifkan PPv2 dengan menyetel atribut berikut ke: `false`

```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```

Lihat [Anotasi Pengontrol AWS Load Balancer untuk detail selengkapnya](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue) tentang atribut sumber daya NLB.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat mengonfigurasi batas waktu dengan benar.
<a name="ts-configure-timeout"></a>

**Gejala**  
Batas waktu permintaan Anda dalam waktu 15 detik bahkan setelah mengonfigurasi batas waktu pada pendengar node virtual dan batas waktu pada rute menuju backend node virtual.

**Resolusi**  
 Pastikan bahwa layanan virtual yang benar termasuk dalam daftar backend.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

# Pemecahan masalah penskalaan App Mesh
<a name="troubleshooting-scaling"></a>

**penting**  
Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini [Migrasi dari AWS App Mesh ke Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect). 

Topik ini merinci masalah umum yang mungkin Anda alami dengan penskalaan App Mesh.

## Konektivitas gagal dan pemeriksaan kesehatan kontainer gagal saat menskalakan melebihi 50 replika untuk gateway virtual node/virtual
<a name="ts-scaling-exceed-virtual-node-envoy-quota"></a>

**Gejala**  
Saat Anda menskalakan jumlah replika, seperti tugas Amazon ECS, pod Kubernetes, atau instans Amazon EC2, untuk node/virtual gateway virtual di atas 50, pemeriksaan kesehatan container Envoy untuk Utusan baru dan yang sedang berjalan mulai gagal. Aplikasi hilir yang mengirimkan lalu lintas ke node/virtual gateway virtual mulai melihat kegagalan permintaan dengan kode `503` status HTTP.

**Resolusi**  
Kuota default App Mesh untuk jumlah Utusan per node/virtual gateway virtual adalah 50. Ketika jumlah Utusan yang berjalan melebihi kuota ini, Utusan baru dan yang sedang berjalan gagal terhubung ke layanan manajemen Utusan App Mesh dengan kode status gRPC (). `8` `RESOURCE_EXHAUSTED` Kuota ini bisa dinaikkan. Untuk informasi selengkapnya, lihat [Kuota layanan App Mesh](service-quotas.md).

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Permintaan gagal `503` ketika backend layanan virtual secara horizontal keluar atau masuk
<a name="ts-scaling-out-in"></a>

**Gejala**  
Ketika layanan virtual backend secara horizontal diskalakan atau masuk, permintaan dari aplikasi hilir gagal dengan kode status. `HTTP 503`

**Resolusi**  
App Mesh merekomendasikan beberapa pendekatan untuk mengurangi kasus kegagalan saat menskalakan aplikasi secara horizontal. Untuk informasi terperinci tentang cara mencegah kegagalan ini, lihat[Praktik terbaik App Mesh](best-practices.md).

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Kontainer utusan mogok dengan segfault di bawah peningkatan beban
<a name="ts-scaling-segfault"></a>

**Gejala**  
Di bawah beban lalu lintas yang tinggi, proxy Envoy macet karena kesalahan segmentasi (kode keluar Linux). `139` Log proses Envoy berisi pernyataan seperti berikut ini.

```
Caught Segmentation fault, suspect faulting address 0x0"
```

**Resolusi**  
Proxy Envoy kemungkinan telah melanggar standar nofile ulimit sistem operasi, batas jumlah file yang dapat dibuka suatu proses pada suatu waktu. Pelanggaran ini disebabkan oleh lalu lintas yang menyebabkan lebih banyak koneksi, yang mengkonsumsi soket sistem operasi tambahan. Untuk mengatasi masalah ini, tingkatkan nilai nofile ulimit pada sistem operasi host. Jika Anda menggunakan Amazon ECS, batas ini dapat diubah melalui pengaturan [Ulimit pada pengaturan batas](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) [sumber daya](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits) definisi tugas.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Peningkatan sumber daya default tidak tercermin dalam Batas Layanan
<a name="default-resources-increase"></a>

**Gejala**  
Setelah meningkatkan batas default resource App Mesh, nilai baru tidak tercermin saat Anda melihat batas layanan Anda.

**Resolusi**  
Meskipun batas baru saat ini tidak ditampilkan, pelanggan masih dapat menggunakannya.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Aplikasi macet karena sejumlah besar panggilan pemeriksaan kesehatan.
<a name="crash-health-checks"></a>

**Gejala**  
Setelah mengaktifkan pemeriksaan kesehatan aktif untuk node virtual, ada peningkatan jumlah panggilan pemeriksaan kesehatan. Aplikasi mogok karena volume panggilan pemeriksaan kesehatan yang sangat meningkat yang dilakukan ke aplikasi.

**Resolusi**  
Ketika pemeriksaan kesehatan aktif diaktifkan, setiap titik akhir Utusan dari hilir (klien) mengirimkan permintaan kesehatan ke setiap titik akhir cluster hulu (server) untuk membuat keputusan perutean. Akibatnya jumlah total permintaan pemeriksaan kesehatan akan `number of client Envoys` menjadi\$1 `number of server Envoys` \$1`active health check frequency`.

Untuk mengatasi masalah ini, modifikasi frekuensi pemeriksaan kesehatan, yang akan mengurangi volume total pemeriksaan kesehatan. Selain pemeriksaan kesehatan aktif, App Mesh memungkinkan konfigurasi [deteksi outlier](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html) sebagai sarana pemeriksaan kesehatan pasif. Gunakan deteksi outlier untuk mengonfigurasi kapan harus menghapus host tertentu berdasarkan respons yang berurutan`5xx`.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

# Pemecahan masalah observabilitas App Mesh
<a name="troubleshooting-observability"></a>

**penting**  
Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini [Migrasi dari AWS App Mesh ke Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect). 

Topik ini merinci masalah umum yang mungkin Anda alami dengan observabilitas App Mesh.

## Tidak dapat melihat AWS X-Ray jejak untuk aplikasi saya
<a name="ts-observability-x-ray-traces"></a>

**Gejala**  
Aplikasi Anda di App Mesh tidak menampilkan informasi penelusuran X-Ray di konsol X-Ray atau. APIs

**Resolusi**  
Untuk menggunakan X-Ray di App Mesh, Anda harus mengonfigurasi komponen dengan benar untuk mengaktifkan komunikasi antara aplikasi, wadah sespan, dan layanan X-Ray. Ambil langkah-langkah berikut untuk mengonfirmasi bahwa X-Ray telah diatur dengan benar:
+ Pastikan protokol pendengar Node Virtual App Mesh tidak disetel sebagai`TCP`.
+ Pastikan bahwa wadah X-Ray yang digunakan dengan aplikasi Anda mengekspos port UDP `2000` dan berjalan sebagai pengguna. `1337` Untuk informasi selengkapnya, lihat [contoh X-Ray Amazon ECS](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-ecs-basics/deploy/2-meshify.yaml#L374-L386) di GitHub.
+ Pastikan bahwa wadah Envoy telah mengaktifkan tracing. Jika Anda menggunakan [image App Mesh Envoy](envoy.md), Anda dapat mengaktifkan X-Ray dengan menyetel variabel `ENABLE_ENVOY_XRAY_TRACING` lingkungan ke nilai `1` dan variabel `XRAY_DAEMON_PORT` lingkungan. `2000`
+ Jika Anda telah menginstrumentasi X-Ray dalam kode aplikasi Anda dengan salah satu [bahasa tertentu SDKs ](https://docs.aws.amazon.com/xray/index.html), maka pastikan bahwa itu dikonfigurasi dengan benar dengan mengikuti panduan untuk bahasa Anda.
+ Jika semua item sebelumnya dikonfigurasi dengan benar, tinjau log kontainer X-Ray untuk kesalahan dan ikuti panduan dalam [Pemecahan Masalah AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-troubleshooting.html). Penjelasan lebih rinci tentang integrasi X-Ray di App Mesh dapat ditemukan di [Mengintegrasikan X-Ray dengan App Mesh](https://aws.amazon.com/blogs/compute/integrating-aws-x-ray-with-aws-app-mesh/).

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat melihat metrik Utusan untuk aplikasi saya di metrik Amazon CloudWatch
<a name="ts-observability-envoy-metrics"></a>

**Gejala**  
Aplikasi Anda di App Mesh tidak memancarkan metrik yang dihasilkan oleh proxy Envoy ke metrik. CloudWatch

**Resolusi**  
Saat Anda menggunakan CloudWatch metrik di App Mesh, Anda harus mengonfigurasi beberapa komponen dengan benar untuk mengaktifkan komunikasi antara proxy Envoy, sespan CloudWatch agen, dan layanan metrik. CloudWatch Ambil langkah-langkah berikut untuk mengonfirmasi bahwa CloudWatch metrik untuk proxy Envoy telah diatur dengan benar:
+ Pastikan Anda menggunakan image CloudWatch agen untuk App Mesh. Untuk informasi selengkapnya, lihat [ CloudWatchagen App Mesh](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent) di GitHub.
+ Pastikan Anda telah mengonfigurasi CloudWatch agen untuk App Mesh dengan tepat dengan mengikuti petunjuk penggunaan khusus platform. Untuk informasi selengkapnya, lihat [ CloudWatchagen App Mesh](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent#usage) di GitHub.
+ Jika semua item sebelumnya dikonfigurasi dengan benar, tinjau log kontainer CloudWatch agen untuk kesalahan dan ikuti panduan yang diberikan dalam [Pemecahan Masalah](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html) agen. CloudWatch 

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat mengonfigurasi aturan pengambilan sampel khusus untuk jejak AWS X-Ray
<a name="ts-observability-custom-sampling"></a>

**Gejala**  
Aplikasi Anda menggunakan penelusuran X-Ray, tetapi Anda tidak dapat mengonfigurasi aturan pengambilan sampel untuk jejak Anda.

**Resolusi**  
Karena App Mesh Envoy saat ini tidak mendukung **konfigurasi pengambilan sampel X-Ray Dinamis**, solusi berikut tersedia.

Jika versi Utusan Anda `1.19.1` atau lebih baru, Anda memiliki opsi berikut.
+ Untuk hanya mengatur laju pengambilan sampel, gunakan variabel `XRAY_SAMPLING_RATE` lingkungan pada wadah Envoy. Nilai harus ditentukan sebagai desimal antara `0` dan `1.00` (100%). Untuk informasi selengkapnya, lihat [AWS X-Ray variabel](envoy-config.md#envoy-xray-config).
+ Untuk mengonfigurasi aturan pengambilan sampel kustom yang dilokalkan untuk pelacak X-Ray, gunakan variabel `XRAY_SAMPLING_RULE_MANIFEST` lingkungan untuk menentukan jalur file dalam sistem file kontainer Envoy. Untuk informasi selengkapnya, lihat [Aturan pengambilan sampel](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling) di *Panduan AWS X-Ray Pengembang*.

Jika versi Utusan Anda sebelumnya`1.19.1`, lakukan hal berikut.
+ Gunakan variabel `ENVOY_TRACING_CFG_FILE` lingkungan untuk mengubah laju pengambilan sampel Anda. Untuk informasi selengkapnya, lihat [Variabel konfigurasi utusan](envoy-config.md). Tentukan konfigurasi penelusuran khusus dan tentukan aturan pengambilan sampel lokal. Untuk informasi selengkapnya, lihat konfigurasi [X-Ray Utusan](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/trace/v3/xray.proto.html#config-trace-v3-xrayconfig).
+ Konfigurasi penelusuran khusus untuk contoh variabel `ENVOY_TRACING_CFG_FILE` lingkungan:

  ```
  tracing:
     http:
       name: envoy.tracers.xray
       typedConfig:
         "@type": type.googleapis.com/envoy.config.trace.v3.XRayConfig
         segmentName: foo/bar
         segmentFields:
           origin: AWS::AppMesh::Proxy
           aws:
             app_mesh:
               mesh_name: foo
               virtual_node_name: bar
         daemonEndpoint:
               protocol: UDP
               address: 127.0.0.1
               portValue: 2000
         samplingRuleManifest:
               filename: /tmp/sampling-rules.json
  ```
+ Untuk detail tentang konfigurasi manifes aturan pengambilan sampel di `samplingRuleManifest` properti, lihat [Mengonfigurasi X-Ray SDK](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling) for Go.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

# Pemecahan masalah keamanan App Mesh
<a name="troubleshooting-security"></a>

**penting**  
Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini [Migrasi dari AWS App Mesh ke Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect). 

Topik ini merinci masalah umum yang mungkin Anda alami dengan keamanan App Mesh.

## Tidak dapat terhubung ke layanan virtual backend dengan kebijakan klien TLS
<a name="ts-security-tls-client-policy"></a>

**Gejala**  
Saat menambahkan kebijakan klien TLS ke backend layanan virtual di node virtual, konektivitas ke backend tersebut gagal. Saat mencoba mengirim lalu lintas ke layanan backend, permintaan gagal dengan kode `HTTP 503` respons dan pesan kesalahan:. `upstream connect error or disconnect/reset before headers. reset reason: connection failure`

**Resolusi**  
Untuk menentukan akar penyebab masalah, sebaiknya gunakan log proses proxy Envoy untuk membantu Anda mendiagnosis masalah. Untuk informasi selengkapnya, lihat [Aktifkan logging debug Envoy di lingkungan pra-produksi](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging). Gunakan daftar berikut untuk menentukan penyebab kegagalan koneksi:
+ Pastikan konektivitas ke backend berhasil dengan mengesampingkan kesalahan yang disebutkan di. [Tidak dapat terhubung ke backend layanan virtual](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend)
+ Di log proses Envoy, cari kesalahan berikut (dicatat pada tingkat debug).

  ```
  TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
  ```

  Kesalahan ini disebabkan oleh satu atau lebih alasan berikut:
  + Sertifikat tidak ditandatangani oleh salah satu otoritas sertifikat yang ditentukan dalam paket kepercayaan kebijakan klien TLS.
  + Sertifikat tidak lagi valid (kedaluwarsa).
  + Nama Alternatif Subjek (SAN) tidak cocok dengan nama host DNS yang diminta.
  + Pastikan bahwa sertifikat yang ditawarkan oleh layanan backend valid, yang ditandatangani oleh salah satu otoritas sertifikat dalam paket kepercayaan kebijakan klien TLS Anda, dan memenuhi kriteria yang ditentukan. [Keamanan Lapisan Pengangkutan (TLS)](tls.md)
  + Jika kesalahan yang Anda terima seperti yang di bawah ini, maka itu berarti permintaan tersebut melewati proxy Utusan dan mencapai aplikasi secara langsung. Saat mengirim lalu lintas, statistik di Envoy tidak berubah yang menunjukkan bahwa Utusan tidak berada di jalur untuk mendekripsi lalu lintas. Dalam konfigurasi proxy node virtual, pastikan `AppPorts` berisi nilai yang benar yang didengarkan aplikasi.

    ```
    upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
    ```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue-bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/). Jika Anda yakin telah menemukan kerentanan keamanan atau memiliki pertanyaan tentang keamanan App Mesh, lihat pedoman [pelaporan AWS kerentanan](https://aws.amazon.com/security/vulnerability-reporting/).

## Tidak dapat terhubung ke layanan virtual backend saat aplikasi berasal dari TLS
<a name="ts-security-originating-tls"></a>

**Gejala**  
Saat memulai sesi TLS dari aplikasi, bukan dari proxy Envoy, konektivitas ke layanan virtual backend gagal.

**Resolusi**  
Ini adalah masalah yang diketahui. Untuk informasi selengkapnya, lihat [Permintaan Fitur: negosiasi TLS antara aplikasi hilir dan masalah proksi hulu](https://github.com/aws/aws-app-mesh-roadmap/issues/162). GitHub Di App Mesh, originasi TLS saat ini didukung dari proxy Envoy tetapi tidak dari aplikasi. Untuk menggunakan dukungan originasi TLS di Utusan, nonaktifkan originasi TLS dalam aplikasi. Hal ini memungkinkan Utusan untuk membaca header permintaan keluar dan meneruskan permintaan ke tujuan yang sesuai melalui sesi TLS. Untuk informasi selengkapnya, lihat [Keamanan Lapisan Pengangkutan (TLS)](tls.md). 

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/). Jika Anda yakin telah menemukan kerentanan keamanan atau memiliki pertanyaan tentang keamanan App Mesh, lihat pedoman [pelaporan AWS kerentanan](https://aws.amazon.com/security/vulnerability-reporting/).

## Tidak dapat menegaskan bahwa konektivitas antara proxy Utusan menggunakan TLS
<a name="ts-security-tls-between-proxies"></a>

**Gejala**  
Aplikasi Anda telah mengaktifkan penghentian TLS pada node virtual atau pendengar gateway virtual, atau originasi TLS pada kebijakan klien TLS backend, tetapi Anda tidak dapat menegaskan bahwa konektivitas antara proxy Envoy terjadi selama sesi yang dinegosiasikan TLS.

**Resolusi**  
Langkah-langkah yang ditentukan dalam resolusi ini menggunakan antarmuka administrasi Utusan dan statistik Utusan. Untuk bantuan mengonfigurasi ini, lihat [Aktifkan antarmuka administrasi proxy Envoy](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface) dan[Aktifkan integrasi Envoy DogStats D untuk pembongkaran metrik](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration). Contoh statistik berikut menggunakan antarmuka administrasi untuk kesederhanaan.
+ Untuk proxy Utusan yang melakukan penghentian TLS:
  + Pastikan bahwa sertifikat TLS telah di-bootstrap dalam konfigurasi Envoy dengan perintah berikut.

    ```
    curl http://my-app.default.svc.cluster.local:9901/certs
    ```

    Dalam output yang dikembalikan, Anda harus melihat setidaknya satu entri di bawah `certificates[].cert_chain` untuk sertifikat yang digunakan dalam penghentian TLS.
  + Pastikan bahwa jumlah koneksi masuk yang berhasil ke pendengar proxy sama persis dengan jumlah jabat tangan SSL ditambah jumlah sesi SSL yang digunakan kembali, seperti yang ditunjukkan oleh contoh perintah dan output berikut.

    ```
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep downstream_cx_total
    listener.0.0.0.0_15000.downstream_cx_total: 11
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.connection_error
    listener.0.0.0.0_15000.ssl.connection_error: 1
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.handshake
    listener.0.0.0.0_15000.ssl.handshake: 9
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.session_reused
    listener.0.0.0.0_15000.ssl.session_reused: 1
    # Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
    ```
+ Untuk proxy Envoy yang melakukan originasi TLS:
  + Pastikan bahwa toko kepercayaan TLS telah di-bootstrap dalam konfigurasi Envoy dengan perintah berikut.

    ```
    curl http://my-app.default.svc.cluster.local:9901/certs
    ```

    Anda harus melihat setidaknya satu entri di bawah `certificates[].ca_certs` untuk sertifikat yang digunakan dalam memvalidasi sertifikat backend selama originasi TLS.
  + Pastikan bahwa jumlah koneksi keluar yang berhasil ke cluster backend persis sama dengan jumlah jabat tangan SSL ditambah jumlah sesi SSL yang digunakan kembali, seperti yang ditunjukkan oleh contoh perintah dan output berikut.

    ```
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep upstream_cx_total
    cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.upstream_cx_total: 11
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.connection_error
    cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.connection_error: 1
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.handshake
    cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.handshake: 9
    curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.session_reused
    cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.session_reused: 1
    # Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
    ```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/). Jika Anda yakin telah menemukan kerentanan keamanan atau memiliki pertanyaan tentang keamanan App Mesh, lihat pedoman [pelaporan AWS kerentanan](https://aws.amazon.com/security/vulnerability-reporting/).

## Memecahkan Masalah TLS dengan Elastic Load Balancing
<a name="ts-security-tls-elb"></a>

**Gejala**  
Saat mencoba mengonfigurasi Application Load Balancer atau Network Load Balancer untuk mengenkripsi lalu lintas ke node virtual, pemeriksaan kesehatan konektivitas dan penyeimbang beban dapat gagal.

**Resolusi**  
Untuk menentukan akar penyebab masalah, Anda perlu memeriksa yang berikut ini:
+ Untuk proxy Envoy yang melakukan penghentian TLS, Anda harus mengesampingkan kesalahan konfigurasi apa pun. Ikuti langkah-langkah yang diberikan di atas di[Tidak dapat terhubung ke layanan virtual backend dengan kebijakan klien TLS](#ts-security-tls-client-policy).
+ Untuk penyeimbang beban, Anda perlu melihat konfigurasi `TargetGroup:`
  + Pastikan `TargetGroup` port cocok dengan port pendengar yang ditentukan node virtual.
  + Untuk Application Load Balancers yang berasal dari koneksi TLS melalui HTTP ke layanan Anda, pastikan bahwa `TargetGroup` protokol diatur ke. `HTTPS` Jika pemeriksaan kesehatan sedang digunakan, pastikan itu `HealthCheckProtocol` diatur ke`HTTPS`. 
  + Untuk Network Load Balancer yang berasal dari koneksi TLS melalui TCP ke layanan Anda, pastikan bahwa protokol diatur ke`TargetGroup`. `TLS` Jika pemeriksaan kesehatan sedang digunakan, pastikan itu `HealthCheckProtocol` diatur ke`TCP`.
**catatan**  
Setiap pembaruan yang `TargetGroup` memerlukan perubahan `TargetGroup` nama.

Dengan konfigurasi ini dengan benar, penyeimbang beban Anda harus menyediakan koneksi aman ke layanan Anda menggunakan sertifikat yang diberikan kepada proxy Envoy.

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/). Jika Anda yakin telah menemukan kerentanan keamanan atau memiliki pertanyaan tentang keamanan App Mesh, lihat pedoman [pelaporan AWS kerentanan](https://aws.amazon.com/security/vulnerability-reporting/).

# Pemecahan masalah App Mesh Kubernetes
<a name="troubleshooting-kubernetes"></a>

**penting**  
Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini [Migrasi dari AWS App Mesh ke Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect). 

Topik ini merinci masalah umum yang mungkin Anda alami saat menggunakan App Mesh dengan Kubernetes.

## Sumber daya App Mesh yang dibuat di Kubernetes tidak dapat ditemukan di App Mesh
<a name="ts-kubernetes-missing-resources"></a>

**Gejala**  
Anda telah membuat resource App Mesh menggunakan definisi sumber daya kustom Kubernetes (CRD), tetapi resource yang Anda buat tidak terlihat di App Mesh saat Anda menggunakan or. Konsol Manajemen AWS APIs

**Resolusi**  
Kemungkinan penyebabnya adalah kesalahan pada pengontrol Kubernetes untuk App Mesh. Untuk informasi selengkapnya, lihat [Pemecahan Masalah](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md) di. GitHub Periksa log pengontrol untuk setiap kesalahan atau peringatan yang menunjukkan bahwa pengontrol tidak dapat membuat sumber daya apa pun. 

```
kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller)
```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Pod gagal memeriksa kesiapan dan keaktifan setelah envoy sidecar disuntikkan
<a name="ts-kubernetes-pods-after-injection"></a>

**Gejala**  
Pod untuk aplikasi Anda sebelumnya berhasil berjalan, tetapi setelah sespan Envoy disuntikkan ke dalam pod, pemeriksaan kesiapan dan keaktifan mulai gagal.

**Resolusi**  
Pastikan bahwa wadah Envoy yang disuntikkan ke dalam pod telah di-bootstrap dengan layanan manajemen Envoy App Mesh. Anda dapat memverifikasi kesalahan apa pun dengan mereferensikan kode kesalahan di[Utusan terputus dari layanan manajemen App Mesh Envoy dengan teks kesalahan](troubleshooting-setup.md#ts-setup-grpc-error-codes). Anda dapat menggunakan perintah berikut untuk memeriksa log Envoy untuk pod yang relevan.

```
kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller) \
    | grep "gRPC config stream closed"
```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Pod tidak mendaftar atau membatalkan pendaftaran sebagai instance AWS Cloud Map
<a name="ts-kubernetes-pods-cmap"></a>

**Gejala**  
Pod Kubernetes Anda tidak terdaftar atau tidak terdaftar AWS Cloud Map sebagai bagian dari siklus hidupnya. Sebuah pod dapat memulai dengan sukses dan siap untuk melayani lalu lintas, tetapi tidak menerima apa pun. Ketika sebuah pod dihentikan, klien mungkin masih mempertahankan alamat IP-nya dan mencoba mengirim lalu lintas ke sana, gagal.

**Resolusi**  
Ini adalah masalah yang diketahui. Untuk informasi selengkapnya, lihat [Pod don't get auto registered/deregistered di Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159) dengan masalah. AWS Cloud Map GitHub Karena hubungan antara pod, node virtual App Mesh, dan AWS Cloud Map sumber daya, [pengontrol App Mesh untuk Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s) dapat menjadi tidak sinkron dan kehilangan sumber daya. Misalnya, hal ini dapat terjadi jika sumber daya node virtual dihapus dari Kubernetes sebelum menghentikan pod yang terkait. 

Untuk mengurangi masalah ini:
+ Pastikan Anda menjalankan versi terbaru dari pengontrol App Mesh untuk Kubernetes.
+ Pastikan bahwa AWS Cloud Map `namespaceName` dan `serviceName` benar dalam definisi node virtual Anda.
+ Pastikan Anda menghapus semua Pod terkait sebelum menghapus definisi node virtual Anda. Jika Anda memerlukan bantuan untuk mengidentifikasi pod mana yang terkait dengan node virtual, lihat[Tidak dapat menentukan lokasi pod untuk resource App Mesh berjalan](#ts-kubernetes-where-pod-running).
+ Jika masalah Anda berlanjut, jalankan perintah berikut untuk memeriksa log pengontrol Anda untuk kesalahan yang dapat membantu mengungkapkan masalah mendasar.

  ```
  kubectl logs -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
  ```
+ Pertimbangkan untuk menggunakan perintah berikut untuk me-restart pod pengontrol Anda. Ini dapat memperbaiki masalah sinkronisasi.

  ```
  kubectl delete -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
  ```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat menentukan lokasi pod untuk resource App Mesh berjalan
<a name="ts-kubernetes-where-pod-running"></a>

**Gejala**  
Ketika Anda menjalankan App Mesh di klaster Kubernetes, operator tidak dapat menentukan di mana beban kerja, atau pod, berjalan untuk resource App Mesh tertentu.

**Resolusi**  
Sumber daya pod Kubernetes dianotasi dengan mesh dan node virtual yang terkait dengannya. Anda dapat menanyakan pod mana yang sedang berjalan untuk nama node virtual tertentu dengan perintah berikut.

```
kubectl get pods --all-namespaces -o json | \
    jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'
```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Tidak dapat menentukan sumber daya App Mesh apa yang dijalankan pod
<a name="ts-kubernetes-pod-running-as"></a>

**Gejala**  
Saat menjalankan App Mesh di klaster Kubernetes, operator tidak dapat menentukan resource App Mesh apa yang dijalankan pod tertentu.

**Resolusi**  
Sumber daya pod Kubernetes dianotasi dengan mesh dan node virtual yang terkait dengannya. Anda dapat menampilkan nama mesh dan node virtual dengan menanyakan pod secara langsung menggunakan perintah berikut.

```
kubectl get pod pod-name -n namespace -o json | \
    jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'
```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## Utusan Klien tidak dapat berkomunikasi dengan Layanan Manajemen Utusan App Mesh dengan dinonaktifkan IMDSv1
<a name="ts-kubernetes-imdsv1-disabled"></a>

**Gejala**  
Saat `IMDSv1` dinonaktifkan, Utusan klien tidak dapat berkomunikasi dengan bidang kontrol App Mesh (Layanan Manajemen Utusan). `IMDSv2`dukungan tidak tersedia pada versi App Mesh Envoy sebelumnya. `v1.24.0.0-prod`

**Resolusi**  
Untuk mengatasi masalah ini, Anda dapat melakukan salah satu dari tiga hal ini.
+ Tingkatkan ke versi App Mesh Envoy `v1.24.0.0-prod` atau yang lebih baru, yang memiliki `IMDSv2` dukungan.
+ Aktifkan kembali `IMDSv1` pada Instance tempat Utusan berjalan. Untuk petunjuk tentang memulihkan`IMDSv1`, lihat [Mengkonfigurasi opsi metadata instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html).
+ Jika layanan Anda berjalan di Amazon EKS, disarankan untuk menggunakan peran IAM untuk akun layanan (IRSA) untuk mengambil kredensyal. Untuk petunjuk mengaktifkan IRSA, lihat [peran IAM untuk akun layanan](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).

## IRSA tidak berfungsi pada wadah aplikasi saat App Mesh diaktifkan dan Utusan disuntikkan
<a name="ts-kubernetes-irsa-not-working"></a>

**Gejala**  
Saat App Mesh diaktifkan pada kluster Amazon EKS dengan bantuan pengontrol App Mesh untuk Amazon EKS, Utusan dan `proxyinit` kontainer akan disuntikkan ke dalam pod aplikasi. Aplikasi tidak dapat mengasumsikan `IRSA` dan sebagai gantinya mengasumsikan. `node role` Ketika kita menjelaskan rincian pod, kita kemudian melihat bahwa variabel `AWS_WEB_IDENTITY_TOKEN_FILE` atau `AWS_ROLE_ARN` lingkungan tidak termasuk dalam wadah aplikasi.

**Resolusi**  
Jika salah satu `AWS_WEB_IDENTITY_TOKEN_FILE` atau variabel `AWS_ROLE_ARN` lingkungan didefinisikan, maka webhook akan melewati pod. Jangan berikan salah satu dari variabel-variabel ini dan webhook akan menyuntikkannya untuk Anda.

```
reservedKeys := map[string]string{
        "AWS_ROLE_ARN":                "",
        "AWS_WEB_IDENTITY_TOKEN_FILE": "",
    }
    ...
    for _, env := range container.Env {
        if _, ok := reservedKeys[env.Name]; ok {
            reservedKeysDefined = true
        }
```

Jika masalah Anda masih belum teratasi, pertimbangkan untuk membuka [GitHub masalah](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) atau hubungi [AWS Support](https://aws.amazon.com/premiumsupport/).