De hoeveelheid gegevens die wereldwijd wordt gegenereerd, groeit in een steeds hoger tempo. Er worden gegevens gegenereerd ter ondersteuning van een toenemend aantal use-cases, zoals IoT, advertenties, gaming, beveiligingsmonitoring, machine learning (ML) en meer. De groei van deze use-cases stimuleert zowel het volume als de snelheid van streaminggegevens en vereist dat bedrijven de gegevens in bijna realtime vastleggen, verwerken, transformeren, analyseren en in verschillende gegevensarchieven laden.
Amazon Kinesis-gegevens Firehose is de gemakkelijkste manier om op betrouwbare wijze streaminggegevens in datameren, datastores en analyseservices te laden. Naarmate het volume van de gegevens die u naar Kinesis Data Firehose streamt groeit, moet u inzichten krijgen en de gezondheid van uw gegevensopname, -transformatie en -levering bewaken.
In dit bericht bekijken we de mogelijkheden van het gebruik van Firehose-afleveringsstroomstatistieken en de Amazon Cloud Watch dashboard op uw Kinesis Data Firehose-console. Met deze mogelijkheden kunt u waarschuwingen maken wanneer, bijvoorbeeld, als de bestemming die u in Kinesis Data Firehose hebt geconfigureerd ontbrekende privileges, verkeerde configuraties of andere problemen heeft, Firehose dit voor u kan detecteren en het als een fout kan melden. Andere fouten die ook kunnen optreden, zijn als u geconfigureerd datatransformatie met Lambda en uw aanroep van de Lambda-functie is mislukt, of als u de Kinesis Firehose hebt bereikt quotumlimieten gekoppeld aan uw AWS-account. In deze gevallen kan de gegevenslevering van Kinesis Data Firehose naar zijn bestemming vertraging oplopen of mislukken. De CloudWatch-waarschuwingen die in dit bericht worden beschreven, moeten helpen dergelijke gevallen tijdig te identificeren.
Dit bericht behandelt ook de verschillende proactieve acties die u kunt ondernemen wanneer alarmen worden geactiveerd, zoals het indienen van een verzoek om quota te verhogen of exponentiële uitstel toe te voegen aan uw gegevensproducenten.
Door de leveringsstromen te monitoren en deze acties uit te voeren, zorgt u ervoor dat gegevens zonder onderbrekingen op uw bestemmingen worden afgeleverd, waardoor uw bedrijf bijna realtime inzicht krijgt.
Gegevensopname naar Kinesis Data Firehose bewaken
U kunt gegevens van uw gegevensproducenten aan Kinesis Data Firehose leveren via: Amazon Kinesis-gegevensstromen (zoals verderop in dit bericht wordt beschreven), met behulp van Kinesis-agent, of rechtstreeks met behulp van de Kinesis Data Firehose API-bewerkingen ZetRecord en ZetRecordBatch. Wanneer u Kinesis Data Streams als gegevensbron gebruikt, schaalt Kinesis Data Firehose automatisch zoals uw Kinesis Data Stream schaalt. Wanneer u de API-bewerkingen gebruikt voor directe opname, moet u de: quotumlimieten gekoppeld aan uw AWS-account om beperking van API-verzoeken te voorkomen. Afhankelijk van het gedrag van uw gegevensproducent, kan deze beperking ertoe leiden dat uw gegevensproducenten de bewerking opnieuw proberen, wat resulteert in een vertraging van de gegevenslevering aan uw bestemming. Deze beperking kan ook leiden tot gegevensverlies als uw gegevensproducenten geen mechanisme voor opnieuw proberen implementeren.
Om dieper inzicht te krijgen in het gebruik van Firehose-leveringsstromen, bieden we aanvullende CloudWatch-statistieken waarmee u quotalimieten kunt bewaken en proactief kunt schalen: ThrottledRecords, RecordsPerSecondLimit, BytesPerSecondLimit en PutRequestsPerSecondLimit. U kunt het CloudWatch-statistiekendashboard gebruiken (op de Monitoren tabblad op uw Kinesis Data Firehose-console) om eenvoudig het huidige gebruik en de quotalimieten te visualiseren.
Wanneer u gegevens rechtstreeks opneemt in uw leveringsstroom met behulp van PutRecord or PutRecordBatch, u moet de Throttle Records metriek. Deze statistiek vertegenwoordigt het aantal records dat daadwerkelijk is beperkt omdat de gegevensopname een van de leveringsstroomlimieten heeft overschreden. Kinesis Data Firehose berekent de beperkingspercentages tijdens de inname met een granulariteit van 1 seconde, maar de gegevensopnamestatistieken die we noemden, worden geaggregeerd en elke 5 minuten naar CloudWatch verzonden. Daarom kunt u binnen die periode van 5 minuten worden beperkt, zelfs als de gegevensopnamestatistieken niet aantonen dat u de limiet heeft bereikt.
Om waarschuwingen te ontvangen voordat uw gegevensproducenten daadwerkelijk worden beperkt, kunt u gebruik maken van aanvullende CloudWatch-statistieken om u te waarschuwen wanneer u op het punt staat een van de leveringsstroomlimieten te bereiken. U kunt dit bereiken door de CloudWatch-statistieken te gebruiken IncomingRecords, IncomingBytes en IncomingPutRequests. Om de limieten van deze metrieken te controleren, raadpleegt u: Amazon Kinesis Data Firehose-quotum.
U kunt de volgende opnamestatistieken en de bijbehorende limietstatistieken gebruiken om een CloudWatch-alarm te maken:
- RecordsPerSecondLimiet – Het maximale aantal records dat in een seconde kan worden opgenomen (
IncomingRecords) - BytesPerSecondLimiet – Het maximale gegevensvolume dat in een seconde kan worden opgenomen (
IncomingBytes) - PutRequestsPerSecondLimit – Het maximale aantal succesvolle
PutRecordenPutRecordBatchAPI-verzoeken die in een seconde kunnen worden uitgevoerd (IncomingPutRequests)
Als u een alarm wilt instellen dat u waarschuwt wanneer uw opnamesnelheid dicht bij een quotum komt, moet u zoeken naar een procentuele relatie tussen de opnamesnelheid en de bijbehorende limiet. Omdat Kinesis Data Firehose elke 5 minuten metrische gegevens naar CloudWatch verzendt, moet u uw metrische gegevens delen door de aggregatieperiode van 5 minuten, uitgedrukt in seconden (300). Als u bijvoorbeeld een waarschuwing wilt genereren wanneer het aantal binnenkomende records per seconde 80% van uw API-bewerkingsquotum overschrijdt, moet uw CloudWatch-alarm als volgt worden gedefinieerd:
Dit geeft u een manier om proactief te begrijpen hoe dicht uw opnamepercentages bij uw leveringsstroomlimieten liggen, en de flexibiliteit om de percentageniveaus aan te passen op basis van uw gebruiksscenario. Om een throttling bottleneck te voorkomen,
u moet de drie meetwaarden voor het opnamepercentage van de leveringsstroom die we hebben besproken, afzonderlijk controleren.
Definieer waarschuwingen met CloudWatch-alarmen
U kunt CloudWatch-alarmen handmatig definiëren via de AWS-beheerconsole of door te gebruiken AWS CloudFormatie. In dit bericht behandelen we beide methoden, te beginnen met de CloudFormation-sjabloon.
De volgende sjabloon maakt uw CloudWatch-alarmen, die u kunt bekijken en aanpassen aan uw behoeften.
Tijdens het proces voor het maken van de stapel geeft u de naam van de Firehose-leveringsstroom op die u wilt controleren, en het quotumpercentage waar u op de hoogte wilt worden gesteld wanneer deze wordt geschonden, zoals 80%. Nadat het maken van de stapel is gelukt, hebt u vier CloudWatch-alarmen gereed.
Voer de volgende stappen uit om uw CloudWatch-alarmen handmatig via de console te maken:
- Zoek uw leveringsstroom op de Kinesis Data Firehose-console.
- Op de Monitoren tabblad, kiest u het pictogram met meer opties van de metriek die u wilt controleren (in dit voorbeeld controleren we inkomende records per seconde).
- Kies in het optiemenu Bekijk in statistieken.
Op de CloudWatch-console ziet u een grafiek die uw huidige API-bewerkingen (blauwe lijn) en de quotalimiet (rode lijn) weergeeft.
- Om een alarm aan te maken, kies Wiskundige uitdrukking.
- kies Gemeen En kies Percentage.
- Voer voor de statistieknaam . in
Percentage of records per second quota. - We gebruiken de metrische uitdrukking
100*(e1/m2), die de formule 100*(BytesPerSecond/BytesPerSecondLimit) die eerder werd beschreven en geeft weer hoe dicht u in procenten bij uw maximum zit. - De uitdrukking van de metriek wijzigen
e1oppompen vanMETRICS("m1")/300naarm1/300.
U kunt ook het label van de Y-as wijzigen.
- Op de Grafiek opties tab, onder Linker Y-asvoor label, ga naar binnen
Percentage.
- Nu u de uitdrukking heeft die u voor het alarm wilt gebruiken, deselecteert u alle andere uitdrukkingen en metrieken op de pagina.
De enige geselecteerde expressie moet degene zijn die u zojuist hebt gemaakt. U zou nu het gewenste percentage moeten zien, zoals in de volgende schermafbeelding.
Een CloudWatch-alarm maken
U hebt nu een uitdrukking op uw . gemaakt IncomingRecords en RecordsPerSecond quota, die u als basis voor het alarm kunt gebruiken. Hiermee kunt u het tolerantieniveau configureren dat voor uw zakelijke gebruiksscenario vereist is.
- Kies het alarmpictogram naast je uitdrukking.
- In het Specificeer metrische gegevens en voorwaarden sectie, kiest u ervoor om een waarschuwing te ontvangen wanneer de alarmen de limiet van 75% overschrijden.
- In het Acties configureren sectie, specificeer hoe dit alarm moet worden doorgestuurd.
U kunt dit alarm doorsturen naar uw bewakingssystemen of naar een e-mailadres via een Amazon eenvoudige meldingsservice (Amazon SNS) onderwerp. Voor dit bericht maken we een nieuw SNS-onderwerp en schrijven we ons in [email protected] aan.
Acties die u kunt ondernemen bij het naderen van de limieten
Wanneer u uw limiet nadert, kunt u verschillende acties ondernemen, die we in deze sectie beschrijven.
Een verhoging van het servicequotum aanvragen
Een actie die u kunt ondernemen wanneer u een waarschuwing ziet, is om een verhoging van het quotum aan te vragen met behulp van de Amazon Kinesis Data Firehose Limits-formulier. De drie quota worden proportioneel geschaald, bijvoorbeeld als u het doorvoerquotum in US East (N. Virginia), US West (Oregon) of Europa (Ierland) verhoogt van 5 MiB/seconde naar 10 MiB/second, de andere twee quota verhoging van 2,000 verzoeken/seconde naar 4,000 verzoeken/seconde en van 500,000 records/seconde naar 1 miljoen records/seconde. Voor meer informatie over de servicequotalimieten per AWS-regio, zie: Amazon Kinesis Data Firehose-quotum.
Gebruik de PutRecordBatch-API
Als u de API-aanroep gebruikt PutRecord om gebeurtenissen aan een Firehose-gegevensstroom te leveren en u de limiet voor het verzoek/tweede quotum bereikt, kunt u overwegen de PutRecordBatch API-bewerking. PutRecordBatch schrijft meerdere datarecords in een leveringsstroom in één aanroep om een hogere doorvoer per producent te bereiken dan het schrijven van enkele records, en vermindert het aantal verzoeken per seconde naar uw leveringsstroom.
Implementeer exponentiële uitstel
Zoals we eerder vermeldden, kunt u zelfs wanneer u uw leveringsstroom controleert, nog steeds bursts in uw gegevensstroom hebben. Dit kan worden veroorzaakt door plotselinge pieken in het gebruik van uw systeem of externe gebeurtenissen zoals hoge handelsactiviteit op financiële markten. Om de producenten te beschermen tegen meerdere gesmoorde records, moet u een exponentiële backoff implementeren. Exponentiële backoff is een veelgebruikt algoritme dat u kunt gebruiken om de snelheid van het indienen van records bij Kinesis Data Firehose te verminderen wanneer deze wordt beperkt, zodat de producent langzaam kan reageren.
Probeer om de records met succes te verzenden.
Hieronder volgen de Kinesis Data Firehose API-reacties wanneer records worden beperkt:
- Als u de API-bewerking gebruikt
PutRecord, de geretourneerde fout van de service isServiceUnavailableExceptionmet HTTP-statuscode 500. - Als u gebruik maakt
PutRecordBatch, moet u de herhalenRequestResponsesarray en zoek naar individu PutRecordBatchResponseEntry Met Foutcode 500 en FoutberichtServiceUnavailableException. Controleer ook de waarde van MisluktPutCount in het antwoord, zelfs wanneer de API-aanroep slaagt.
In beide gevallen moet u exponentiële uitstel gebruiken en de bewerking opnieuw proberen. Voor meer informatie over het implementeren van exponentiële uitstel, zie: Foutpogingen en exponentiële uitstel in AWS.
Gebruik Kinesis Data Streams met Kinesis Data Firehose
Kinesis Data Streams is een enorm schaalbare en duurzame realtime datastreamingservice. Uw gegevensproducenten kunnen: gegevens rechtstreeks naar Kinesis Data Streams produceren, en u kunt Kinesis Data Firehose configureren om: verbruiken de gegevens van Kinesis Data Streams en bezorg het op je bestemming. Wanneer u Kinesis Data Streams gebruikt als bron voor de Firehose-leveringsstroom, zijn de eerder genoemde doorvoerlimieten niet van toepassing. U hoeft zich geen zorgen te maken over doorvoerlimieten, omdat Kinesis Data Firehose automatisch wordt geschaald om overeen te komen met het aantal shards dat uw Kinesis-gegevensstroom heeft.
Als u een Firehose-leveringsstroom als consument aan uw Kinesis-gegevensstroom koppelt en u meerdere consumententoepassingen hebt die gegevens uit uw Kinesis-gegevensstroom lezen, zoals AWS Lambda (Zie AWS Lambda gebruiken met Amazon Kinesis), zorg ervoor dat de totale consumentenapplicaties de totale leessnelheid van 2 MB van de shard. Dit kan ertoe leiden dat de Kinesis-gegevensstroom de leesdoorvoer van uw consumententoepassingen, inclusief Kinesis Data Firehose, vertraagt.
Als er meer leescapaciteit nodig is, kunnen sommige applicatiegebruikers zoals Lambda (zie AWS Lambda ondersteunt Kinesis Data Streams Enhanced Fan-Out en HTTP/2 voor snellere streaming) of aangepaste consumenten die zijn ontwikkeld met de Kinesis-consumentenbibliotheek kan speciale doorvoer van Kinesis Data Streams ondersteunen met behulp van: verbeterde fan-out, die momenteel niet wordt ondersteund door Kinesis Data Firehose. Deze functie biedt deze consumententoepassingen een geïsoleerde verbinding met de stream met een uitgaande doorvoer van 2 MB/seconde, zodat ze geen invloed hebben op andere consumententoepassingen die van de shards lezen.
Als u meer opnamecapaciteit nodig heeft, kunt u het aantal shards in de stream eenvoudig opschalen met behulp van de console of de UpdateShardCount-API.
Bewaak de gegevenslevering van Kinesis Data Firehose
In het geval van netwerktime-outs, ontbrekende privileges of verkeerde configuraties van uw leveringsstroom, zoals incorrecte bestemmingsconfiguratie or AWS Sleutelbeheerservice (AWS KMS) toets ARN, kan de gegevenslevering van uw gegevens van Kinesis Data Firehose naar zijn bestemming vertragen of mislukken. Er kunnen ook fouten optreden als u geconfigureerd datatransformatie met Lambda en uw aanroep van de Lambda-functie is mislukt.
Wanneer Kinesis Data Firehose leverings- of verwerkingsfouten tegenkomt, probeert het opnieuw totdat de geconfigureerde duur van nieuwe poging verloopt. Als de duur van de nieuwe poging eindigt en de gegevens niet succesvol zijn afgeleverd, bewaart Kinesis Data Firehose de gegevens intern tot een maximale periode van 24 uur. Als het probleem aanhoudt na de maximale bewaarperiode van 24 uur, verwijdert Kinesis Data Firehose de gegevens, wat resulteert in gegevensverlies.
Wanneer dergelijke problemen met de gegevenslevering aanhouden, gegevens versheid metrisch, de leeftijd van het oudste record in Kinesis Data Firehose dat nog niet is afgeleverd, neemt voortdurend toe. Om in dergelijke gevallen gewaarschuwd te worden, moet u een CloudWatch-alarm maken voor wanneer de metrische gegevensversheid de drempel van 4 uur overschrijdt. We raden ook aan een alarm in te stellen om de historische p90 van de metrische waarde voor gegevensversheid te observeren. Stel bijvoorbeeld een bepaald tolerantieniveau in (zoals 50% boven de waargenomen waarde) als alarmdrempel om variaties in gegevensversheid te detecteren.
U moet de metrische gegevens over de versheid van gegevens controleren die relevant zijn voor uw Kinesis Data Firehose-bestemming, zoals: DeliveryToS3.DataFreshness, DeliveryToAmazonOpenSearchService.DataFreshness, DeliveryToSplunk.DataFreshnessof DeliveryToHttpEndpoint.DataFreshness. Voor meer informatie, zie Kinesis-gegevensbrandblusser bewaken met behulp van CloudWatch-statistieken.
Als dit alarm wordt geactiveerd, moet u actie ondernemen om de hoofdoorzaak van de variatie in gegevensversheid te begrijpen. Een reden voor een dergelijke variatie kan een verandering in uw Lambda-transformatielogica of configuratiewijziging van Lambda-gelijktijdigheid bij gebruik Kinesis Data Firehose-gegevenstransformatie. Het kan ook een gevolg zijn van een wijziging in de configuratieparameters, formaat conversie schema, of opgenomen recordtype. Voor meer informatie, zie Gegevensversheidsstatistiek Toenemend of niet verzonden of je kan een verzoek om technische ondersteuning indienen indien nodig.
Wanneer gegevenslevering mislukt vanwege gegevenstransformatie of een probleem op de bestemming, kunt u in sommige gevallen gedetailleerde storingslogboeken vinden in CloudWatch-logboeken, waarmee u het probleem kunt oplossen.
We raden ook aan om de bytesnelheid van de gegevenslevering naar uw bestemming te controleren (bijvoorbeeld DeliveryToS3.Byte), die moet overeenkomen met of hoger zijn dan uw bytesnelheid voor gegevensopname (IncomingBytes) op een aanhoudende gemiddelde basis om verhoging van de gegevens versheid metrisch en mogelijk uiteindelijk gegevensverlies. Als de waargenomen leveringsdatasnelheden lager zijn dan de opnamesnelheden, overweeg dan om knelpunten zoals Lambda-concurrency-niveaus of uw Lambda-transformatielogica indien gebruikt met Kinesis Data Firehose-gegevenstransformatie.
Om extra inzicht te krijgen in de levering van uw gegevens op de bestemming, bieden we CloudWatch-statistieken die u kunt controleren. U kunt bijvoorbeeld het aantal afgeleverde records controleren om de gegevens bij te houden die vanuit Kinesis Data Firehose naar uw bestemmingen zijn opgenomen. Voor meer informatie en aanvullende statistieken per bestemming, zie Kinesis-gegevensbrandblusser bewaken met behulp van CloudWatch-statistieken.
Conclusie
In dit bericht hebben we de mogelijkheden besproken van het gebruik van de Firehose-leveringsstroomstatistieken en het CloudWatch-dashboard op uw Kinesis Data Firehose-console. Hierdoor kunt u operationeel inzicht krijgen in de gegevensopname en gegevenslevering van uw Firehose-leveringsstroom, en ook CloudWatch-waarschuwingen maken om op de hoogte te worden gesteld wanneer een van uw drempels wordt overschreden. We hebben ook de verschillende acties besproken die u kunt ondernemen wanneer deze alarmen worden geactiveerd, zoals het indienen van een verzoek om uw quotum te verhogen of het toevoegen van exponentiële uitstel aan uw gegevensproducenten.
Bewaak uw leveringsstromen en onderneem deze acties om ervoor te zorgen dat uw bedrijfsgegevens zonder onderbrekingen op uw bestemmingen worden afgeleverd, zodat uw bedrijf bijna in realtime inzicht krijgt.
Over de auteur
Alon Gentler is een Startup Solutions Architect Manager bij Amazon Web Services. Hij werkt samen met AWS-klanten om hen te helpen bij het oplossen van complexe problemen en om veilige, veerkrachtige, schaalbare en hoogwaardige applicaties in de cloud te ontwerpen. Alon heeft een passie voor data en helpt klanten er het maximale uit te halen.
