<section style="text-align: center;"> # Agents Natifs GCP ![gcp](/uploads/upload_fbdbd6c77f6af86908b383ae45570b3d.png) --- <section style="text-align: left;"> ## Objectifs - Tester l'agent natif de GCP pour collecter logs et métriques - Essayer et analyser les fonctionnalités du tableau de bord natif de GCP - Modifier la configuration pour les logs et métriques --- <section style="text-align: left;"> ## GCP cloud monitoring <font size="6"> Cloud monitoring offre une solution pour collecter, analyser et exploiter les données... Les agents proposés sont : - Agent Ops (par défaut) - Legacy agent (obsolète) En combinant la journalisation et les métriques dans un seul agent, l'agent Ops utilise **Fluent Bit** pour les journaux, qui est compatible avec la journalisation à haut débit, et le collecteur **OpenTelemetry** pour les métriques. </font> --- <section style="text-align: left;"> ## Fluentbit <font size="6"> [Fluentbit](https://fluentbit.io/) est un projet open source créé par l'équipe TreasureData et sous la responsabilité de CNCF (Cloud Native Computing Fundation). Il permet la gestion des logs dans les VMs et conteneurs. Etant basé sur fluentd, fluentbit apporte plusieurs avantages: - consommation mémoire moindre - Pas de dépendances externes - journalisation haut débit </font> </section> <section style="text-align: center;"> ![fluentbit](/uploads/upload_fd88b6d7d6171231e46b292dc525b4e6.png =x220) </section> --- ## OpenTelemetry <font size="6"> [OpenTelemetry](https://opentelemetry.io/) est un projet de l'incubateur CNCF. Il est utilisé pour orchestrer, collecter, générer et exporter des données (métriques, logs et traces) afin d'analyser les performances et les comportements des logiciels. </font> <section style="text-align: center;"> ![OpenTelemetry Collection](/uploads/upload_57b50ebc2420c46302faefaa5ffc4448.png =x350) --- <section style="text-align: left;"> <font size="4"> ## Configuration de l'[agent OPS](https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/configuration) L'agent Ops utilise une configuration par défaut intégrée et immuable. On peut cependant y ajouter notre fichier de configuration après redémarrage de l'agent. Les composants de la configuration sont : Receivers : cet élément décrit ce qui est collecté par l'agent. Processors : cet élément décrit comment l'agent peut modifier les informations collectées. Service : cet élément associe les récepteurs et les processeurs pour créer des flux de données, appelés pipelines. La configuration de l'agent Ops est à modifier dans les fichiers suivant : Pour Linux : /etc/google-cloud-ops-agent/config.yaml Pour Windows : C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml </font> ![configuration OpsAgent](/uploads/upload_2e8fc11eb106f67f2fea620b05f91593.png =x400) <!--- Architecture d'OpenTelemetry Source: ![OpenTelemetry Collection](/uploads/upload_57b50ebc2420c46302faefaa5ffc4448.png) --> --- <section style="text-align: left;"> <font size="5"> ## Configuration de métriques L'élément receivers contient un ensemble de définitions de récepteur. Un récepteur désigne où extraire les métriques, par exemple cpu et memory. Un récepteur peut être partagé entre plusieurs pipelines. Chaque récepteur doit avoir un identifiant, RECEIVER_ID, et inclure un élément type. Les types valides sont les suivants : - hostmetrics - iis (Windows uniquement) - mssql (Windows uniquement) ```(yaml) metrics: receivers: hostmetrics: type: hostmetrics collection_interval: 10s ``` </font> --- <section style="text-align: left;"> <font size="5"> ## Configuration de la journalisation L'élément receivers contient un ensemble de récepteurs, chacun étant identifié par un RECEIVER_ID. Un récepteur décrit comment récupérer les journaux (par exemple, en affichant les dernières lignes des fichiers, via un port TCP, ou depuis le journal des événements Windows). Les types valides sont les suivants : files : collecter des journaux en affichant les dernières lignes des fichiers sur le disque. fluent_forward : collecter les journaux envoyés à l'aide du protocole Fluent Forward via TCP. syslog : collecter syslog via TCP ou UDP. tcp : collecter les journaux au format JSON en écoutant un port TCP. windows_event_log (Windows uniquement) : collecter les journaux d'événements Windows. systemd_journald : collecter des journaux à partir du service systemd-journald. ```(yaml) receivers: RECEIVER_ID: type: files ... RECEIVER_ID_2: type: syslog ... ``` </font> --- <section style="text-align: left;"> <font size="6"> ## Cas pratique : surveillance de l'applications Nginx Prérequis - Nginx installé avec Stub-status activé - configuration de l'agent OPS (opentelemetry) Nginx étant l'une des [applications pré configurées](https://cloud.google.com/monitoring/agent/ops-agent/third-party) pour l'agent ops, un minimum de configuration suffit pour exporter à la fois les métriques et les logs. </font> --- <section style="text-align: left;"> #### La configuration de l'agent ops pour nginx <font size="4"> ```(bash) sudo tee /etc/google-cloud-ops-agent/config.yaml > /dev/null << EOF # CONFIGURATION DES LOGS - ACCES ET ERREURS logging: receivers: nginx_access: type: nginx_access nginx_error: type: nginx_error service: pipelines: nginx: receivers: - nginx_access - nginx_error # CONFIGURATIOND DES METRIQUES metrics: receivers: nginx: type: nginx stub_status_url: http://127.0.0.1:80/nginx_status service: pipelines: nginx: receivers: - nginx # REDEMARRAGE DE L'AGENT sudo service google-cloud-ops-agent restart EOF ``` </font> --- <section style="text-align: left;"> ## Filtrage des métriques - ajout d'un processors - un seul filtre possible (exclude_metrics) <font size="3"> ![](/uploads/upload_7f37c393f2d736af0613a210d9a0f1da.png =x200) </font> --- <section style="text-align: left;"> ## Filtrage de la journalisation - ajout d'un processors - plusieurs filtres possibles (parse_json, parse_regex, exclude_logs) <font size="3"> ![](/uploads/upload_acd43167e4fa00e06a4f0ab2885d2069.png) </font> --- ## Empreinte sur la machine virtuelle GCP fournit d'origine un tableau de bord permettant d'observer les processus de la machine. ![Focus sur OpenTelemetry](/uploads/upload_70f16d9a27cb77124254f6fbe966cabd.png =x300) --- ## Limitations <font size="6"> * Pas de support multiline pour les stacktrace mais un MR est ouvert dans ce sens * Impossible de créer des métriques custom en utilisant directement le collector opentelemetry * Un nombre limité d'applications préconfigurées (voir la liste https://cloud.google.com/monitoring/agent/ops-agent/third-party) * Pas de lograte pour les logs de l'agent Ops NB: GCP travaille déja sur toutes ces limitations </font> --- ## Conclusion <font size="6"> * facilité d'installation et de configuration * des tableaux de bord pré configurés et nativement accessibles * configuration uniforme entre windows et linux * empreinte mémoire minime * documentation complète * repo github très actif </font> --- ## Liens [documentation confluence](https://confluence.corp.cloudwatt.com/display/CAAS/Agents+GCP) [documentation upstream de l'agent ](https://cloud.google.com/logging/docs/agent/ops-agent) [repo github](https://github.com/GoogleCloudPlatform/ops-agent) --- <style type="text/css"> p { font-size: smaller; } .reveal ul ul li { font-size: smaller; } .reveal ol li { font-size: smaller; } .reveal ol li ul li { font-size: smaller; } .reveal section { text-align: left; } } .reveal h3 { color: orange; text-align: center; border-bottom: 1px solid orange; } .reveal h2 { color: orange; text-align: center; border-bottom: 1px solid orange; } .reveal h1 { color: orange; text-align: center; border-bottom: 1px solid orange; margin-bottom: 0.4em; } .reveal code { color: aquamarine; font-size: smaller; } </style>
{"type":"slide","slideOptions":{"transition":"slide","center":true}}