Menyelidiki kesalahan server internal Meminimalkan dampak dari kesalahan server internal Meningkatkan kesadaran operasional

Memecahkan masalah kesalahan server internal di Amazon DynamoDB

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 metrik), Anda harus menyelidiki lebih lanjut.

Topik

Menyelidiki kesalahan server internal
Meminimalkan dampak dari kesalahan server internal
Meningkatkan kesadaran operasional

Menyelidiki kesalahan server internal

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

Periksa AWS Dasbor Kesehatan.

Untuk mengidentifikasi masalah, langkah pertama adalah memeriksa AWS Service Health Dashboard dan AWS Dasbor Kesehatan Akun. 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 Layanan AWS Anda menggunakan 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.
Jangkau AWS Support.

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 AWS Tim Support. Lihat, DynamoDB Service Level Agreement untuk mempelajari lebih lanjut.

Saat membuka kasing dengan AWS Tim Support, berikan detail berikut untuk membantu mempercepat proses pemecahan masalah:
- TerdampakDDB; 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 permintaanIDs, Anda masih harus mencatat kasus ini dengan detail lain yang tersedia.

Meminimalkan dampak dari kesalahan server internal

Jika kesalahan server internal terjadi saat menggunakan DynamoDB, meminimalkan dampaknya pada aplikasi Anda, pertimbangkan praktik terbaik berikut:

Gunakan backoff dan percobaan ulang — SDK perilaku 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.

Meningkatkan kesadaran operasional

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 Keunggulan Operasional 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 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 AWS 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'

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Memecahkan masalah

Latensi