Verwenden Sie AWS X-Ray, um Ihre Anwendung zu verfolgen und zu verstehen

Da FloQast sich auf Microservices und die Entkopplung unserer Serviceinfrastruktur konzentriert hat, standen wir vor einer Reihe von Herausforderungen, darunter der Fähigkeit, unsere Systeme nicht nur zu überwachen und zu protokollieren, sondern auch die internen Abläufe unserer Anwendung mithilfe von Tracing zu verstehen. Um mit der Lösung dieser Probleme zu beginnen, hat FloQast kürzlich das X-Ray von AWS implementiert.

Das Problem

Als schnell wachsendes Unternehmen, wir fügen der Codebasis jeden Tag mehr und mehr Geschäftslogik hinzu. Wir stellten fest, dass ein Teil des Codes zu Engpässen führte. Wir wollten, dass alle Entscheidungen, die wir zur Behebung dieser Engpässe treffen, datengesteuert und testbar sind. Deshalb begannen wir, Kennzahlen zu sammeln, um die Leistung für unsere Endbenutzer zu verbessern.

Eine kurze Geschichte von X-Ray

X-Ray ist ein AWS-Service Dadurch können Benutzer einen Einblick in die Anforderungen erhalten, die Ihre Anwendung bearbeitet. Es enthält ein Dashboard, in dem Benutzer aussagekräftige Daten anzeigen, filtern und sammeln können, um Fehler und Optimierungsmöglichkeiten zu identifizieren. Sie können Anfragen auch problemlos über AWS-Ressourcen und andere Microservices hinweg verfolgen.

Ein Machbarkeitsnachweis für X-Ray

Den Code einpacken

Um die Abschnitte Geschäftslogik und Datenbanklogik zu überwachen, haben wir am Beispiel des AWS-SDK unseren eigenen X-Ray-Wrapper erstellt.

Xray.callbackCapture = (identifier, segment, obj, func) => {
    return (...args) => {
        const subsegment = segment.addNewSubsegment(identifier);
        const callback = args[args.length - 1];
        args[callbackIdx] = (...callbackArgs) => {
            if (callbackArgs[0]) {
                subsegment.close(callbackArgs[0]);
            } else {
                subsegment.close();
            }

            return callback.apply(this, callbackArgs);
        }

        return func.apply(obj,args);
    }
}

‍‍Abbildung 1: Eine Illustration unserer X-Ray-Wrapper-Implementierung‍

Wir haben bei der Entwicklung dieser Wrapper auch Wert auf Flexibilität gelegt, sodass sie sowohl auf Strecken mit X-Ray als auch auf Strecken ohne X-Ray funktionieren. Für uns war es wichtig, die Anwendung nicht zu beschädigen, falls X-Ray nicht richtig funktioniert.

Der Dämon

Als X-Ray-Daemon wird von AWS empfohlen, alle X-Ray-Anfragen zu stapeln, bevor sie an AWS gesendet werden. Zu diesem Zweck haben wir diesen Daemon als Beiwagen zu unserer Hauptaufgabe in AWS ECS entwickelt und ausgeführt.

Nun zur Infrastruktur. Zunächst betrachteten wir einen X-Ray-Daemon, der in einem eigenen ECS-Service und einem eigenen EC2-Container läuft. Unsere EC2-Leistungskennzahlen zeigten jedoch, dass wir über genügend Bandbreite verfügten, um einen X-Ray-Daemon Seite an Seite mit der Hauptaufgabe auszuführen. Darüber hinaus erkannten wir, dass die ursprüngliche Methode zusätzliche Kosten verursachen würde und außerdem eine unabhängige Bereitstellungspipeline für AWS X-Ray erfordert. Daher haben wir entschieden, dass es effizienter ist, eine neue Aufgabendefinition zu haben, um den AWS X-Ray Daemon Seite an Seite mit der Haupt-App-Aufgabe im selben EC2-Container auszuführen. Die folgenden Ressourcen sollten zu Ihrer Terraform im Terraform-Infrastructure-Repository hinzugefügt werden:

cloudwatch.tf:

resource "aws_cloudwatch_log_group" "xray" {
  name = "/fq/${var.environment}/${var.service_name}-watcher/instance/xray"
}

ecs.tf:

resource "aws_ecs_service" "ecs-watcher" {
  ...
  depends_on = [
    ...
    "aws_cloudwatch_log_group.xray"
  ]
  ...

‍‍Richtlinien/ecsServiceInstanceRolePolicy.json:

   {
        "Sid": "XRayDaemonWriteAccess",
        "Effect": "Allow",
        "Action": [
            "xray:PutTraceSegments",
            "xray:PutTelemetryRecords",
            "xray:GetSamplingRules",
            "xray:GetSamplingTargets",
            "xray:GetSamplingStatisticSummaries"
        ],
        "Resource": [
            "*"
        ]
    },

task-definitions/task-definition.json: (HINWEIS: Diese Datei existiert möglicherweise im Repository Ihrer Anwendung und hat einen anderen Namen)

[
  {
    ...
    "environment": [
      {
          "name": "AWS_XRAY_DAEMON_ADDRESS",
          "value": "fq-${ENVIRONMENT}-xray:2000"
      }
    ],
    ...
    "links": [
      "fq-${ENVIRONMENT}-xray"
    ]
    ...
  },
  {
    "name": "fq-${ENVIRONMENT}-xray",
    "essential": true,
    "image": "${AWS_ACCOUNT}.dkr.ecr.us-west-2.amazonaws.com/xray:latest",
    "cpu": 32,
    "memoryReservation": 256,
    "portMappings" : [
      {
        "hostPort": 0,
        "containerPort": 2000,
        "protocol": "udp"
      }
    ],
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/fq/${ENVIRONMENT}/${SERVICE_NAME}/instance/xray",
        "awslogs-region": "${REGION}",
        "awslogs-stream-prefix": "xray"
      }
    }
  }
]

Probenentnahme

Da die Kosten von der Anzahl der API-Aufrufe des Segments abhängen, wollten wir auch die Möglichkeit haben, nur die Routen zu überwachen, die wir benötigen, und die Möglichkeit, X-Ray schnell zu den Routen hinzuzufügen oder daraus zu entfernen, falls wir jemals eine Änderung vornehmen müssen. Dies führte dazu, dass wir die X-Ray-Route als Code im Server konfigurierten, anstatt sie einzurichten. über Terraform und AWS Console.

Es lebt!

Als die Daten eingingen, konnten wir uns das Produktions-X-Ray-Dashboard ansehen, um die Codeabschnitte zu identifizieren, die verbessert werden könnten.

Zukünftige Erkenntnisse

Da wir als datengetriebenes Unternehmen weiter wachsen, ermöglicht die Überwachung der Daten für unsere Anwendung dem Team, sich auf die richtigen Bereiche des Codes zu konzentrieren. Monitoring-Dienste erfordern in der Regel auch eine schnelle Implementierung, wobei der Schwerpunkt auf Skalierbarkeit liegt. Überwachungstools von Drittanbietern wie AWS X-Ray, die sofort einsatzbereit und einfach zu implementieren sind, sind eine hervorragende Antwort auf diese Herausforderungen.