Ik ben bezig met certificering voor AZ-204 van Azure, waarbij ik de lessen/uitleg/instructies van Azure zelf volg via deze flow: link. Ik was bij blok 4 begonnen: link, daarna heb ik blok 1 uitgevoerd: link. Ik ga nu maar de normale volgorde aanhouden en kijk dan wel even welke items ik op de specs kan aanvinken als "afgerond".
Tijd voor blok 2: "Connect your services together": link.
We beginnen met Choose a messaging model in Azure to loosely connect your services: link.
Vroeger had je één grote bak code, maar om je systemen onderhoudbaar te maken en onderdelen te kunnen upgraden/vervangen zijn we met zijn allen meer richting de microservices gegaan. Maar dan moet er wel (meer) onderlinge communicatie uitgevoerd worden, waar problemen op kunnen treden. En dan?
Azure biedt diensten om die communicatie betrouwbaarder te maken. Storage queue, Event Hubs, Event Grid en Service Bus. We gaan ons hierin verdiepen. De voorbeeld-case die gegeven wordt is dat je een website hebt waar artiesten hun muziek kunnen uploaden. Andere muzikanten kunnen dit beluisteren en hun reactie/commentaar geven. Nu blijkt dat bij hoge belasting uploads mislukken en dat reacties niet toegevoegd worden.
Als je deze zaken gaat oplossen moet je eerst weten waar je het over hebt. Gaat het over berichten (messages) of over acties (events)?
Een "message" bevat de rauwe data, door een component aangemaakt en wat door een andere component gebruikt gaat worden. De verzender van de data verwacht dat de ontvangende partij hier een specifieke actie op uit gaat voeren.
Een "event" is een stuk lichter qua uitvoeren. Het bevat niet de data, soms wel een verwijzing naar de data en wordt vaak als een soort "broadcast" gebruikt. Je hebt de publishers en de subscribers. De Azure Event Grid of Azure Event Hubs worden vaak gebruikt waar de consumers kunnen aangeven dat ze notificaties van bepaalde events willen ontvangen.
Een event geeft aan dat er iets gebeurd is, dit kan naar 0, 1, 2, ... tig consumers gestuurd worden, de verzendende partij heeft geen aanname over wat de ontvangende partij met de melding gaat doen.
We gaan kijken naar de upload van muziek. Mogelijke opties hiervoor zijn Azure Queue Storage en Azure Service Bus. De Queue Storage (link) kan heel veel berichten bevatten en kan veilig benaderd worden via een REST interface. Service Bus (link) is een "message broker systeem" voor enterprise applicaties. Deze apps gebruiken vaak meerdere communicatieprotocollen, verschillende data-contracten, hogere security eisen en kunnen zowel cloud als "on-premise" services bevatten.
De Azure Service Bus heeft ook Topics. Hier kunnen meerdere diensten zich op aanmelden (subscriben). Voorbeeld hierbij is dat de gebruiker naar een lied luistert. De mobiele app stuurt een bericht naar het "listened" topic. Dit topic kan 2 subscribers hebben, een "updateuserlistenhistory" en een "updateartistsfanlist". Zo kan 1 actie: "liedje beluisterd" zorgen dat 2 acties uitgevoerd worden: bij de gebruiker wordt het lied geregistreerd (en kan hij/zij later terug zien welke nummers beluisterd zijn) en de artiest krijgt een update dat het lied beluisterd is.
Garantie van aflevering
Hier zijn een paar verschillende methoden om het aan te pakken:
- "at least once" delivery: elk bericht wordt minimaal naar 1 ontvangende component van de queue gestuurd. Aandachtspunt hierbij is dat als het verwerken lang duurt er een time-out op kan treden en een ander proces het bericht ook oppakt. Het kan dus 2x verwerkt worden. Hier moet je wel rekening mee houden (ik denk hier aan het 2x afschrijven of bijboeken van geld op een bankrekening...).
- "at most once" delivery: het is niet gegarandeerd dat je bericht verwerkt wordt. Wel wordt gegarandeerd dat je bericht maximaal 1x verwerkt wordt. Dit wordt ook wel automatic duplicate detection genoemd.
- "first in first out" delivery: soms is het noodzakelijk dat berichten in dezelfde volgorde verwerkt worden. Dan moet je een FIFO queue gebruiken.
Transacties
Sommige zaken moeten in een transactie uitgevoerd worden. Als een klant iets koopt en er: - geld van de rekening afgeboekt moet worden, - de goederen moeten uitgeleverd worden, - er moet een bevestiging naar de klant gestuurd worden, - de order en uitgifte moeten in de database opgeslagen worden, voor al deze zaken geldt óf alles moet lukken óf alles moet mislukken. Als er geen geld afgeboekt kan worden, dan mogen de goederen niet geleverd worden.
Server Bus Topics:
- gebruik deze dienst als meerdere ontvangers wat met een bericht moeten doen.
Server Bus Queue:
- als je een at-most-once aflevertype nodig hebt.
- als je een FIFO aflevertype nodig hebt.
- als je messages moet groeperen om er een transactie van te maken.
- als je messages wilt ontvangen zonder continu de queue te hoeven "pollen".
- als je de toegang tot de queues op basis van rollen wilt inregelen.
- als je messages groter dan 64 KB zijn, maar kleiner dan 256 KB.
- als je queue niet groter dan 80 GB wordt.
- als je batches van messages wilt kunnen publiceren en consumeren.
Queue Storage:
- als je een audit-trail nodig hebt van alle berichten die in de queue gestaan hebben.
- als de verwachtte grootte van de queue groter dan 80 GB gaat worden.
- als je de voortgang van het verwerken van een bericht in de queue wilt bekijken.
We kijken naar het andere punt, de notificatie(s). Een artiest upload muziek en er moet ergens geregistreerd worden dat dit gedaan is (zodat mensen die dit type muziek volgen of de artiest zelf dit zien).
De Azure Event Grid (link) is een event routing service die draait op Service Fabric (link). Een event uit een blob-storage (bv. een upload - link) of Azure Media Services (link) wordt door event grid doorgestuurd naar Azure Functions (link) of webhook(s). De onderdelen die hierbij van toepassing zijn:
Events: wat is er gebeurd? Een stuk JSON-data, maximaal 64 KB, bestaande uit topic, subject, id, eventType, eventTime, data, dataVersion, metadataVersion.
Event sources: waar is het gebeurd? Is er wat in een blob-storage gedaan: Azure Storage. Is er een IoT event: IoT Hub.
Topics: het "endpoint" waar de data van het event heen gestuurd wordt. Zo zul je een topic hebben voor het bijwerken van profieldata van een gebruiker, maar wil je voor het afhandelen van een aangemaakte order een ander "endpoint" willen hebben. Je hebt system topics (Azure eigen zaken waar je op kunt subscriben) en custom topics.
Event subscriptions: hiermee kun je aangeven welke events je wilt ontvangen. Je kunt hier ook nog filteren op basis van type of onderwerp of je dit event wel of niet wilt verwerken.
Event handlers: een applicatie of resource die reageert op events. Zo kan een Azure Function getriggerd worden als er een nieuw lied in de blob-storage geüpload wordt. Je hoeft niet te pollen!
Bijna elke bron in Azure kan als bron dienen om events te activeren. De "handlers" zijn Azure Functions, webhooks, Azure Logic Apps en Microsoft Power Automate.
De punten om Event Grid te gebruiken:
- het is makkelijk om bronnen aan "subscribers" te koppelen.
- met de filtering kunnen subscribers precies bepalen welke topics ze wel en niet willen verwerken.
- je kunt je aanmelden voor een ongelimiteerd aantal topics.
- "event delivery" wordt 24 uur per subscription geprobeerd.
- je betaalt alleen voor de events die verzonden zijn.
Als je met heel veel data moet gaan werken, dan is Azure Event Hubs (link) een alternatief. De data van honderden sensoren in een vliegtuig verwerken, dat werk.
Als event hubs data ontvangen, wordt dit in partities onderverdeeld. Zo wordt data gebufferd en verdwijnt het niet als het systeem "het even druk heeft". De standaard tijd tot verlopen is 24 uur. Elke event hub heeft minimaal 2 partities en elke partitie heeft eigen subscribers.
Event hubs kunnen je data direct doorsturen naar Azure Data Lake (link) of Blob-storage zodat het meteen opgeslagen is.
Alle publishers zijn geauthenticeerd met een token. Geen bull-shit data door een frauduleuze actie. Door het gebruik van het token kunnen externe apparaten en mobiele apps data registreren.
De punten om Event Hubs te gebruiken:
- als je een groot aantal publishers moet ondersteunen op basis van authenticatie.
- als je een stream van events naar Data Lake of Blob-storage moet doorsturen.
- als je data moet aggregeren of analytics op je event stream moet uitvoeren.
- als je betrouwbaar berichtenverkeer en opslag van data nodig hebt.
We gaan door met Implement message-based communication workflows with Azure Service Bus: link.
De voorbeeld-case is een fietsverhuur, orders gaan via een SQL database en in tijden van drukte treden er deadlocks op.
Azure Service Bus kan berichten in 3 verschillende manieren versturen, queue, topic en relay. In een queue komt een bericht binnen en die wordt door 1 proces verwerkt. Wil je dat het naar meerdere ontvangers gaat, dan gebruik je de topics (wordt niet ondersteund in de Basic versie). Een relay is een vreemde eend in de bijt, dit is voor synchrone communicatie tussen 2 partijen waar bijvoorbeeld een firewall tussen zit.
De service bus heeft een aantal voordelen:
- ondersteuning van grotere berichten, 256 KB (standard) of 1 MB (premium) ten opzichte van de 64 KB die je anders hebt.
- ondersteuning van at-most-once en at-least-once aflevering.
- garantie van FIFO principe.
- berichten kunnen gegroepeerd worden in een transactie
- toegang/beheer op basis van rollen
- ontvangende componenten hoeven niet continu te "pollen"
Voordelen van storage queues:
- geen limiet op grootte van de queue (ten opzichte van de 80 GB limiet van de service bus)
- houdt een log bij van alle berichten
We gaan de voorbeeld-case in duiken. We maken een Service Bus aan, queue "salesmessages", topic "salesperformancemessages" met daar 2 subscriptions, een "Americas" en een "EuropeAndAsia". Om in C# met je servicebus te werken kun je het nuget-package Microsoft.Azure.ServiceBus gebruiken. Om vervolgens connectie te maken heb je 2 gegevens nodig, namelijk de URL waarop de bus te bereiken is: jouwnaam.servicebus.windows.net en de toegangssleutel. De URL is dus zonder de naam van de queue, want die gebruik je bij het aanmaken van het QueueClient-object.
We zien code die je bij gebruik als het goed is zelf zult aanmaken:
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Azure.ServiceBus;
var queueClient = new QueueClient(TextAppConnectionString, "PrivateMessageQueue");
// verzenden
string message = "Sure would like a large pepperoni!";
var encodedMessage = new Message(Encoding.UTF8.GetBytes(message));
await queueClient.SendAsync(encodedMessage);
// ontvangen
queueClient.RegisterMessageHandler(MessageHandler, messageHandlerOptions);
await queueClient.CompleteAsync(message.SystemProperties.LockToken);
We starten met een project wat je op Github kunt vinden: link.
Het opvragen van de connection-string kan met dit commando:
az servicebus namespace authorization-rule keys list \
--resource-group naam-resource-group \
--name RootManageSharedAccessKey \
--query primaryConnectionString \
--output tsv \
--namespace-name jouw-ingevoerde-namespace
In de code die we gaan runnen krijg ik een foutmelding op await queueClient.CloseAsync();
Deze bestaat niet in ons voorbeeld (maar dat klopt ook wel, want eerder maken we hier een await using var client = new ServiceBusClient(ServiceBusConnectionString); aan.
Ik heb deze regel in commentaar gezet en het werk, volgens mij is dit een correcte fix.
Met onderstaand statement kun je zien hoeveel items in de queue staan:
az servicebus queue show \
--resource-group naam-resource-group \
--name salesmessages \
--query messageCount \
--namespace-name jouw-ingevoerde-namespace
We krijgen daarna het voorbeeld om data te ontvangen. Maar de losse delen en het totaal-overzicht komt niet helemaal overeen. En als het het met dotnet run -p naam wil runnen krijg ik foutmeldingen. Uiteindelijk met onderstaande inhoud kreeg ik het werkend:
using System;
using System.Text;
using System.Threading.Tasks;
using Azure.Messaging.ServiceBus;namespace privatemessagereceiver
{
class Program
{const string ServiceBusConnectionString = "mijn-connectiestring";
const string QueueName = "salesmessages";static void Main(string[] args)
{ReceiveSalesMessageAsync().GetAwaiter().GetResult();
}static async Task ReceiveSalesMessageAsync()
{Console.WriteLine("======================================================");
Console.WriteLine("Press ENTER key to exit after receiving all the messages.");
Console.WriteLine("======================================================");
var client = new ServiceBusClient(ServiceBusConnectionString);var processorOptions = new ServiceBusProcessorOptions
{
MaxConcurrentCalls = 1,
AutoCompleteMessages = false
};await using ServiceBusProcessor processor = client.CreateProcessor(QueueName, processorOptions);
//ServiceBusProcessor processor = client.CreateProcessor(QueueName, processorOptions);
processor.ProcessMessageAsync += MessageHandler;
//processor.ProcessMessagesAsync += MessageHandler;
processor.ProcessErrorAsync += ErrorHandler;await processor.StartProcessingAsync();
Console.Read();
//await processor.CloseAsync();
await processor.DisposeAsync();
await client.DisposeAsync();}
static async Task MessageHandler(ProcessMessageEventArgs args)
{
Console.WriteLine($"Received message: SequenceNumber:{args.Message.SequenceNumber} Body:{args.Message.Body}");
await args.CompleteMessageAsync(args.Message);
}static Task ErrorHandler(ProcessErrorEventArgs args)
{
Console.WriteLine($"Message handler encountered an exception {args.Exception}.");
Console.WriteLine("Exception context for troubleshooting:");
Console.WriteLine($"- Endpoint: {args.FullyQualifiedNamespace}");
Console.WriteLine($"- Entity Path: {args.EntityPath}");
Console.WriteLine($"- Executing Action: {args.ErrorSource}");
return Task.CompletedTask;
}
}
}
Het volgende voorbeeld werkt met "topics". Het gaat hier over een applicatie voor pizza's. En dan om het annuleren van een pizza. De bestel-actie kan wel naar 1 loket, maar deze melding moet zowel naar de keuken (stop met bakken!) als naar de koeriersdienst (pizza niet mee geven!). We gaan zo in C# gebruik maken van TopicClient in plaats van QueueClient.
We kunnen op het topic met onze subscription filters instellen. Zo kun je het CancelTopic in de gaten houden, maar filteren op "vestiging=Leeuwarden", zodat je alleen je eigen annuleringen ziet.
Hierin zijn 3 types te onderscheiden:
- boolean filter: dit is een harde TrueFilter: ik wil alles ontvangen, of een FalseFilter: ik wil niets ontvangen.
- SQL filters: de standaard WHERE criteria waarmee je aangeeft waar op gematcht moet worden.
- Correlation filters: er wordt op basis van eigenschappen van het filter en de eigenschappen van het bericht gekeken of het overeenkomt, zo ja, dan heb je een match.
Weer even een overzicht wat de meest gebruikte code bij een TopicClient is:
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Azure.ServiceBus;
var topicClient = new TopicClient(TextAppConnectionString, "GroupMessageTopic");
string message = "Cancel! I can't believe you use canned mushrooms!";
var encodedMessage = new Message(Encoding.UTF8.GetBytes(message));
await topicClient.SendAsync(encodedMessage);
var subscriptionClient = new SubscriptionClient(ServiceBusConnectionString, "GroupMessageTopic", "NorthAmerica");
subscriptionClient.RegisterMessageHandler(MessageHandler, messageHandlerOptions);
await subscriptionClient.CompleteAsync(message.SystemProperties.LockToken);
Als je wilt zien hoeveel berichten in het topic staan te wachten (per subscription), dan is dit het commando:
az servicebus topic subscription show \
--resource-group naam-resource-groep \
--namespace-name jouw-namespace-naam \
--topic-name salesperformancemessages \
--name Americas \
--query messageCount
Na deze oefeningen gaan we door met het volgende blok, Communicate between applications with Azure Queue storage: link.
We gaan een storage account aanmaken. Dat kun je met onderstaande commando uitvoeren:
az storage account create --name [unique-name] -g naam-resource-groep --kind StorageV2 --sku Standard_LRS -l westeurope
Als je vervolgens acties met de queue wilt gaan doen, heb je 3 gegevens nodig: de naam van het storage-account ([unique-name] in bovenstaande), naam van de queue en het autorisatie-token.
Er zijn verschillende autorisatie-methodes, zo kun je via de Azure Active Directory toegang krijgen (role-based dus), Shared Key (elk storage account heeft 2 van deze sleutels) maar het is wel gevaarlijk: je hebt hiermee root-toegang en je hebt nog de shared access signature. Het is een URI die je toegang geeft tot bepaalde delen. Je kunt de toegang tot bepaalde onderdelen inperken, je kunt rechten instellen en je kunt ook een verloopdatum instellen: daarna heb je met het token geen toegang meer.
De connectiestring die je gaat gebruiken ziet er ongeveer zo uit:
"DefaultEndpointsProtocol=https;AccountName=<your storage account name>;AccountKey=<your key>;EndpointSuffix=core.windows.net"
Je kunt deze gegevens opvragen via de portal, het storage account en dan onderdeel security + networking, access keys. Of je voert onderstaand commando uit:
az storage account show-connection-string -g <resource group name> -n <storage account name> --output tsv
En ja, ook hier heb je een nuget-package voor: Azure.Storage.Queues (link). Op basis van connectiestring en de naam van de queue heb je toegang.
We gaan met een case bezig, het project kun je op Github vinden: link.
Eerst gaan we de connectiestring in een omgevingsvariabele zetten:
export STORAGE_CONNECTION_STRING=`az storage account show-connection-string -g naam-resource-group -n naam-storage-account --output tsv`
// controle:
echo $STORAGE_CONNECTION_STRING
Er wordt uitgelegd dat je in een queue ook binaire data kunt versturen. Maar dan moet je het wel eerst Base-64 encoden. Let op dat je limiet per stuk van 64 KB voor een Base-64 bericht op 48 KB staat!). De queue zelf kan wel 500 TB groot worden.
Een voorbeeld hoe je data ontvangt en vervolgens uit de queue verwijdert:
Response<QueueMessage> response = await queueClient.ReceiveMessageAsync();
QueueMessage message = response.Value;
NewsArticle article = message.Body.ToObjectFromJson<NewsArticle>();
await queueClient.DeleteMessageAsync(message.MessageId, message.PopReceipt);
We gaan data in een queue zetten, maar ik loop hier tegen problemen aan, ik krijg de melding dat de app geen connectie kan/mag maken met de queue die ik aangemaakt heb. Blijkt uiteindelijk dat het sandbox account van mslearn niet helemaal lekker is, want er is geen subscription (meer). Je moet dus wachten tot die learn-sandbox verlopen is (4 uur) en dan wordt een nieuwe aangemaakt.
Nadat de sandbox verlopen is kan ik met een nieuwe aan de slag. Hier geen foutmeldingen over abonnementen. Maar het toevoegen en ophalen van data uit de queue werkt nog steeds niet. Maar ik volg wel exact het voorbeeld wat Microsoft aanlevert. Ik geloof het dus wel, mocht ik nog ergens tijd hebben dan zou ik dit zelf nog eens kunnen gaan testen.
We gaan door met het volgende blok, Enable reliable messaging for Big Data applications using Azure Event Hubs: link.
Het voorbeeld wat genoemd wordt is dat je bij een credit-card bedrijf werkt. Je zit in de afdeling waar real-time controles uitgevoerd worden om fraude te detecteren en voorkomen. Dit moet responsive blijven, anders krijgen klanten en webshops problemen.
Hierbij gaat Event Hubs ingezet worden. Events, pakketjes, kunnen maximaal 1 MB groot zijn. De publishers (dus die events inschieten) zijn partijen die HTTPS ondersteunen of AMQP (Advanced Message Queuing Protocol) 1.0. Als er vaak data verzonden moet worden heeft AMQP de voorkeur. Daarbij geldt wel een langere opstarttijd, omdat er een 2-richting verkeer socket opgestart wordt en Transport Level Security of SSL/TLS opgestart moeten worden. Voor minder regelmatige events heeft HTTPS de voorkeur. Daar hoeft ook geen sessie voor opgestart te worden.
Notitie van de site: Kafka gebaseerde clients die Apache Kafka 1.0 draaien en nieuwer kunnen ook als Event Hubs publishers optreden.
Een consumer groep is een specifieke view op data in een Event Hub. Door meerdere hiervan aan te maken kunnen apps die aangemeld zijn hun eigen data zien. In veel gevallen is die scheiding niet nodig en is 1 view voldoende.
Je hebt 3 verschillende prijsgroepen, Basic, Standard en Dedicated. Als je via de CLI een Hub aanmaakt en geen aanpassingen doet, dan wordt Standaard gekozen: 20 consumer groups en 1.000 brokered connecties.
Als je een Event Hub maakt, dan moet je eerst de namespace aanmaken, daarna de hub zelf. In de namespace stel je de zaken in, zoals de prijsgroep, performance. Als je 2 verkoophubs gaat maken, zou je kunnen kiezen voor 1 hub in een "normale drukte namespace" en 1 hub in een "black friday drukte namespace". De namespace volgt altijd deze naamgeving: namespace.servicebus.windows.net
En je kunt in de namespace nog instellen dat Kafka actief is, hierdoor kunnen Kafka clients als publishers acteren. Je kunt een namespace Zone-redundant maken. Hierdoor wordt je data in verschillende data-centers geregistreerd, valt ergens de stroom uit, dan ligt je applicatie niet plat. En je kunt nog auto-inflate en auto-inflate-maximum instellen. Hiermee kun je het systeem op laten schalen naar dit maximum.
Met het commando az eventhubs namespace kun je vervolgens met create een namespace aanmaken. Met authorization-rule krijg je de connectionstring. Als je een hub aanmaakt is de naam mimimaal 1 en maximaal 50 karakters lang. Deze moet beginnen (en eindigen) met en letter of een cijfer. In de naam mag je naast cijfers en letters gebruik maken van een underscore, punten en verbindingsstreepjes.
Je maakt partities aan, tussen de 2 en 32. De standaard is 4. Dit aantal is later niet aan te passen. Je stelt dit in op het verwachte aantal gelijktijdige (concurrent) gebruikers.
Message retention, hiermee geef je aan hoe lang berichten bewaard blijven. Dit is tussen de 1 en 7 dagen, standaard is 7.
Met az eventhubs eventhub kun je eventhub acties uitvoeren. Met create maak je een hub aan, met show krijg je details te zien.
We gaan vervolgens een namespace en eventhub aanmaken. Hierbij de stappen:
// default waarden instellen
az configure --defaults group=resource-groep-naam location=westeurope
// deze neem ik hier even mee, omdat een willekeurig getal nog wel eens handig kan zijn:
NS_NAME=ehubns-$RANDOM
az eventhubs namespace create --name $NS_NAME
az eventhubs namespace authorization-rule keys list \
--name RootManageSharedAccessKey \
--namespace-name $NS_NAME
// registreer deze punten uit bovenstaande output// primaryConnectionString
// primaryKeyHUB_NAME=hubname-$RANDOM
az eventhubs eventhub create --name $HUB_NAME --namespace-name $NS_NAME
az eventhubs eventhub show --namespace-name $NS_NAME --name $HUB_NAME
Als je berichten naar een HUB wilt sturen, dan heb je daarvoor onderstaande gegevens nodig:
- Event hub namespace name
- Event hub name
- Shared access policy name
- Primary shared access key
Als je berichten van een HUB wilt ontvangen, dan heb je daarvoor onderstaande gegevens nodig:
- Event hub namespace name
- Event hub name
- Shared access policy name
- Primary shared access key
- Storage account name
- Storage account connection string
- Storage account container name
In het voorbeeld gaan we door, een ontvangende partij slaat de berichten op in Blob-storage. We gaan dus een Storage Account aanmaken.
STORAGE_NAME=storagename$RANDOM
az storage account create --name $STORAGE_NAME --sku Standard_RAGRS --encryption-service blob
// keys opvragen:
az storage account keys list --account-name $STORAGE_NAME
// connectiestring:
az storage account show-connection-string -n $STORAGE_NAME
// container aanmaken:
az storage container create --name messages --connection-string "<connection string here>"
We beginnen met een project van Github, hier te downloaden: link. Dit is een java project, we gaan dit met Maven builden/runnen:
mvn clean package -DskipTests
Het invullen van de velden en uitvoeren van sender en ontvanger werkt. We gaan door.
Het (tijdelijk) uitvallen van een hub kan komen door onderhoud, upgrades, herstarten.
Dit zijn de symptomen:
- je ziet in de grafiek een dip bij inkomende berichten/requests
- het log-bestand begint zich te vullen met foutmeldingen
- er zijn disconnects van de applicaties met de service (voor enkele seconden)
- verzoeken worden tijdelijk "gethrotteld"
Client SDK's zijn gebouwd om dit te ondervangen. Je kunt dit testen door in de portal je hub even uit te zetten.
Handige zaken om te bekijken:
Throttled Requests: je kunt zien hoeveel requests "afgeknepen" worden omdat er teveel doorvoer van data is.
ActiveConnections: het aantal verbindingen met een namespace of event hub.
Incoming/Outgoing Bytes: het aantal bytes wat verzonden wordt naar of vanuit de event hub over een bepaalde periode.
Tijd voor het laatste blok, React to state changes in your Azure services by using Event Grid: link.
De voorbeeld-case in dit blok is dat je in een ziekenhuis werkt en je een aantal Virtuele Machines onder je hoede hebt. En zodra daar iets in de configuratie aangepast wordt wil je een e-mail ontvangen met informatie. Een prima case voor een event grid.
Omdat Event Grid ingebakken zit in Azure hoef je er weinig voor te doen. De pluspunten zijn:
- Simpel, wijs aan en klik op een item in Azure portal om je events van resources te verzamelen.
- Het kan events filteren waardoor handlers alleen events ontvangen die echt belangrijk zijn voor die handler.
- Het ondersteunt meerdere abonnees/subscribers. Koppel meerdere handlers aan 1 event van 1 source.
- Het is betrouwbaar. Er wordt 24 uur geprobeerd om je bericht af te leveren.
- Doorvoer is hoog. Er kunnen miljoenen per seconde verwerkt worden.
- Het heeft ingebouwde events. Hierdoor kun je snel beginnen en hoef je niet heel diep in de werking te duiken.
- Het ondersteunt "custom events". Gebruik Event Grid om betrouwbaar events aan jouw eigen componenten aan te leveren.
Met een webhook handler kun je zaken buiten Azure aannroepen. Binnen Azure kun je gebruik maken van deze handlers: Azure Functions, Azure Logic Apps, Azure Automation, Azure Event Hubs, Azure Service Bus.
We gaan vervolgens een Virtual Machine aanmaken en een Logic App. In de Logic App gaan we via Sjablonen naar Lege logische app. We zoeken hier op Event Grid en kiezen dan voor de "Wanneer een resourcegebeurtenis optreedt (eronder staat Event Grid)". Bij Bron kies je voor "Microsoft.Resources.ResourceGroup". We voegen hier 3 event types aan toe: Microsoft.Resources.ResouceActionSuccess, Microsoft.Resources.ResouceDeleteSuccess, Microsoft.Resources.ResouceWriteSuccess.
We zien vervolgens een voorbeeld hoe conditions gebruikt worden, bijvoorbeeld om bij een "lijst van bestanden" de .PDF-bestanden eruit te selecteren.
Daar kun je een aantal acties op uitvoeren, bijvoorbeeld Azure Service Bus, SQL Server, Office 365 Outlook, Salesforce. En je kunt switchen in weergave, je ziet het ontwerp of je ziet de achterliggende JSON-code.
We voegen een conditie toe. Dit is op basis van "AND" en vul bij de Expression-tab dit in: triggerBody()?['data']['operationName']
Bij de verwachte waarde kiezen we voor Microsoft.Compute/virtualMachines/write
Bij de TRUE voeg je een "Send an email (V2)" toe. Hiermee kun je een mail laten sturen als er wat aangepast wordt. We gaan vervolgens van de VM de schijfgrootte aanpassen. Dat duurt ongeveer 10 minuten, daarna nog 2 of 3 minuten wachten, maar dan krijg ik inderdaad een e-mail met de gegevens. Dit is goed gegaan.