{"id":3144,"date":"2021-05-28T13:59:00","date_gmt":"2021-05-28T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3144"},"modified":"2023-04-21T10:01:15","modified_gmt":"2023-04-21T08:01:15","slug":"best-practices-per-il-logging-su-aws-lo-stack-ekk","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/best-practices-per-il-logging-su-aws-lo-stack-ekk\/","title":{"rendered":"Best practices per il logging su AWS: lo stack EKK."},"content":{"rendered":"\r\n
Oggigiorno \u00e8 sempre pi\u00f9 importante poter monitorare e tracciare lo stato delle proprie applicazione, come saper identificare facilmente la fonte di problematiche. Contando il numero sempre pi\u00f9 crescente di servizi digitali, indipendentemente dalla loro grandezza e importantanza, questa esigenza \u00e8 sempre pi\u00f9 sentita.<\/p>\r\n\r\n\r\n\r\n
Ad oggi ci si scontra anche con molti pattern infrastrutturali moderni e sempre pi\u00f9 complessi, pensiamo al mondo microservizi o serverless. Bisogna trovare strumenti efficaci e centralizzati per il monitoraggio.<\/p>\r\n\r\n\r\n\r\n
Lungi da noi andare a descrivere e comparare i vari programmi di logging management, non basterebbe un solo articolo! Possiamo dire, per\u00f2, che sul mondo AWS questi problemi vengono notevolmente ridotti grazie alle numerose alternative che abbiamo a disposizione, unitamente al vantaggio dei servizi totalmente gestiti!<\/p>\r\n\r\n\r\n\r\n
In questo articolo andremo a parlare di come centralizzare e gestire in modo efficiente i log provenienti da varie applicazioni, restando interamente sul mondo AWS! Nello specifico, esploreremo un\u2019alternativa alla popolare soluzione di log aggregation, lo stack ELK (Elasticsearch, Logstash, Kibana), ovvero lo stack EKK (Amazon Elasticsearch Service, Amazon Kinesis e Kibana).<\/p>\r\n\r\n\r\n\r\n
Iniziamo con una breve descrizione dello stack ELK. Per chi di voi lo conoscesse, facciamo un ripasso insieme! Come per la storia, anche nell\u2019informatica risulta utile conoscere il passato per comprendere a meglio il presente.<\/p>\r\n\r\n\r\n\r\n
Partendo dal diagramma riportato sotto, lo stack ELK \u00e8 composto dai seguenti componenti:<\/p>\r\n\r\n\r\n\r\n
Presentato cos\u00ec, potrebbe risultare relativamente complessa la semplice funzione di \u201clogging\u201d della nostra applicazione. Tuttavia, questo stack ad oggi \u00e8 utilizzato moltissimo per la sua versatilit\u00e0 e la sua scalabilit\u00e0.<\/p>\r\n\r\n\r\n\r\n
Ma non \u00e8 di questa struttura che andremo a parlare, bens\u00ec di un suo \u201cfork\u201d cloud-native sul mondo AWS! Tratteremo infatti lo stack EKK, i componenti che entrano in gioco diventano:<\/p>\r\n\r\n\r\n\r\n
Il diagramma infrastrutturale si trasforma come di seguito:<\/p>\r\n\r\n\r\n\r\n
Comodo, vero? Dimentichiamoci il provisioning e la gestione di macchine EC2, oltre al loro scaling, manutenzione e configurazione in alta disponibilit\u00e0. Questi servizi, totalmente gestiti da AWS, vengono in nostro soccorso permettendoci di concentrarci sulla nostra applicazione e ridurre attivit\u00e0 costose, in termini di tempo, per la \u201cbanale\u201d infrastruttura legata all\u2019aggregazione e presentazione dei log.<\/p>\r\n\r\n\r\n\r\n
Per i pi\u00f9 diffidenti, il dover mandare i dati a Firehose potrebbe non risultare la scelta migliore. Ma vediamo di illustrarne i vantaggi.<\/p>\r\n\r\n\r\n\r\n
Innanzitutto, esiste un\u2019integrazione nativa tra Kinesis e Elasticsearch gestito da AWS! Inoltre, possiamo decidere di effettuare attivit\u00e0 di processing su tutti i dati in ingresso, se fosse ad esempio necessario formattare i log in arrivo da tutti i sistemi sorgenti.<\/p>\r\n\r\n\r\n\r\n
Non basta? Su Kinesis possiamo anche selezionare un bucket S3 per salvare i log, cos\u00ec facendo saranno disponibili in futuro per eventuali analisi o spostamento su altre piattaforme.<\/p>\r\n\r\n\r\n\r\n
Per ridurre i costi, nulla ci vieta di spostare i dati su altri S3 Tier pi\u00f9 economici rispetto a quello Standard.<\/p>\r\n\r\n\r\n\r\n
Tra le funzioni offerta da Kinesis, c\u2019\u00e8 poi quella di batching, encryption e retry per gestire al meglio le richieste verso il server di Elasticsearch.<\/p>\r\n\r\n\r\n\r\n
Ma quali sorgenti possiamo utilizzare con Kinesis? Idealmente, qualsiasi! E\u2019 infatti possibile richiamare direttamente le API (ad esempio quelle fornite dai vari SDK), oppure possiamo utilizzare strumenti gi\u00e0 forniti da AWS se stiamo utilizzando i suoi servizi di computing pi\u00f9 noti.<\/p>\r\n\r\n\r\n\r\n
Facciamo qualche esempio:<\/p>\r\n\r\n\r\n\r\n
Riassumendo, abbiamo visto come riportare il classico stack ELK in ottica cloud-native AWS, trasformandolo quindi in stack EKK per sfruttare i vantaggi dei servizi gestiti da AWS.<\/p>\r\n\r\n\r\n\r\n
Non vedete l\u2019ora di fare un po\u2019 di pratica? Perfetto! Facciamo una breve demo utilizzando un cluster ECS in modalit\u00e0 Fargate!<\/p>\r\n\r\n\r\n\r\n
Prima di partire con la demo, elenchiamo i servizi che andremo ad utilizzare:<\/p>\r\n\r\n\r\n\r\n
Ecco il nostro cluster Fargate con il service<\/em> creato per la demo, blog-ekk<\/em>:<\/p>\r\n\r\n\r\n\r\n Particolare attenzione \u00e8 da porre nel definizione del task definiton<\/em>, andremo infatti a utilizzare FireLens<\/em> per l\u2019integrazione nativa tra Fargate e Firehose:<\/p>\r\n\r\n\r\n\r\n FireLens \u00e8 un log driver per i container ospitati su Amazon ECS che estende le sue funzionalit\u00e0 per la gestione dei log. Si appoggia a Fleuntd e Fluent Bit.<\/p>\r\n\r\n\r\n\r\n Di seguito viene riportata una semplificazione del task definition utilizzato da noi:<\/p>\r\n\r\n\r\n\r\n <\/p>\r\n\r\n\r\n\r\n Se utilizziamo l\u2019interfaccia grafica per la creazione del nostro task definition, una volta configurato il nostro container, modificando il log router in firelens apparir\u00e0 in automatico il side container che si appoggia a FluentBit (container image: amazon \/ aws-for-fluent -bit: latest<\/em>)<\/p>\r\n\r\n\r\n\r\n Non dimenticatevi di cambiare il task definition role affinch\u00e9 abbia i permessi di scrivere su Firehose!<\/p>\r\n\r\n\r\n\r\n Perfetto, il sistema sender \u00e8 stato configurato! Passiamo ora alla definizione del sistema di ingestion: Kinesis Firehose!<\/p>\r\n\r\n\r\n\r\n La sua configurazione risulta relativamente semplice. Nel nostro caso abbiamo utilizzato S3 come backup, Elasticsearch come destinazione e nessuna trasformazione Lambda.<\/p>\r\n\r\n\r\n\r\n Avete configurato tutto? Assicuratevi che il vostro Service su ECS sia up e running, nella sezione log<\/em> potete controllare che il side container stia effettivamente inoltrato i log a Kinesis.<\/p>\r\n\r\n\r\n\r\n Per ulteriore verifica, potete controllare dalle metriche su Kinesis la corretta ricezione e il corretto inoltro sul server Elasticsearch.<\/p>\r\n\r\n\r\n\r\n Non ci resta che entrare sul dominio di Elasticsearch, nella pagina di overview troveremo l\u2019indirizzo per accedere a Kibana. Nel nostro caso l\u2019accesso verr\u00e0 autenticato tramite username e password salvati e gestiti da Cognito:<\/p>\r\n\r\n\r\n\r\n Ed ecco qui la nostra dashboard su Kibana:<\/p>\r\n\r\n\r\n\r\n Il comportamento \u00e8 quello atteso, abbiamo infatti creato un semplice container che scrive \u201cbingo\u201d periodicamente tramite un setInterval in Javascript.<\/p>\r\n\r\n\r\n\r\n Per concludere, in questo articolo abbiamo descritto i vantaggi dello stack EKK, una versione cloud-native AWS del classico stack ELK.<\/p>\r\n\r\n\r\n\r\n Abbiamo poi visto quali possibili servizi possiamo utilizzare per inoltrare i nostri log, approfondendo il caso di container ospitati su ECS in modalit\u00e0 Fargate.<\/p>\r\n\r\n\r\n\r\n Volete approfondire questa modalit\u00e0 con una guida passo-passo? O magari siete curiosi della soluzione partendo da macchine EC2? Scriveteci o commentate con le vostre considerazioni!<\/p>\r\n A tra 14 giorni con un nuovo articolo su #Proud2beCloud!<\/strong><\/p>\r\n\r\n\r\n\r\n <\/p>\r\n","protected":false},"excerpt":{"rendered":" Introduzione Oggigiorno \u00e8 sempre pi\u00f9 importante poter monitorare e tracciare lo stato delle proprie applicazione, come saper identificare facilmente la […]<\/p>\n","protected":false},"author":14,"featured_media":3155,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[269,251,265],"class_list":["post-3144","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecting","tag-amazon-elasticsearch-service","tag-amazon-s3","tag-kibana"],"yoast_head":"\n<\/figure>\r\n<\/div>\r\n\r\n\r\n\r\n
{ \"family\": \"firelens-example-firehose\", \"taskRoleArn\": \"arn:aws:iam::XXXXXXXXXXXX:role\/ecs_task_iam_role\", \"executionRoleArn\": \"arn:aws:iam::XXXXXXXXXXXX:role\/ecs_task_execution_role\", \"containerDefinitions\": [ { \"essential\": true, \"image\": \"amazon\/aws-for-fluent-bit:latest\", \"name\": \"log_router\", \"firelensConfiguration\": { \"type\": \"fluentbit\" }, \"logConfiguration\": { \"logDriver\": \"awslogs\", \"options\": { \"awslogs-group\": \"firelens-container\", \"awslogs-region\": \"eu-west-1\", \"awslogs-create-group\": \"true\", \"awslogs-stream-prefix\": \"firelens\" } }, \"memoryReservation\": 50 }, { \"essential\": true, \"image\": \"your-image-uri\", \"name\": \"app\", \"logConfiguration\": { \"logDriver\":\"awsfirelens\", \"options\": { \"Name\": \"firehose\", \"region\": \"eu-west-1\"\", \"delivery_stream\": \"blog-ekk\" } }, \"memoryReservation\": 100 } ] }<\/pre>\r\n
<\/figure>\r\n<\/div>\r\n\r\n\r\n\r\n
<\/figure>\r\n<\/div>\r\n\r\n\r\n\r\n
<\/figure>\r\n<\/div>\r\n\r\n\r\n\r\n
Conclusioni<\/h2>\r\n\r\n\r\n\r\n