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

# Memecahkan masalah kesalahan server internal di Amazon DynamoDB
<a name="TroubleshootingInternalServerErrors"></a>

Di DynamoDB, kesalahan server internal (500 kesalahan) menunjukkan bahwa layanan tidak dapat melayani permintaan. Kesalahan ini dapat terjadi karena berbagai alasan, seperti masalah jaringan sementara di armada, masalah infrastruktur, masalah terkait node penyimpanan, dan banyak lagi.

Anda mungkin mengalami beberapa kesalahan server internal selama siklus hidup tabel DynamoDB Anda. Hal ini diharapkan karena sifat layanan yang didistribusikan dan biasanya tidak perlu dikhawatirkan. DynamoDB secara otomatis memperbaiki dan menyembuhkan masalah sementara dengan layanan secara real time, tanpa memerlukan intervensi dari Anda. Namun, jika Anda mengamati jumlah kesalahan server internal yang tinggi secara konsisten pada permintaan ke tabel Anda (seperti yang terlihat dalam [SystemErrors](metrics-dimensions.md#SystemErrors) metrik), Anda harus menyelidiki lebih lanjut.

**Topics**
+ [Menyelidiki kesalahan server internal](#ServerErrors-investigating)
+ [Meminimalkan dampak dari kesalahan server internal](#ServerErrors-minimizing-impact)
+ [Meningkatkan kesadaran operasional](#ServerErrors-improving-operational-awareness)

## Menyelidiki kesalahan server internal
<a name="ServerErrors-investigating"></a>

Jika Anda mengalami kesalahan server internal di tabel DynamoDB Anda, pertimbangkan opsi ini:

1. **Periksa Dasbor AWS Kesehatan.**

   Untuk mengidentifikasi masalah, langkah pertama adalah memeriksa [AWS Service Health Dashboard dan Dashboard](https://health.aws.amazon.com/health/status) Kesehatan AWS Akun Anda. Dasbor ini memberikan informasi berharga tentang masalah di seluruh layanan, tabel yang terkena dampak, masalah yang sedang berlangsung, dan akar penyebab setelah masalah diselesaikan.

   Meninjau detail di dasbor ini akan memberi Anda pemahaman yang lebih baik tentang status saat ini yang Layanan AWS Anda gunakan dan potensi masalah apa pun yang memengaruhi akun Anda. Informasi ini dapat membantu Anda menentukan langkah selanjutnya untuk mengatasi masalah dan meminimalkan gangguan pada operasi Anda.

1. **Jangkau Dukungan.**

   Jika Anda mengamati kesalahan yang berkepanjangan dan berkelanjutan dalam permintaan Anda, itu mungkin menunjukkan masalah dengan layanan. Sebagai aturan umum, jika Anda melihat tingkat kegagalan keseluruhan 1% atau lebih selama 15 menit terakhir, ini adalah waktu yang tepat untuk meningkatkan masalah ke tim AWS Support. Lihat, [DynamoDB Service Level Agreement](https://aws.amazon.com/dynamodb/sla/) untuk mempelajari lebih lanjut.

   Saat membuka kasus dengan tim AWS Support, berikan detail berikut untuk membantu mempercepat proses pemecahan masalah:
   + DDB yang terkena dampak; tabel atau indeks sekunder
   + Jendela waktu ketika kesalahan diamati
   +  IDsPermintaan DynamoDB, `4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG` seperti, yang dapat Anda temukan di log aplikasi Anda.

   Menyertakan detail ini dalam kasus dukungan akan membantu AWS tim memahami masalah dan memberikan resolusi yang lebih cepat. Jika Anda tidak memiliki permintaan IDs, Anda masih harus mencatat kasus ini dengan detail lain yang tersedia.

## Meminimalkan dampak dari kesalahan server internal
<a name="ServerErrors-minimizing-impact"></a>

Jika kesalahan server internal terjadi saat menggunakan DynamoDB, meminimalkan dampaknya pada aplikasi Anda, pertimbangkan praktik terbaik berikut:
+ Gunakan backoff dan percobaan ulang — Perilaku SDK default DynamoDB dirancang untuk menemukan keseimbangan yang tepat untuk sebagian besar aplikasi dalam hal strategi back-off dan coba lagi. Namun, Anda dapat menyesuaikan pengaturan ini berdasarkan toleransi aplikasi Anda terhadap waktu henti dan persyaratan kinerja. Pelajari lebih lanjut tentang back-off dan percobaan ulang untuk memahami bagaimana Anda dapat menyempurnakan pengaturan coba ulang ini.
+ Gunakan pembacaan yang konsisten pada akhirnya — Jika aplikasi Anda tidak memerlukan pembacaan yang sangat konsisten, pertimbangkan untuk menggunakan pembacaan yang konsisten pada akhirnya. Pembacaan ini berbiaya lebih rendah dan kecil kemungkinannya untuk mengalami masalah sementara karena kesalahan server internal karena akan disajikan dari salah satu Node Penyimpanan yang tersedia. Untuk informasi selengkapnya, lihat [DynamoDB membaca konsistensi](HowItWorks.ReadConsistency.md).

## Meningkatkan kesadaran operasional
<a name="ServerErrors-improving-operational-awareness"></a>

Mempertahankan ketersediaan tinggi dan keandalan aplikasi Anda sangat penting dalam lanskap digital saat ini. Salah satu aspek kunci dari ini adalah secara proaktif memantau kesalahan server internal (ISEs) di tabel DynamoDB Anda dan indeks sekunder global (). GSIs Dengan membuat CloudWatch alarm untuk memantau kesalahan ini, Anda dapat memperoleh kesadaran operasional yang lebih baik dan diberi tahu tentang potensi masalah sebelum berdampak pada pengguna akhir Anda. Pendekatan ini sejalan dengan pilar Operational Excellence dari AWS Well-Architected Framework, memastikan beban kerja DynamoDB Anda dioptimalkan untuk kinerja, keamanan, dan keandalan.

**Membuat CloudWatch alarm**

Anda harus mengatur CloudWatch alarm pada tabel DynamoDB Anda untuk menerima pemberitahuan untuk jumlah kesalahan server internal yang tinggi secara konsisten alih-alih mengamati metrik secara manual. Ini terkait dengan pilar keunggulan operasional kerangka kerja Well-Architected untuk setiap beban kerja. AWS Lihat [Menggunakan DynamoDB Well-Architected Lens untuk mengoptimalkan beban kerja DynamoDB Anda](bp-wal.md) untuk mempelajari lebih lanjut tentang Merancang dengan Baik tabel DynamoDB Anda.

Alarm ini menggunakan matematika metrik khusus untuk menghitung persentase permintaan yang gagal untuk jendela 5 menit. Praktik terbaik yang disarankan adalah mengonfigurasi alarm untuk memasuki `ALARM` status ketika 3 titik data berturut-turut melanggar ambang batas 1%, yang berarti bahwa keseluruhan 1% permintaan gagal dalam periode 15 menit.

Contoh di bawah ini adalah CloudFormation template yang dapat membantu Anda membuat CloudWatch alarm di meja Anda dan GSI di atas meja.

```
AWSTemplateFormatVersion: "2010-09-09"
Description: Sample template for monitoring DynamoDB
Parameters:  
 DynamoDBProvisionedTableName: 
    Description: Name of DynamoDB Provisioned Table to create
    Type: String
    MinLength: 3
    MaxLength: 255
    ConstraintDescription : https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html#limits-naming-rules
  DynamoDBSNSEmail:
    Description : Email Address subscribed to newly created SNS Topic
    Type: String
    AllowedPattern: "^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+$"
    MinLength: 1
    MaxLength: 255

Resources:
  DynamoDBMonitoringSNSTopic:
    Type: AWS::SNS::Topic
    Properties: 
      DisplayName: DynamoDB Monitoring SNS Topic
      Subscription: 
        - Endpoint: !Ref DynamoDBSNSEmail
          Protocol: email
      TopicName: dynamodb-monitoring
      
  DynamoDBTableSystemErrorAlarm:
    Type: 'AWS::CloudWatch::Alarm'
    Properties:
      AlarmName: 'DynamoDBTableSystemErrorAlarm'
      AlarmDescription: 'Alarm when system errors exceed 1% of total number of requests for 15 minutes'
      AlarmActions:
        - !Ref DynamoDBMonitoringSNSTopic
      Metrics:
        - Id: 'e1'
          Expression: 'm1/(m1+m2+m3)'
          Label: SystemErrorsOverTotalRequests
        - Id: 'm1'
          MetricStat:
            Metric:
              Namespace: 'AWS/DynamoDB'
              MetricName: 'SystemErrors'
              Dimensions:
                - Name: 'TableName'
                  Value: !Ref DynamoDBProvisionedTableName
            Period: 300
            Stat: 'SampleCount'
            Unit: 'Count'
          ReturnData: False
        - Id: 'm2'
          MetricStat:
            Metric:
              Namespace: 'AWS/DynamoDB'
              MetricName: 'ConsumedReadCapacityUnits'
              Dimensions:
                - Name: 'TableName'
                  Value: !Ref DynamoDBProvisionedTableName
            Period: 300
            Stat: 'SampleCount'
            Unit: 'Count'
          ReturnData: False
        - Id: 'm3'
          MetricStat:
            Metric:
              Namespace: 'AWS/DynamoDB'
              MetricName: 'ConsumedWriteCapacityUnits'
              Dimensions:
                - Name: 'TableName'
                  Value: !Ref DynamoDBProvisionedTableName
            Period: 300
            Stat: 'SampleCount'
            Unit: 'Count'
          ReturnData: False
      EvaluationPeriods: 3
      Threshold: 1.0
      ComparisonOperator: 'GreaterThanThreshold'
  DynamoDBGSISystemErrorAlarm:
    Type: 'AWS::CloudWatch::Alarm'
    Properties:
      AlarmName: 'DynamoDBGSISystemErrorAlarm'
      AlarmDescription: 'Alarm when GSI system errors exceed 2% of total number of requests for 15 minutes'
      AlarmActions:
        - !Ref DynamoDBMonitoringSNSTopic
      Metrics:
        - Id: 'e1'
          Expression: 'm1/(m1+m2+m3)'
          Label: GSISystemErrorsOverTotalRequests
        - Id: 'm1'
          MetricStat:
            Metric:
              Namespace: 'AWS/DynamoDB'
              MetricName: 'SystemErrors'
              Dimensions:
                - Name: 'TableName'
                  Value: !Ref DynamoDBProvisionedTableName
                - Name: 'GlobalSecondaryIndexName'
                  Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
            Period: 300 
            Stat: 'SampleCount'
            Unit: 'Count'
          ReturnData: False
        - Id: 'm2'
          MetricStat:
            Metric:
              Namespace: 'AWS/DynamoDB'
              MetricName: 'ConsumedReadCapacityUnits'
              Dimensions:
                - Name: 'TableName'
                  Value: !Ref DynamoDBProvisionedTableName
                - Name: 'GlobalSecondaryIndexName'
                  Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
            Period: 300 
            Stat: 'SampleCount'
            Unit: 'Count'
          ReturnData: False
        - Id: 'm3'
          MetricStat:
            Metric:
              Namespace: 'AWS/DynamoDB'
              MetricName: 'ConsumedWriteCapacityUnits'
              Dimensions:
                - Name: 'TableName'
                  Value: !Ref DynamoDBProvisionedTableName
                - Name: 'GlobalSecondaryIndexName'
                  Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
            Period: 300 
            Stat: 'SampleCount'
            Unit: 'Count'
          ReturnData: False
      EvaluationPeriods: 3
      Threshold: 1.0
      ComparisonOperator: 'GreaterThanThreshold'
```