CloudWatch Alarme über Slack empfangen

Ob CPU-Auslastung einer EC2-Instanzen, Fehler beim Ausführen einer Lambda-Funktion oder verfügbarer Speicherplatz einer RDS-Instanz mit Amazon CloudWatch lassen sich Ressourcen bei AWS überwachen. Dafür werden zwei Komponenten benötigt:

  • Metriken: Eine Metrik ist ein Sammeltopf für Messwerte, die von den AWS Services automatisch befüllt werden.
  • Alarme: Ein Alarm überprüft in regelmäßigen Abständen ob sich die Messwerte einer Metrik noch innerhalb von definierten Grenzen bewegt.

Eine Übersicht über alle verfügbaren Metriken findet sich unter Metriken und Dimensionen-Referenz von Amazon CloudWatch.

Wann immer ein CloudWatch Alarm feststellt, dass sich eine Metrik außerhalb der definierten Grenzen bewegt, können automatisch folgende Aktionen ausgeführt werden:

Beispielsweise lässt sich ein CloudWatch Alarm so konfigurieren, dass bei einer CPU-Auslastung von über 80% über SNS eine E-Mail an den Verteiler des eigenen DevOps-Teams gesendet wird. Allerdings führen Benachrichtigungen von CloudWatch Alarmen per E-Mail schnell zu einem überquellenden Postfach. Außerdem entsteht mit jeder E-Mail an den Verteiler des eigenen DevOps-Teams auch Abstimmungsbedarf: „Wer kümmert sich um das Problem?“.

Bei tecRacer Consulting verwenden wir Slack um über Standorte (Hannover, Duisburg, Frankfurt und München) hinweg die Kommunikation zwischen allen Cloud Consultants sicherzustellen. Was liegt da näher als auch CloudWatch Alarme über Slack zu empfangen?

Im Jahr 2016 haben Michael und ich an der Serverless Chatbot Competition teilgenommen und in diesem Rahmen einen Chatbot entwickelt. Mit marbot lassen sich CloudWatch Alarme über Slack empfangen. Dabei versucht der Chatbot das DevOps-Team möglichst wenig zu stören. Eingehende Alarme werden über eine Eskalationsstrategie erst einem einzelnen Teammitglied, bei Bedarf einem weiteren Teammitglied und schließlich erst dem ganzen Team zugestellt.

Neben CloudWatch Alarmen integriert sich marbot mit einer Vielzahl von anderen Quellen, über die AWS-Ressourcen überwacht werden können.

Zusätzlich können per HTTP/HTTPS oder E-Mail beliebige Alarme an marbot gesendet werden.

Unser Chatbot kann damit als unkompliziertes und agiles Incident Management Tool verwendet werden. Fügen Sie marbot zu Ihrem Slack Workspace hinzu um die 14-tägige und kostenlose Probezeit zu starten.

Default DNS-Server in AWS VPCs

AWS reserviert in jedem Subnetz die dritte IP (bei einer 24er Maske also die x.x.x.2) für Ihren DNS-Server. Sobald man mit Network ACLs arbeitet, geht man daher davon aus, dass die DNS-Queries innerhalb des Subnetzes der Instanz stattfinden. Allerdings findet sich versteckt in den Dokumentationen der Hinweis, dass es sich bei „Subnetz+2“ nur um eine Reservierung handelt, der DNS aber eigentlich auf „VPC+2“ liegt – selbst wenn dort überhaupt kein Subnetz konfiguriert ist.

Dieses Problem kann man elegant umgehen, indem der DNS Endpunkt auf dem lokalen Interface genutzt wird. Während die Existenz des Metadata-Services auf der 169.254.169.254 weithin bekannt ist, ist nämlich der DNS auf 169.254.169.253 eher unbekannt.

Bei Security Groups findet sich eine weitere Besonderheit im Zusammenhang mit DNS: Sofern man ausgehende Regeln explizit konfiguriert hat, ist der default DNS-Server implizit auch freigegeben – selbst wenn udp/53 nicht in den erlaubten Regeln vorhanden ist. Ein externer DNS Server, der z.B. im on-Premise Netzwerk steht, braucht allerdings eine explizite Freigabe.

 

Anpassen von Konfigurationsdateien mit Ausgabewerten von CloudFormation Stacks

Bei der Migration von Anwendungen auf AWS müssen auch die Konfigurationsdateien der Anwendungen angepasst werden.  Auch dabei gilt der Grundsatz „Automatisiere alles“. Doch wie kommen die Daten aus der neu auf AWS provisionierten Infrastruktur auf die Server? Hierzu ein paar Tipps zu CloudFormation und Anpassung von Konfigurationsdateien mit Shell Skripten. (mehr …)

50 Mitarbeiter Zertifizierungen für AWS

 

Seit vielen Jahren haben darauf hin gearbeitet … jetzt die Marke von 50 Mitarbeiter Zertifizierungen für die Amazon Web Services Cloud erreicht.

Insider wissen, wie schwer diese Zertifizierungen sind, so dass sich unsere Kunden darauf verlassen können, das unsere Mitarbeiter richtig Ahnung davon haben …

Clouds – einfaches Management von CloudFormation Templates

Infrastruktur als Code ist eine (Heraus)Forderung von DevOps. Die Infrastrukturbeschreibungssprache von AWS heißt CloudFormation. Hat man sich erstmal eingearbeitet, greift man immer häufiger zum Texteditor statt zur Console, um AWS Ressourcen zu erstellen. Und eh man es sich versieht, hat man eine unüberschaubare Anzahl von Cloudformation Templates. Und dann steht man vor der Aufgabe, diese zu verwalten. Hier wollen wir ein paar Möglichkeiten dafür vorstellen.

(mehr …)