บางครั้งแอพพลิเคชัน .NET ระงับการผลิตและไม่มีใครรู้ว่าทําไมเพราะบันทึกและเมตริกจะดี มันค่อนข้างกังวลและทําให้การแก้ไขปัญหาไม่พอใจมาก ในกรณีดังกล่าวการลบหน่วยความจําอาจทําให้การแก้ไขปัญหาง่ายขึ้นและลดเวลาแก้ไขปัญหาจากวันถึงนาที บทความนี้อธิบายวิธีการกําหนดค่าการวางจําหน่ายสําหรับแอปพลิเคชัน .NET ที่ใช้ใน และส่งไปยังทีมพัฒนาในวิธีที่สะดวกและปลอดภัยที่สุด AWS ECS Fargate ในบทความนี้เราจะสร้างทรัพยากร AWS และฉันจะอ้างถึงเอกสาร AWS ในสถานการณ์ที่เฉพาะเจาะจง IAC จะไม่ได้อยู่ในความสนใจของเรา อย่างไรก็ตามหากคุณสนุกกับ Terraform มากเท่าที่ฉันชอบคุณสามารถใช้โมดูล AWS แบบเปิดสําหรับแต่ละส่วนของบทความ จากส่วนของฉันฉันฉันสามารถแนะนําให้คุณดูสองโครงการโมดูล AWS Terraform: https://github.com/cloudposse https://github.com/terraform-aws-modules ในบทความนี้เราจะสร้างทรัพยากร AWS และฉันจะอ้างถึงเอกสาร AWS ในสถานการณ์ที่เฉพาะเจาะจง IAC จะไม่ได้อยู่ในความสนใจของเรา อย่างไรก็ตามหากคุณสนุกกับ Terraform มากเท่าที่ฉันชอบคุณสามารถใช้โมดูล AWS แบบเปิดสําหรับแต่ละส่วนของบทความ จากส่วนของฉันฉันฉันสามารถแนะนําให้คุณดูสองโครงการโมดูล AWS Terraform: https://github.com/cloudposse https://github.com/terraform-aws-modules https://github.com/cloudposse https://github.com/terraform-aws-modules โซลูชั่นสถาปัตยกรรม มันเป็นเวลาที่จะดูสถาปัตยกรรมของเรา ฉันจะเริ่มต้นโดยการคาดการณ์ว่าทีมพัฒนาไม่ได้พิจารณาการดึง .NET dump จากการจัดเก็บข้อมูลเช่น EBS หรือ EFS เนื่องจากความซับซ้อนของมัน S3 เป็นเรื่องง่ายมากสําหรับนักพัฒนาที่จะได้รับไฟล์ประเภทใด ๆ และเหมาะกับความคาดหวังของเรา นอกเหนือจากนั้นการรับการแจ้งเตือนแบบ proactive เมื่อมีการส่งข้อมูล .NET ใหม่จะถูกสร้างขึ้นจะมีคุณค่าอย่างมาก ตัวอย่างเช่นฉันจะใช้ Slack แต่ตัวเลือกอื่น ๆ ได้แก่ Teams, Mattermost, WhatsApp และอื่น ๆ เพื่อส่งข้อความแจ้งเตือนเราจะใช้ตัวกระตุ้น Lambda และ S3 และข้อความที่สําคัญที่สุด มันค่อนข้างซับซ้อนที่จะยึดถัง S3 โดยธรรมชาติกับ ECS ด้วยเหตุนี้เราจะสร้างชั้น middleware ที่สร้างขึ้นบนด้านบนของ EFS, DataSync และ sidecar ECS container / Lambda ฟังก์ชั่น EFS จะใช้เป็นพื้นที่เก็บไฟล์ intermediate สําหรับงาน ECS ของเรา Datasync จะถ่ายโอนข้อมูลจาก EFS ไปยัง S3 โดยอัตโนมัติและภาชนะ sidecar หรือ Lambda จะทําความสะอาดข้อมูลเก่าจาก EFS ลองตรวจสอบแผนภูมิอย่างรวดเร็ว: AWS Lambda deletes old EFS files by the schedule configured in EventBridge. Alternatively, during ECS Task bootstrap phase, sidecar container removes outdated dumps from EFS and quits. janitor During .NET application crash, a new dump is created at EFS filesystem, and only after that the process is terminated. DataSync moves data to S3 after a new file is uploaded to EFS. When an S3 hook detects a newly uploaded file, AWS Lambda is triggered. AWS Lambda uses IAM to obtain the necessary secrets from AWS Secret Manager. AWS Lambda sends a message to Slack via API. การดําเนินการขั้นตอนตามขั้นตอน สร้างงาน ECS Fargate ในส่วนนี้เราต้องสร้างงาน ECS Fargate โดยใช้แอพพลิเคชัน .NET ตัวอย่าง ข้อกําหนด ก่อนที่เราจะดําเนินการมีขั้นตอนบางอย่างที่ต้องเสร็จสิ้น: Setup ECS cluster via AWS Console, or Terraform. An official AWS guide: Creating an Amazon ECS cluster for Fargate workloads Create an IAM execution role for ECS task. To do it, you can follow . In the scope of this article I will use name for IAM execution role. this AWS guide kvendingoldo-dotnet-crash-dump-demo การสร้างคลัสเตอร์ Amazon ECS สําหรับภาระงาน Fargate คู่มือ AWS นี่ขั้นต่ํา สําหรับบทบาทการดําเนินการจะเพียงพอ: Trust policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } เช่นเดียวกับขั้นต่ํา : permissions policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] } สร้างการกําหนดค่างาน เมื่อข้อกําหนดขั้นพื้นฐานทั้งหมดพร้อมแล้วถึงเวลาที่จะสร้างงาน Fargate อย่างน้อยด้วยแอพ .NET ตัวอย่าง เพื่อทําเช่นนี้ให้ทําตาม , และใช้การกําหนดค่างานนี้ JSON ไฟล์: คู่มือ AWS อย่างเป็นทางการ คู่มือ AWS อย่างเป็นทางการ { "containerDefinitions": [ { "cpu": 0, "essential": true, "image": "mcr.microsoft.com/dotnet/samples:aspnetapp", "mountPoints": [], "name": "app", "portMappings": [ { "containerPort": 8000, "hostPort": 8000, "protocol": "tcp" } ], "systemControls": [], "volumesFrom": [] } ], "cpu": "256", "executionRoleArn": "kvendingoldo-dotnet-crash-dump-demo", "family": "kvendingoldo-dotnet-crash-dump-demo", "memory": "512", "networkMode": "awsvpc", "placementConstraints": [], "requiresCompatibilities": ["FARGATE"], "volumes": [], "tags": [] } การตั้งค่า .NET dumps โดยค่าเริ่มต้นแอพ .NET ไม่สร้าง dumps ใด ๆ เพื่อกําหนดค่าเราต้องตั้งค่าตัวแปรสภาพแวดล้อมต่อไปนี้: # Forces the runtime to generate a stack dump on unhandled exceptions. COMPlus_StackDumpOnUnhandledException=1 # Enable mini dump generation on crash COMPlus_DbgEnableMiniDump=1 # Choose dump type: # 1 = Mini, # 2 = Full (use carefully) # 4 = Triage (includes stack, threads, and some heap info — a good balance for debugging). COMPlus_DbgMiniDumpType=2 # Target path for dump file (EFS is mounted here) COMPlus_DbgMiniDumpName=/dumps/dump-%e-%p-%t.dmp พารามิเตอร์เหล่านี้สามารถเพิ่มโดยตรงไปยัง Dockerfile หรือกําหนดเป็นพารามิเตอร์สภาพแวดล้อมใน ECS Task Definition json ในตัวอย่างของเราเราจะฉีดพวกเขาลงในข้อกําหนดงาน ECS เพื่อให้บรรลุนี้เราจะเพิ่มพวกเขาลงใน ตามที่แสดงด้านล่าง: containerDefinitions[0].environment "environment": [ { "name": "COMPlus_StackDumpOnUnhandledException", "value": "1" }, { "name": "COMPlus_DbgMiniDumpType", "value": "4" }, { "name": "COMPlus_DbgEnableMiniDump", "value": "1" }, { "name": "COMPlus_DbgMiniDumpName", "value": "/dumps/%t-kvendingoldo-dotnet-demo-crash.dmp" } ] ดังที่คุณเห็นฉันใช้ผู้ถือตําแหน่งหลายคนใน COMPlus_DbgMiniDumpName Dotnet จะขยายผู้ถือตําแหน่งต่อไปนี้โดยอัตโนมัติในชื่อไฟล์ dump: %e - ชื่อที่สามารถดําเนินการได้ %p - ID กระบวนการ %t - timestamp ดูลิงก์เหล่านี้สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการเก็บรวบรวมและวิเคราะห์ขยะ .NET crash: Collect .NET Crash Dumps (Microsoft เรียนรู้) การแก้ไขปัญหาหน่วยความจํา .NET Core (บน Linux) ด้วย Dump Dotnet ดังที่คุณเห็นฉันใช้ผู้ถือตําแหน่งหลายคนใน COMPlus_DbgMiniDumpName Dotnet จะขยายผู้ถือตําแหน่งต่อไปนี้โดยอัตโนมัติในชื่อไฟล์ dump: %e - ชื่อที่สามารถดําเนินการได้ %p - ID กระบวนการ %t - ช่วงเวลา ดูลิงก์เหล่านี้สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการเก็บรวบรวมและวิเคราะห์ขยะ .NET crash: Collect .NET Crash Dumps (Microsoft เรียนรู้) การแก้ไขปัญหาหน่วยความจํา .NET Core (บน Linux) ด้วย Dump Dotnet Collect .NET Crash Dumps (Microsoft เรียนรู้) การแก้ไขปัญหาหน่วยความจํา .NET Core (บน Linux) ด้วย Dump Dotnet สร้างพื้นที่เก็บข้อมูล EFS และติดตั้งลงในงาน ECS Fargate ดังที่ฉันได้กล่าวถึงที่จุดเริ่มต้นของบทความนี้การยึดถัง S3 กับงาน ECS นั้นค่อนข้างยาก แต่เราจะใช้ เป็นพื้นที่เก็บข้อมูลกลางสําหรับไฟล์ .NET dump ซึ่งสามารถติดตั้งกับชุดงาน ECS ได้อย่างง่ายดาย Amazon EFS (Elastic File System) หากต้องการสร้างพื้นที่เก็บข้อมูล EFS โปรดทําตามคู่มือ AWS อย่างเป็นทางการ: Amazon ECS Tutorial: Using Amazon EFS File Systems หากต้องการสร้างพื้นที่เก็บข้อมูล EFS โปรดทําตามคู่มือ AWS อย่างเป็นทางการ: Amazon ECS Tutorial: Using Amazon EFS File Systems Amazon ECS Tutorial: การใช้ระบบไฟล์ Amazon EFS ไม่มีอะไรพิเศษที่จะเพิ่มลงในเอกสารอย่างเป็นทางการ เพียงให้แน่ใจว่า: EFS และ ECS Cluster ใน VPC เดียวกัน EFS สามารถเข้าถึงได้โดยงาน ECS ผ่าน NFS (พอร์ต 2049/tcp) เพื่อให้สามารถเข้าถึงพอร์ต NFS ในกลุ่มความปลอดภัย EFS ได้ To mount EFS filesystem into the ECS task we must grant the necessary permissions to the บทบาท IAM (ให้ความสนใจกับผู้ถือตําแหน่ง): kvendingoldo-dotnet-crash-dump-demo { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowEFSAccess", "Effect": "Allow", "Action": [ "elasticfilesystem:ClientMount", "elasticfilesystem:ClientWrite", "elasticfilesystem:ClientRootAccess" ], "Resource": "arn:aws:elasticfilesystem:<region>:<account-id>:file-system/<filesystem-id>" } ] } ในขั้นตอนสุดท้ายกําหนดปริมาณ EFS และจุดติดตั้งในการกําหนดค่างาน ECS ของคุณ (change fileSystemId กับ ID ระบบไฟล์จริงของคุณหลังจาก bootstrapping): fs-xxxxxx "volumes": [ { "name": "dotnet-dumps", "efsVolumeConfiguration": { "fileSystemId": "fs-xxxxxx", "rootDirectory": "/" } } ] "mountPoints": [ { "containerPath": "/dumps", "readOnly": false, "sourceVolume": "dotnet-dumps" } ] การกําหนดค่า AWS DataSync เพื่อถ่ายโอนไฟล์ EFS ไปยัง S3 บริการ DataSync เป็นเครื่องมือมาตรฐานของ AWS สําหรับการถ่ายโอนข้อมูลระหว่างประเภทการจัดเก็บข้อมูลต่างๆ ในกรณีของเรามันจะช่วยให้เรา move.NET dumps จาก EFS ไปยัง S3 เพื่อให้บรรลุเป้าหมายของเราเราต้อง: Create an S3 bucket to store our.NET dumps. Further in this article I’ll use S3 bucket name kvendingoldo-dotnet-demo-crash Use to create a bucket. this official doc Create DataSync Use to create DataSync. this official doc Some service parameters I'll be using: Source: EFS Destination: S3 bucket (e.g., ) s3://kvendingoldo-dotnet-demo-crash/ Include path filters like /dumps/* Schedule sync every minute this official doc สิทธิทางการนี้ doc สร้างการแจ้งเตือน Slack ขึ้นอยู่กับ AWS Lambda ดังกล่าวก่อนหน้านี้การแจ้งเตือนเกี่ยวกับ new.NET dumps มีประโยชน์อย่างมากสําหรับทีมพัฒนา จากมุมมองของสถาปัตยกรรมการแจ้งเตือนสามารถสร้างได้ในหลายวิธี: ฟังก์ชั่น lambda ง่ายที่ส่งข้อความไปยัง Slack ผ่าน API และกระตุ้นโดยเหตุการณ์ S3 ข้อความจะเผยแพร่ไปยังหัวข้อ SNS โดยใช้การแจ้งเตือนเหตุการณ์ S3 ที่กําหนดค่าซึ่งจะเปิดใช้งานฟังก์ชั่น Lambda เพื่อส่งเหตุการณ์ไปยัง Slack เนื่องจากเราไม่คาดหวังโหลดสูงตัวเลือกแรกจะดีกว่าสําหรับเรา ในกรณีที่คุณต้องการใช้ตัวเลือกที่สองใช้ลิงก์เหล่านี้: โมดูล Terraform สําหรับการใช้งาน SNS และ Lambda Stack คู่มือในการกําหนดค่าเหตุการณ์ S3 ไปยัง SNS โมดูล Terraform สําหรับการใช้งาน SNS และ Lambda Stack คู่มือในการกําหนดค่าเหตุการณ์ S3 ไปยัง SNS เราใช้ Python เพื่อส่งข้อความไปยัง Slack ในบทความนี้เราจะส่งลิงก์ไปยังไฟล์ S3 เท่านั้น แต่ในบางกรณีจําเป็นต้องส่งไฟล์ทั้งหมด Slack API มีการเปลี่ยนแปลงเป็นเวลานานแล้วและการส่งไฟล์อาจเป็นเรื่องซับซ้อนเล็กน้อย หากคุณต้องการทราบข้อมูลเพิ่มเติมโปรดดูบทความ “อัปโหลดไฟล์ไปยัง Slack ด้วย Python” เราใช้ Python เพื่อส่งข้อความไปยัง Slack ในบทความนี้เราจะส่งลิงก์ไปยังไฟล์ S3 เท่านั้น แต่ในบางกรณีจําเป็นต้องส่งไฟล์ทั้งหมด Slack API มีการเปลี่ยนแปลงเป็นเวลานานแล้วและการส่งไฟล์อาจเป็นเรื่องซับซ้อนเล็กน้อย หากคุณต้องการทราบข้อมูลเพิ่มเติมโปรดดูบทความ “อัปโหลดไฟล์ไปยัง Slack ด้วย Python” การอัปโหลดไฟล์ไปยัง Slack ด้วย Python Ok, ลองสร้างการแจ้งเตือนขั้นตอนตามขั้นตอน: 1. Create Slack secret สร้าง AWS Secret Manager Secret ด้วยฟิลด์เดียว: คีย์นี้ควรมีลิงก์ไปยัง Webhook Slack ของคุณ (เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการตรวจสอบ Webhook Slack) ) kvendingoldo-dotnet-crash-dump-demo slack_webhook_url คู่มืออย่างเป็นทางการ คู่มืออย่างเป็นทางการ 2. Configure AWS Lambda เราจะไม่เข้าสู่ความลึกเกี่ยวกับการสร้าง AWS Lambda แต่เราจะเน้นจุดสําคัญบางอย่าง สําหรับข้อมูลพื้นฐานเพิ่มเติมเกี่ยวกับการติดตั้ง AWS Lambda โปรดดูที่ . the official guide คู่มืออย่างเป็นทางการ 2.1. ตรวจสอบให้แน่ใจว่าบทบาท Lambda IAM มีสิทธิ์ในการอ่านจาก S3: { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::kvendingoldo-dotnet-demo-crash/*" } 2.2: เพื่อรับข้อมูลจากผู้จัดการ AWS Secret เราต้องระบุตัวแปรสภาพแวดล้อมในการกําหนดค่า Lambda ของ AWS: SECRET_NAME=kvendingoldo-dotnet-demo-crash 2.3:อัปโหลดรหัส Python ไปยัง Lambda import json import urllib3 import os import boto3 def get_secret(secret_name): client = boto3.client("secretsmanager") try: response = client.get_secret_value(SecretId=secret_name) if "SecretString" in response: secret = response["SecretString"] try: return json.loads(secret) except json.JSONDecodeError: return secret else: return response["SecretBinary"] except Exception as e: print(f"Error retrieving secret: {e}") return None def lambda_handler(event, context): print("Event received:", json.dumps(event)) secret_name = os.environ.get('SECRET_NAME', '') if secret_name == "": return { 'statusCode': 500, 'body': json.dumps("SECRET_NAME env variable is empty") } secret = get_secret(secret_name) slack_webhook_url = secret["slack_webhook_url"] for record in event['Records']: bucket_name = record['s3']['bucket']['name'] file_name = record['s3']['object']['key'] region = record['awsRegion'] if ".aws" in file_name: print(f"Skipping internal file: {file_name}") continue message = ( f":package: *New .NET dump is uploaded!*\n\n" f":cloud: Bucket: `{bucket_name}`\n" f":floppy_disk: File: `{file_name}`\n" f":link: Link: https://{bucket_name}.s3.{region}.amazonaws.com/{file_name}" ) http = urllib3.PoolManager() slack_resp = http.request( "POST", slack_webhook_url, body=json.dumps({ "text": message }), headers={ "Content-Type": "application/json" } ) if slack_resp.status != 200: raise Exception( f"Slack webhook request failed with status {slack_resp.status}: {slack_resp.data.decode('utf-8')}") return { "statusCode": 200, "body": json.dumps("Message has been sent successfully!") } 2.4: กําหนดค่าการแจ้งเตือนเหตุการณ์ S3 สําหรับถัง S3 ของคุณ เพื่อทําเช่นนี้โปรดไปที่ และเลือก“ ". กําหนดค่าเหตุการณ์โดยใช้ตัวเลือกต่อไปนี้: อะไหล่ -> คุณสมบัติ -> การแจ้งเตือนเหตุการณ์ สร้างการแจ้งเตือนเหตุการณ์ ชื่อเหตุการณ์: kvendingoldo-dotnet-demo-crash แพ็คเกจ: Dumps ประเภทเหตุการณ์: s3:ObjectCreated:* เป้าหมาย: <ชื่อฟังก์ชั่น Lambda ของคุณ> การตั้งค่าการทําความสะอาดการจัดเก็บ EFS สมบูรณ์แบบโซ่การส่งมอบ .NET dumps พร้อมแล้ว แต่มันคืออะไรเกี่ยวกับขยะเก่า? EFS ไม่อนุญาตให้เราลบไฟล์เก่าโดยใช้นโยบายวงจรชีวิต; เราสามารถถ่ายโอนพวกเขาไปยังประเภทการเก็บข้อมูล Access ที่หายากซึ่งไม่เพียงพอถ้าเราไม่ต้องการจ่ายสําหรับพื้นที่ที่ไม่จําเป็น เพื่อแก้ปัญหานี้มีสองทางเลือก: สร้างคอนเทนเนอร์ ECS sidecar ที่จะทําความสะอาดไฟล์ EFS เก่าในขั้นตอนการเริ่มต้น สร้างงาน Lambda หรือ ECS ที่จะติดตั้ง EFS และทําความสะอาดไฟล์เก่าโดย CRON ลองตรวจสอบทั้งสอง ตัวเลือก 1: AWS Lambda นี่เป็นโซลูชั่นที่ดีที่สุดเนื่องจากไม่ได้รับผลกระทบจากวงจรชีวิตของงาน ECS และปัจจัยอื่น ๆ เพื่อใช้กลยุทธ์นี้คุณต้องสร้างฟังก์ชั่น Lambda พร้อมการจัดเก็บ EFS ที่ติดตั้ง (เรียนรู้เพิ่มเติมเกี่ยวกับการติดตั้งระบบไฟล์ใน Lambda จาก ) และรหัส Python ต่อไปนี้: the official doc the official doc import os import time import json def lambda_handler(event, context): # Note: you can only mount the filesystem to the /mnt/ directory. directory = '/mnt/dumps' # File pattern to match pattern = 'crash.dmp' # Time in minutes (by default 1d) minutes_old = 1440 # Convert minutes to seconds age_seconds = minutes_old * 60 # Current time now = time.time() for root, dirs, files in os.walk(directory): for file in files: if pattern in file: file_path = os.path.join(root, file) file_mtime = os.path.getmtime(file_path) if now - file_mtime > age_seconds: print(f"Found a file that older than {minutes_old} minutes: {file_path}") try: os.remove(file_path) except Exception as e: print(f"Failed to delete {file_path}: {e}") return { "statusCode": 200, "body": json.dumps("EFS clean-up completed successfully!") } ดังที่คุณเห็นนี่เป็นรหัสที่เรียบง่ายที่ลบไฟล์จากพื้นที่เก็บข้อมูลที่ติดตั้งซึ่งมีอายุมากกว่าหนึ่งวัน เมื่อ Lambda ของคุณพร้อมแล้วเรายังต้องกําหนดค่าตัวกระตุ้น CRON เพื่อเรียกใช้ฟังก์ชั่นเป็นประจํา สามารถสร้างได้โดยใช้__ ภาษาไทย Cloudwatch กฎเหตุการณ์ นั่นคือหลังจากทั้งหมดขั้นตอนเหล่านี้การจัดเก็บ EFS ของคุณจะถูกทําความสะอาดโดยอัตโนมัติโดยตาราง CRON ของคุณ ตัวเลือก 2: คอนเทนเนอร์ ECS sidecar เพื่อใช้ตัวเลือกนี้เราต้องเพิ่มคอนเทนเนอร์ใหม่ลงในคําจํากัดงานของเรา: { "essential": false, "name": "janitor", "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "command": [ "bash", "-lc", "find /dumps -name '*crash.dmp*' -type f -mmin +10080 -print -delete" ], "mountPoints": [ { "containerPath": "/dumps", "readOnly": false, "sourceVolume": "dotnet-dumps" } ], "linuxParameters": { "initProcessEnabled": true } } เหตุผลที่อยู่เบื้องหลังงานนี้: เริ่มต้นงาน ECS ใหม่ด้วยสองภาชนะ: app และ janitor ทําความสะอาดไฟล์ EFS ที่หมดอายุในภาชนะ janitor และออก ไม่ว่างานจะไม่ได้หยุดหรือหยุดเนื่องจาก ECS ตัวเลือก "จําเป็น": false As you can see, this technique is quite straightforward and relies on find command, which you can customize. In the example, it deletes files that are older than 10080 minutes (7 days). Of course, this strategy is less desirable than the first when dealing with long-lived ECS tasks, but it may be more convenient for short-lived ECS tasks or prototyping. เวลาทดสอบ ในส่วนนี้เราจะไม่เจาะลึกเข้าไปในการสร้างแอปพลิเคชัน .NET สําหรับวัตถุประสงค์ในการทดสอบคุณสามารถแก้ไข ที่เราใช้ในตอนแรก ตัวอย่าง Aspnetapp ตัวอย่าง Aspnetapp วิธีที่ง่ายที่สุดในการทําให้เกิดความผิดพลาดของ .NET คือ วิธีการนี้ใช้กันอย่างแพร่หลายในการจําลอง . Environment.FailFast() แตกหนัก ลองจําลองการกระแทก: เพิ่ม Environment.FailFast("kvendingoldo-dotnet-demo-crash .NET example crash"); สายไปยังไฟล์ dotnet-docker/samples/aspnetapp/aspnetapp/Program.cs สร้างภาพ docker ใหม่และสร้างงาน ECS อีกครั้ง ECS Task จะสิ้นสุดลง แต่ก่อนที่จะสร้าง .NET crash dump ซึ่งจะสามารถใช้ได้ใน S3 ในไม่กี่วินาที ในขั้นตอนสุดท้ายคุณจะได้รับข้อความบน Slack ของคุณเช่นนี้: 📦 New .NET dump is uploaded! ☁️ Bucket: kvendingoldo-dotnet-demo-crash 💾 File: 1739104252-kvendingoldo-dotnet-demo-crash.dmp 🔗 Link: https://kvendingoldo-dotnet-demo-crash.s3.us-east-2.amazonaws.com/1739104252-kvendingoldo-dotnet-demo-crash.dmp การปรับปรุงที่เป็นไปได้ ก่อนที่จะบรรจุบทความผมอยากจะให้ความคิดเห็นเกี่ยวกับการเปลี่ยนแปลงที่เป็นไปได้: จะเป็นความคิดที่ดีที่จะสร้าง URL ที่ลงนามไว้ล่วงหน้าสําหรับวัตถุ S3 กําหนดนโยบายวงจรชีวิตสําหรับถัง S3 เพื่อลบขยะเก่าจากถังโดยอัตโนมัติ ใช้ SNS เพื่อส่งการแจ้งเตือนเกี่ยวกับวัตถุ S3 ใหม่ไปยังหลายเป้าหมาย ข้อสรุป ในสภาพแวดล้อมการผลิตการมองเห็นความผิดพลาดอย่างรวดเร็วเป็นสิ่งสําคัญ การส่งมอบขยะอัตโนมัติช่วยลด MTTR (Mean Time To Resolution) และปรับปรุงการตอบสนองต่อเหตุการณ์ ดังที่คุณสามารถเห็นการใช้งานขั้นตอนนี้ไม่ยากเท่าที่คุณคาดหวัง ใช่เราได้ใช้บริการ AWS หลายแห่งเพื่อทําหน้าที่เหล่านี้ แต่เมื่อเราดูลึกขึ้นพวกเขามีความสําคัญทั้งหมด ฉันหวังว่าบทความนี้ช่วยให้คุณสร้างโซ่การจัดส่งขยะส่วนบุคคลและทําให้ทีมพัฒนาของคุณมีความสุขมากขึ้น รู้สึกอิสระที่จะแก้ไขวิธีการที่นําเสนอและโปรดติดต่อฉันได้ตลอดเวลาหากคุณมีคําถามใด ๆ โค้ดความสุข!
