Comment ingérer un grand nombre de logs dans ASP.Net Web API ?

Question

Je suis novice en matière de développement d'API et je souhaite créer un point final d'API Web qui recevra une grande quantité de données de journalisation. Et je veux envoyer ces données à Seau Amazon s3 via Flux de livraison Amazon Kinesis . Vous trouverez ci-dessous un exemple d'application qui fonctionne ENFIN, Mais je n'ai AUCUNE idée de la manière d'INGESTER de grandes quantités de données entrantes et du format dans lequel mon API doit recevoir les données. ? A quoi doit ressembler mon point de terminaison API ?

 [HttpPost]
 public async void Post() // HOW to allow it to receive large chunk of data?
 {
        await WriteToStream();
 }

    private async Task WriteToStream()
    {
        const string myStreamName = "test";
        Console.Error.WriteLine("Putting records in stream : " + myStreamName);
        // Write 10 UTF-8 encoded records to the stream.
        for (int j = 0; j < 10000; ++j)
        {
        // I AM HARDCODING DATA HERE FROM THE LOOP COUNTER!!! 
            byte[] dataAsBytes = Encoding.UTF8.GetBytes("testdata-" + j);
            using (MemoryStream memoryStream = new MemoryStream(dataAsBytes))
            {
                    PutRecordRequest putRecord = new PutRecordRequest();
                    putRecord.DeliveryStreamName = myStreamName;
                    Record record = new Record();
                    record.Data = memoryStream;
                    putRecord.Record = record;
                    await kinesisClient.PutRecordAsync(putRecord);
            }
        }
    }

P.S. : Dans une application réelle, je n'aurai pas cette boucle. Je veux que mon API ingère de grandes données, quelle devrait être la définition de mon API ? Dois-je utiliser quelque chose appelé multiformes/données , fichier ? Merci de me guider.

Answer 1

Voici mon raisonnement. Comme vous exposez une API pour la journalisation, votre entrée devrait contenir les attributs suivants

• Niveau de journalisation (info, debug, warn, fatal)
• Message du journal (chaîne)
• ID de l'application
• ID de l'instance d'application
• application IP
• Hôte (machine dans laquelle l'erreur a été enregistrée)
• ID de l'utilisateur (pour lequel l'erreur s'est produite)
• Horodatage en Utc (heure à laquelle l'erreur s'est produite)
• Données supplémentaires (personnalisables en xml / json)

Je suggère d'exposer l'API en tant qu'AWS lambda via l'API Gateway, car cela facilitera la mise à l'échelle en cas d'augmentation de la charge.

Pour obtenir un exemple de la manière de construire une API et d'utiliser la liaison de modèle, vous pouvez vous référer à https://docs.microsoft.com/en-us/aspnet/web-api/overview/formats-and-model-binding/model-validation-in-aspnet-web-api

Answer 2

Je n'ai pas beaucoup de contexte et je vais donc essayer de répondre à la question de mon point de vue.

Tout d'abord, au lieu d'envoyer les données à webapi, j'enverrais les données directement à S3. Dans azure il y a un Token d'accès partagé donc vous envoyez une requête à votre api pour vous donner l'url où télécharger le fichier (il y a beaucoup d'options mais vous pouvez limiter par le temps, limiter par l'IP qui peut télécharger). Donc pour télécharger un fichier 1. Faire un appel pour obtenir l'url de téléchargement, 2. PUT à cette url. Dans le cas d'Amazon, il s'agit de Politique signée .

Après cela, écrire une fonction lambda qui sera déclenchée sur le téléchargement S3, cette fonction enverra un événement (encore une fois, je ne sais pas comment cela se passe dans AWS, mais dans Azure, j'enverrai un message Blob Queue), cet événement contiendra l'url du fichier et la position de départ.

Ecrire un second Lambda qui écoute les événements et fait le traitement réel. Dans mes applications, je sais parfois que le traitement de N éléments prend 10 secondes, donc je choisis généralement N comme étant quelque chose qui ne dépasse pas 10-20 secondes, en raison de la nature des déploiements. Une fois que vous avez traité N lignes et que vous n'avez pas encore terminé, envoyez le même événement, mais maintenant la position de départ = position de départ au début + N. Plus d'informations comment lire la gamme

En concevant cette méthode, vous pouvez traiter des fichiers volumineux, et même être plus intelligent car vous pouvez envoyer plusieurs événements en indiquant la ligne de départ et la ligne d'arrivée, ce qui vous permettra de traiter votre fichier en plusieurs fois.

PS. La raison pour laquelle je ne vous recommande pas d'uploader des fichiers vers WebApi est que ces fichiers seront en mémoire, donc disons que vous avez des fichiers de 1GB envoyés de plusieurs sources dans ce cas vous tuerez vos serveurs en quelques minutes.

PS2. Le format du fichier dépend, il pourrait être json puisque c'est le moyen le plus facile de lire ces fichiers, mais gardez à l'esprit que si vous avez de gros fichiers, il sera coûteux de lire tout le fichier en mémoire. Voici ce qu'il en est exemple de lecture correcte . L'autre option pourrait donc être un fichier plat, ce qui faciliterait sa lecture, puisque vous pourriez alors lire la plage et la traiter.

PS3. Dans azure, j'utiliserais Azure Batch Jobs