Forem: Ezzio Moreira

OpenTelemetry Collector ElasticBeanStalk

Ezzio Moreira — Fri, 28 Jun 2024 14:27:15 +0000

Este guia descreve os passos para implementar o OpenTelemetry Collector no Elastic Beanstalk utilizando .ebextension. O processo inclui baixar o binário do OpenTelemetry Collector, configurar um serviço do Linux, copiar o arquivo de configuração e iniciar o serviço.

1. Criar a Pasta `.ebextensions`

Primeiro, crie um diretório chamada .ebextensions no diretório raiz da sua aplicação.

2. Baixar o Binário do OpenTelemetry Collector

Crie um arquivo de configuração chamado 01_download_collector.config no diretório .ebextensions para baixar o binário do OpenTelemetry Collector.

files:
  "/opt/otelcol-contrib/otelcol-contrib":
    mode: "000755"
    owner: ec2-user
    group: ec2-user
    source: https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.103.1/otelcol-contrib_0.103.1_linux_arm64.tar.gz

commands:
  extract_otel_collector:
    command: "tar -xvzf /opt/otelcol-contrib/otelcol-contrib -C /opt/otelcol-contrib/"

3. Criar o Serviço Linux para OtelColl

Crie um arquivo de configuração chamado 02_create_service.config para configurar um serviço systemd para o OpenTelemetry Collector.

files:
  "/etc/systemd/system/otelcol-contrib.service":
    mode: "000644"
    owner: root
    group: root
    content: |
      [Unit]
      Description=OpenTelemetry Collector Contrib
      After=network.target

      [Service]
      User=ec2-user
      ExecStart=/opt/otelcol-contrib/otelcol-contrib --config=/etc/otelcol-contrib/config.yaml
      Restart=always

      [Install]
      WantedBy=multi-user.target

commands:
  reload_systemd:
    command: "sudo systemctl daemon-reload"
  enable_service:
    command: "sudo systemctl enable otelcol-contrib"

4. Copiar o Arquivo de Configuração

Crie um arquivo de configuração chamado 03_copy_config.config para copiar o arquivo de configuração do OpenTelemetry Collector.

files:
  "/etc/otelcol-contrib/config.yaml":
    mode: "000644"
    owner: ec2-user
    group: ec2-user
    content: |
      receivers:
        otlp:
          protocols:
            grpc:
              endpoint: "0.0.0.0:4317"
            http:
              endpoint: "0.0.0.0:4318"

        prometheus:
          config:
            scrape_configs:
              - job_name: otelcoll-metrics
                scrape_interval: 60s
                static_configs:
                  - targets: ['localhost:8888']

      processors:
        batch:
          send_batch_max_size: 1000
          timeout: 60s
          send_batch_size: 800

        memory_limiter:
          check_interval: 1s
          limit_percentage: 70
          spike_limit_percentage: 30

        resourcedetection:
          detectors: [env, elastic_beanstalk, ec2]
          timeout: 2s
          override: false

        attributes/logs:
          actions:
            - action: insert
              key: loki.attribute.labels
              value: event.domain, event.name
            - action: insert
              key: loki.format
              value: json

        resource/logs:
          attributes:
            - action: insert
              key: loki.resource.labels
              value: service.name

      exporters:
        loki:
          endpoint: http://ENPOINT:3100/loki/api/v1/push
          tls:
            insecure: true

        otlphttp/tempo:
          endpoint: http://ENPOINT:4318
          tls:
            insecure: true

        prometheusremotewrite:
          endpoint: http://ENPOINT:9009/api/v1/push
          resource_to_telemetry_conversion:
            enabled: true
          target_info:
            enabled: false

      service:
        telemetry:
          logs:
            level: info
          metrics:
            address: 0.0.0.0:8888

      pipelines:
        traces:
          receivers: [otlp]
          processors: [resourcedetection, batch, memory_limiter]
          exporters: [otlphttp/tempo]

        metrics:
          receivers: [otlp, prometheus]
          processors: [resourcedetection, batch, memory_limiter]
          exporters: [prometheusremotewrite]

        logs:
          receivers: [otlp]
          processors: [resourcedetection, resource/logs, attributes/logs, batch, memory_limiter]
          exporters: [loki]

5. Iniciar o Serviço

Crie um arquivo de configuração chamado 04_start_service.config para iniciar o serviço do OpenTelemetry Collector.

commands:
  start_otel_service:
    command: |
      sudo systemctl start otelcol-contrib
      sudo systemctl status otelcol-contrib

Resumo

Esta abordagem garante que o coletor inicie corretamente e comece a enviar dados para o Grafana após o lançamento da instância.

Referencia

https://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/customize-containers-ec2.html

Stack Grafana deployed on AWS ECS -Part 1 - Create a Cluster

Ezzio Moreira — Fri, 26 Apr 2024 18:54:01 +0000

This post is part of a series about the stack Grafana deployed on AWS ECS. This project is a simple MVP.

In part 1, we will set up our cluster ECS and LoadBalance.

AWS ECS: is a container orchestration that helps us to deploy, manage, and scale applications.

Pre-Requirements

Knowledge with Terraform
AWS Account
- 2 subnets publics, with tag: tier = public
- 2 subnets private, with tag: tier = private

AWS VPC

We need the following structure for AWS VPC. We'll get ID the subnets privates with the Terraform DataSource.

Remember the add tag tier = private for private subnets.

Remember the add tag tier = public for public subnets.

ECS Cluster Type

Currently, there are three types of the ECS cluster. Cluster EC2 instance, serverless Fargate, and on-primeses VM.

Consult the AWS documentations for more details. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-configuration.html

We'll use the ECS EC2 cluster for this MVP.

Create ECS Cluster

You can use this Terraform module to create cluster ECS.

https://github.com/EzzioMoreira/aws-terraform-module/releases/tag/v0.0.1-ecs-cluster-alb

Below an example how to use this module. That will provide a cluster ECS type of EC2, and Application LoadBalance.



####################################################################################################

### ECS Cluster o11y ###

####################################################################################################

module "ecs_cluster" {

  source = "https://github.com/EzzioMoreira/aws-terraform-module//modules/ecs-cluster?ref=v0.0.1-ecs-cluster-alb"

cluster_name  = "ecs-cluster-example"

  min_size      = 1

  max_size      = 2

  desired_size  = 1

  instance_type = "t3a.medium"

  vpc_id        = "vpc-xxxxxxxx"

  tags = {

    created_by    = "terraform"

    documentation = "null"

    env           = "prod"

    repository    = "ezziomoreira/aws-terraform-modules"

    service       = "observability"

    team          = "sre"

  }

}

####################################################################################################

### Loadbalance o11y ###

####################################################################################################

module "loadbalance" {

  source = "https://github.com/EzzioMoreira/aws-terraform-module//modules/loadbalance?ref=v0.0.1-ecs-cluster-alb"

name               = "ecs-cluster-example-internal"

  type               = "application"

  internal           = true

  subnet_ids         = ["subnet-xyxyx", "subnet-yxyxyx"]

  security_group_ids = [sg-123123123]

  tags = {

    created_by    = "terraform"

    documentation = "null"

    env           = "prod"

    repository    = "ezziomoreira/aws-terraform-modules"

    service       = "observability"

    team          = "sre"

  }

}

References

Siglas da Observabilidade SLI, SLO, SLE, MTTA, MTTR, MTBF e MTTF

Ezzio Moreira — Fri, 22 Sep 2023 13:56:57 +0000

Nesta postagem, abordaremos alguns termos relacionados a conceitos cruciais na área de administração de serviços e sistemas, especialmente no que se refere à análise de desempenho e observabilidade.
Essas siglas ajudam a avaliar e melhorar a confiabilidade, disponibilidade e eficiência de sistemas.
As equipes podem estabelecer metas e otimizar processos de reparo e manutenção garantindo serviços de alta qualidade.

SLA, SLO e SLI

Conforme mencionado no livro escrito por membros do time SRE do Google Site Reliability Engineering, SLI, SLO e SLA são indicadores de nível de serviço, objetivo e acordo.

Essas características definem quais métricas são relevantes, quais valores desejamos que essas métricas contenham e como as equipes devem agir caso o serviço não atenda às expectativas dos clientes.

SLA: Acordos de Nível de Serviço

É um acordo entre o provedor com clientes, sejam clientes externos ou outras equipes dentro de sua organização. O SLA é um acordo que diz quanto tempo o serviço estará disponível para os clientes e quais são as consequências se o acordo for quebrado. As consequências são facilmente percebidas, quando envolvem penalidades financeiras.

SLO: Objetivos de Nível de Serviço

É um acordo para o desempenho de um serviço, baseado no SLI. Por exemplo, 99% das requisições HTTP serão concluídas em menos de 50 ms. O SLO define o que o cliente espera do sistema e quais metas devem ser atingidas pelas equipes de engenharia.

SLI: Indicadores de Nível de Serviço

SLIs são métricas usadas na avaliação de SLOs, como latência, taxa de transferência ou taxa de erro que indicam o desempenho do sistema.

Exemplo

Através do SLI mediremos a disponibilidade de um site, queremos que o site esteja disponível 99,8% do tempo.

Definiremos um SLO de 99,8%, o que significa que nosso objetivo é manter o site disponível 99,8% do tempo.

No SLA, documentamos o acordo entre o provedor do sistema e o cliente.

SLI é a métrica de disponibilidade, o SLO é a meta que queremos alcançar (99,8% de disponibilidade), e o SLA é o acordo que formaliza esse compromisso com os clientes do site.

MTTA, MTTR, MTBF e MTTF

O custo de um período de indisponibilidade (downtime) para um sistema pode variar significativamente com base no tipo de negócio, no tamanho da empresa, no setor, entre outros.

Durante um período de inatividade teremos custos associados como, perda de receita, perda de cliente, custo de recuperação, perda de credibilidade da marca, etc. O MTTA, MTTR, MTBF e MTTF são métricas importantes para gerenciar incidente e confiabilidade, para minimizar o impacto do downtime e melhorar a eficiência das operações.

MTTA (Mean Time To Acknowledge) Tempo Médio para Reconhecimento

O MTTA é o tempo médio que levamos para reconhecer uma falha. Isso inclui desde quando a falha ocorreu até o momento em que é ela foi reconhecida e registrada.

É crucial identificar falhas de forma rápida e reduzir o tempo total de inatividade do sistema. Dessa forma, podemos resolver o problema quanto antes.

MTTR (Mean Time To Repair) Tempo Médio para Reparo

O MTTR indica o tempo médio que leva para reparar o sistema ou resolver um problema após o reconhecimento.

Mostra a eficiência e velocidade com que a equipe resolve problemas e restaurando os serviços para os usuários.

MTBF (Mean Time Between Failures) Tempo Médio entre Falhas

É o tempo médio entre falhas de um sistema. Para calcular o MTBF dividimos o tempo total de operação pelo número de falhas ocorridas durante esse período.

Essa métrica é utilizada para entender a confiabilidade de um sistema e permite planejar manutenções preventivas.

MTTF (Mean Time To Failure) Tempo Médio sem Falhas

Mostra quanto tempo um sistema leva para falhar. O MTTF auxilia na compreensão do tempo que o sistema leva para apresentar falhas.

Conclusão

A utilização correta de SLIs, SLOs, SLEs, MTTA, MTTR, MTBF e MTTF permite um gerenciamento eficaz dos sistemas, garantindo que os serviços atendam às necessidades e expectativas dos usuários, aumentando a confiabilidade e a disponibilidade.

Referências

Conceitos OpenTelemetry

Ezzio Moreira — Fri, 15 Sep 2023 11:08:04 +0000

Em 2019, houve a fusão entre dois projetos, OpenCensus e OpenTracing que resultou no OpenTelemetry. Os dois projetos queriam resolver um problema comum, definir um padrão para instrumentação, coleta e envio de dados de telemetria para um backend de observabilidade.

OpenTracing é composto por uma especificação de APIs, permitindo enviar dados de telemetria para um vendor de observabilidade.
OpenCensus incluía um conjunto de bibliotecas suportada por diversas linguagens para instrumentar código e enviar dados para o backend de observabilidade.

A combinação dos pontos fortes de cada projeto permite que os usuários resolvam os desafios da observabilidade utilizando um padrão único de bibliotecas, APIs, coleta, processamento e envio de dados de telemetria agnóstico de vendors de observabilidade.

O que é OpenTelemetry?

É um framework de observabilidade que sustenta um conjunto de APIs, SDKs, agentes e outros elementos que permite gerar, processar e transmitir dados de telemetria de forma unificada e agnóstico ao provedor de observabilidade.

Conceitos do OpenTelemetry

Antes de começar a usar o OpenTelemetry, é importante entender quais são os principais componentes e terminologias.

Isso nos ajuda a compreender como funciona o OpenTelemetry.

Existe outros componentes e terminologias que não foram citadas aqui, consulte a documentação oficial do projeto.

O projeto é composto por:

Signals (Sinais)
Instrumentation (Instrumentação)
Semantic Conventions (Convenção Semântica)
Sampling (Amostragem)

Signals

Métrica, log, trace e bagagem são exemplos de sinais ou tipos de telemetria que formam a estrutura em torno do OpenTelemetry. Cada sinal representa um conjunto lógico e autônomo.

Esses sinais são importantes para a observabilidade, troubleshooting e monitoramento. Eles auxiliam os engenheiros a entender o que está acontecendo em um sistema, rastrear problemas e tomar decisões mais assertivas.

Instrumentation

Para tornar um sistema observável, é necessário que ele seja instrumentado. É adicionado um código ao sistema para coletar dados de telemetria.

Algumas linguagens suportam a autoinstrumentação, que provê uma forma de instrumentar seu aplicativo sem alterar o código-fonte do sistema.

Existem outros mecanismos para instrumentar um sistema, instrumentação manual e utilizando bibliotecas fornecidas pelo projeto OpenTelemtry.

Semantic Conventions

A convenção semântica é composto por vários documentos que especificam nomenclaturas comuns para os diferentes tipos de dados.

Por exemplo, se o servidor A possui uma métrica http.server.duration e o servidor B uma métrica http.server.request_duration, como podemos comparar a duração total entre os dois serviços se as métricas têm nomes diferentes?

A imagem mostra algumas especificações de atributos para Spans de cliente/servidor HTTP.

Sampling

Através do rastreamento distribuído, podemos observar a latência das requisições que passa entre os serviços.

No entanto, se a maioria das requisições tem um status bem-sucedido com latência num período previsível, precisamos de todos esses dados?
Nem sempre é necessário um grande volume de dados para encontrar os insights corretos. Você só precisa da amostragem correta desses dados.

A ideia por trás da amostragem é controlar a quantidade de dados que você envia para o backend de observabilidade, muitas vezes esses provedores de observabilidade cobram por dados ingestados.

Os principais objetivos da amostragem são: gerenciamento de custos, foco no rastreamento relevantes e filtrar ruídos.

Conclusão

Exploramos um pouco da história do OpenTelemetry e podemos entender a origem do projeto. Compreender os conceitos do OpenTelemetry nos auxiliará a superar os desafios para desenvolver observabilidade de alta qualidade.

Os sinais são compostos por trace, métricas, logs e baggage, os quais geram telemetria. Conhecer as convenções semânticas e a propagação de contexto ajuda na correlação dos eventos entre os sinais, através da amostragem podemos gerenciar os dados que serão enviados para o backend de observabilidade mantendo o foco nos dados relevantes para o sistema.

Referências:

Três Pilares da Observabilidade

Ezzio Moreira — Mon, 26 Jun 2023 23:41:54 +0000

Como foi mencionado no texto Observabilidade e Monitoramento, a observabilidade permite que as equipes atuem com mais rapidez e eficiência nos efeitos e causas geradas por sistemas.

Para isso, podemos contar com os 3 pilares da observabilidade, métrica, trace e log, no capítulo 4 do ebook Distributed-Systems-Observability, a autora menciona, que ter acesso à métrica, trace e log não necessariamente torna o sistema mais observável, esses sinais são importantes e se bem compreendidos, podem gerar insights valiosos para melhorar o sistema.

Log

Log é um registro de evento relevante e imutável gerado por sistema computacional ao longo do tempo. Imagine um diário de bordo, onde os navegadores registram os acontecimentos mais importantes de sua jornada mar adentro.

Os registos de log são considerados um dos elementos fundamentais para qualquer sistema, e todos os registos de log possuem no mínimo 3 características, carimbo de data e hora do momento que o evento foi gerado, uma mensagem que descreve o acontecimento e uma severidade (INFO, WARN, ERROR, EMERGENCY) que classifica o tipo de evento.
Em ambientes distribuídos, os logs podem se tornar complexos devido ao excesso de informações geradas pelos sistemas.

A grande maioria das equipes adotam padrões e boas práticas para gerenciar eventos de logs.

Logs devem ser registrados no formato JSON, é adotado devido à sua estrutura organizada e fácil de analisar.
Informações de origem do registro do evento de logs, esse tipo de informação é muito útil em ambientes distribuídos. Segundo a documentação do OpenTelemetry, com esse tipo de abordagem podemos capturar a hierarquia de identificação da entidade que originou o evento. O log deve conter informação que descreve qual é o cluster, host, namespace, pod, contêiner, etc.
É esperado que toda inicialização e encerramento do sistema seja logado, isso ajuda a identificar possíveis problemas durante o processo de inicialização e encerramento do sistema.
Erros e Exceções, causas não esperadas na lógica do sistema precisam ser registradas.
Correlação de log e trace, segundo a documentação do OpenTelemetry, é uma prática padrão registrar o contexto de rastreamento (IDs de rastreamento e span, bem como contexto* definido pelo usuário) nos spans. O OpenTelemetry desenvolve essa prática aos logs incluindo TraceId e SpanId nos eventos de log.

O que é contexto*? são informações importantes do sistema, estado do sistema, configuração, metadados de telemetria e outras informações que ajudam a entender o funcionamento e o comportamento do sistema.

Cuidado com dados sensíveis, os registros de log não podem conter dados sensíveis como dados de usuário, chaves de segurança, segredos, etc.
Padrão de atributos de logs, em ambientes distribuídos cada equipe adota uma linguagem de programação para desenvolver seus sistemas. Cada linguagem possui bibliotecas e frameworks para instrumentar log e cada uma pode conter campos e formatos diferentes. Por exemplo, em um sistema desenvolvido em Python o campo http status code pode ser http.status_code enquanto na linguagem golang esse mesmo campo pode ser http.statuscode, essas diferenças entre atributos de log pode dificultar pesquisas no vendor de observabilidade.

Estas são apenas algumas recomendações propostas pela grande maioria dos serviços que coletam, processam, transmitem e armazenam dados de telemetria. É importante salientar que cada organização pode adotar um padrão próprio, conforme o negócio.

A seguir temos um exemplo de um log em JSON, isso ajuda a entender o modelo de dados dos eventos gerados por sistemas distribuídos. O objetivo do log é registrar, o que aconteceu e quando aconteceu.

{
  "Timestamp": 1687520180000, //carimbo data e hora no formato epoch                             
  "Attributes": { //atributos do evento gerado pelo sistema
    "http.scheme": "https",
    "http.method": "post",
    "http.status_code": 500,
    "http.url": "https://rapadura.com",
    "http.target":"/order",
    "my.custom.application.tag": "blablabla",
  },
  "Resource": { //informações da origem que gerou o evento
    "service.name": "rapadura-shop",
    "service.version": "v1.0.0",
    "k8s.cluster.name": "k8s-cluster-prd",
    "k8s.namespace": "app-rapadura",
    "k8s.pod.uid": "1138528c-c36e-11e9-a1a7-42010a800198",
  },
  "TraceId": "f4dbb3edd765f620", //informações para correlacionar o log ao trace
  "SpanId": "43222c2d51a7abe3",
  "SeverityText": "ERROR", //categoria do log
  "SeverityNumber": 17,
  "Body": "I like rapadura" //mensagem do acontecimento
}

Trace

Também conhecido como rastreamento, trace ou tracing, possibilita acompanhar o fluxo e a condição de uma transação. Segundo a documentação do OpenTelemetry, os traces fornece uma visão geral do caminho e o que acontece quando uma solicitação é feita em um sistema.
O trace conta a história da interação entre sistemas distribuídos, uma transação pode interagir com vários sistemas o trace possibilita identificar qual sistema está causando a falha.

A imagem acima representa um trace, e cada interação nessa requisição é chamada de span (período), cada trace e cada span possui um identificador único, são conhecidos como traceid e spanid, esses valores serve para identificar as interações na transação.
Na figura é possível perceber que o tempo total dessa requisição foi de 320 milissegundos, bem como quais componentes essa transação interagiu e o tempo de interação.

Os registros de trace auxiliam as equipes a compreender as dependências entre sistemas, aumento de latência, onde a requisição falhou, o trace ajuda a atribuir um possível problema a um o serviço específico.

Métrica

Métrica é uma representação numérica de uma informação em relação ao tempo. As métricas fornecem uma visão geral da integridade do sistema ou ambiente.

As métricas também são úteis para escalar o ambiente para atender a demanda do sistema, sendo muito utilizados para criar alerta e são mais adequadas para criar dashboards.

A métrica é composta por um nome da métrica (por exemplo, http_requests_total), o registro de data e hora (com precisão em milissegundos), pelo valor da métrica (um valor float64) e tags, é a possibilidade de agregação da métrica (por exemplo, solicitações HTTP com método POST).

Após a coleta, as métricas apresentam maior flexibilidade para cálculos matemáticos, probabilidade, estatistificas, amostragem, etc. Essas características tornam as métricas mais adequadas para demostrar a integridade do sistema.

Conclusão

Os três pilares da observabilidade trace, métrica e log são complementares para compreender o comportamento e do desempenho de um sistema.

Como Brian Knox menciona:

The goal of an Observability team is not to collect logs, metrics, or traces. It is to build a culture of engineering based on facts and feedback, and then spread that culture within the broader organization.

A observabilidade não se limita a trace, log e métrica, trata-se de construir uma cultura onde as equipes sejam guiadas por fatos e comunicação.

Referências

Observabilidade e Monitoramento

Ezzio Moreira — Tue, 20 Jun 2023 11:54:17 +0000

Revisado por: Fernanda Santos Barros

Resolver conflitos de serviços entre ambientes distintos, escalar sistemas rapidamente e ter sistemas menos acoplados são alguns dos benefícios de se adotar uma arquitetura de sistemas distribuídos. Tais sistemas possuem uma alta complexidade, necessitando de um esforço adicional para manter a sua arquitetura.

Em sistemas distribuídos, a questão mais complexa em termos de depuração não é compreender o código em execução, mas sim identificar onde o código com problema está localizado.

Pensando nisso, como as equipes poderiam garantir o máximo de confiabilidade desses sistemas?

Como seria possível identificar rapidamente qual sistema está causando falha ou lentidão no processamento das requisições?

Como os times poderiam melhorar esses sistemas em um ambiente complexo?

Sistemas distribuídos podem conter inúmeros serviços em execução, assim, é primordial garantir a confiabilidade e a segurança de todos os recursos.

Esse formato de sistema possui algumas características importantes, são elas:

Compartilhamento de recursos: conforme o ambiente de execução do microsserviço, pode ocorrer o compartilhamento de recursos. O ambiente Kubernetes pode ser um exemplo, nele ocorre o compartilhamento de CPU, memória, disco, rede e outros.

Processo simultâneo: um cluster é composto por diversos hosts; dessa forma um mesmo microsserviço pode existir em diversos hosts ao mesmo tempo.

Escalonamento: um microsserviço, ou recurso computacional, deve ser capaz de aumentar ou diminuir a sua capacidade conforme a utilização.

Resiliência: microsserviços são projetados para serem tolerantes à falha.

Em suma, devido à quantidade de componentes, a complexidade do ambiente e a imprevisibilidade, torna-se evidente a necessidade de utilizar os conceitos e as ferramentas que a engenharia de confiabilidade nos oferece. Sendo assim, é
importante destacar dois conceitos: observabilidade e monitoramento.

O que é observabilidade?

Observabilidade é a capacidade de achar repostas para perguntas que ainda não temos:
by Juraci Paixão

A observabilidade nada mais é do que a capacidade de compreender o estado interno de um sistema com base em seu comportamento.
Para um sistema ser considerado minimamente observável é necessário cumprir alguns requisitos, sendo eles: permitir a coleta de logs, métricas e traces distribuídos.

Observabilidade é a capacidade de preservar o máximo de contexto possível em torno de qualquer solicitação, permitindo a reconstrução do ambiente e das circunstâncias que provocaram um novo ponto de falha.

Conforme essa definição, alguns pontos que podem surgir em um sistema observável:

Por qual motivo esse(s) cliente(s) apresenta(am) uma alta latência nas requisições do sistema X?
Quais são os serviços envolvidos em uma transação específica?
Quais são os impactos de uma alteração no ecossistema de microserviço?

Os engenheiros que praticam a observabilidade conseguem questionar o sistema fazendo perguntas exploratórias, usando as respostas para conduzir a outras investigações.

Essas simples perguntas auxiliam no processo de investigação da causa raiz de possíveis problemas e permitem a obtenção de insights sobre o comportamento dos sistemas. Tais questionamentos podem ser realizados em diferentes estágios do ciclo de vida do sistema, de acordo com o contexto da situação enfrentada.

O que é o monitoramento?

Monitoramento é a prática de obter resposta rápida para perguntas frequentes.
by Juraci Paixão

O monitoramento se concentra em coletar e analisar dados de telemetria, visando garantir o desempenho e a disponibilidade do sistema.

O monitoramento tradicional é totalmente reativo, e se concentra em métrica, alerta e dashboards. Dashboard repleta de gráficos, e talvez não sabemos o que todos os gráficos realmente dizem.

Seguindo esse conceito, um sistema monitorado é capaz de produzir respostas para várias perguntas previamente conhecidas. Dentre elas, temos:

Como estão os níveis de consumo de recursos computacional (CPU, memória, disco, rede)?
Quais são as taxas de erros da última hora?
Qual é o tempo médio das requisições?
Existe algum alerta ativo?

As respostas para esses questionamentos nos permitem determinar, em tempo real, qual o estado do sistema e como está sendo o seu desempenho. Essas informações são cruciais em análises de causa raiz e na definição de ações corretivas.

Conclusão

O monitoramento é para os desconhecidos conhecidos, a observabilidade é para os desconhecidos.

Monitoramento e observabilidade são conceitos que se complementam para garantir um sistema confiável. O primeiro nos fornece uma abordagem mais reativa, com base em números concretos, enquanto o outro nos permite realizar uma análise mais profunda e estratégica do sistema e do negócio.
Com essa união, torna-se possível que as equipes de operações e engenharia atuem com mais rapidez e eficiência nas inconsistências que ocorrem durante a utilização de sistemas distribuídos.

Referências:

Controle de fluxo com Python

Ezzio Moreira — Wed, 31 May 2023 23:40:25 +0000

Na ciência da computação, estrutura de seleção (ou expressão condicional, ou construção condicional) é uma estrutura de desvio do fluxo de controle presente em linguagens de programação que realiza diferentes ações dependendo se a condição é verdadeira ou falsa, a expressão é processada e transformada em um valor booleano.

Comando if

O controle de fluxo em Python é realizado por meio de estruturas condicionais, como o if e o else. Essas estruturas permitem que você execute diferentes blocos de código com base em condições específicas.

Aqui está um exemplo básico de controle de fluxo em Python usando if e else:

A condição 3 é maior que 2, é verdadeira?
- Se sim, imprima Funciona!
- Se não, imprima 3 é maior que 2

if 3 > 2:
    print('Funciona!')
else:
    print('3 é maior que 2')

Perceba que existe uma edentação de quatro espaços do no print em relação ao if.

É possível utilizar o elif (abreviação de "else if") para verificar múltiplas condições em uma estrutura condicional.

Veja um exemplo:

idade = int(input("Digite sua idade: "))

if idade < 16:
    print("Voto não permitido!")
elif idade >= 16 and idade < 18 or idade < 65:
    print("Voto obrigatório!")
else:
    print("Voto opcional!")

Nesse exemplo, o Python espera que usuário entre com um valor que representa sua idade.

Se, a idade for menor que 16.
- Imprima, Voto não permitido!
Senão, idade for maior ou igual a 16 e menos ou igual a 65 anos.
- Imprima Voto obrigatório!
Outro, se as condições if e elfi forem falsas.
- Imprima, Voto opcional!

Observability in Kong API Gateway

Ezzio Moreira — Wed, 31 May 2023 11:03:30 +0000

This article explains some points about monitoring and observability of the Kong API Gateway system through the three pillars of observability: metrics, trace, and logs.

Metrics

Kong has the Prometheus plugin, which exports service metrics through the endpoint http://endpoint-kong:8001/metrics. These metrics provide insight into the performance of the service.

To configure metric collection: https://docs.konghq.com/hub/kong-inc/prometheus/

Trace

Kong has the OpenTelemetry plugin, which sends trace and spans generated by the service to an HTTP or gRPC endpoint of the OpenTelemetry collector. The OpenTelemetry collector receives this data, processes it, and sends it to the vendor for observability.

It is necessary to declare the environment variable KONG_OPENTELEMETRY_TRACING: all, to enable OTEL tracing on Kong, another imported variable is KONG_OPENTELEMETRY_TRACING_SAMPLING_RATE: 1.0, which defines the proportion of traces sample collected and sent to the vendor of observability.

To configure trace collection: https://docs.konghq.com/hub/kong-inc/opentelemetry/

Logs

Kong offers many plugins for collecting, processing, and sending logs. I can recommend using a Fluentbit sidecar for collecting these logs and send to an observability provider.

It is possible to use the NGINX HTTP logs module to help us define which attributes will be added to the logs.

Module ngx_http_log_module: http://nginx.org/en/docs/http/ngx_http_log_module.html

To configure logs collection: https://docs.konghq.com/hub/?category=logging

Operadores em Python

Ezzio Moreira — Wed, 31 May 2023 10:53:41 +0000

Em Python existe uma grande variedade de operadores lógicos, operadores são símbolos que representa uma expressão, soma, multiplicação, maior, menor ou igual, etc.

Operadores Aritméticos

Python suporta cálculos matemáticos mistos de forma simples.

Exemplos de expressões matemáticas em Python.

Operador	Nome	Descrição
x + y	Adição	Realiza a soma de x e y.
x - y	Subtração	Realiza a subtração de x e y.
x * y	Multiplicação	Realiza a multiplicação de x e y.
x / y	Divisão	Realiza a divisão de x e y.
x % y	Resto	Retorna o resto da divisão de x e y.
x ** y	Exponencial	Retorna o resultado de x elevado a y.

Utilização de cada operador aritmético:

Soma (+):

x = 5
y = 3
soma = x + y
print(soma)  # Saída: 8

Subtração (-):

x = 5
y = 3
subtracao = x - y
print(subtracao)  # Saída: 2

Multiplicação (*):

x = 5
y = 3
multiplicacao = x * y
print(multiplicacao)  # Saída: 15

Divisão (/):

x = 5
y = 3
divisao = x / y
print(divisao)  # Saída: 1.6666666666666667

Divisão inteira (//):

x = 5
y = 3
divisao_inteira = x // y
print(divisao_inteira)  # Saída: 1

Resto da divisão (%) ou módulo:

x = 5
y = 3
resto_divisao = x % y
print(resto_divisao)  # Saída: 2

Potência ():**

x = 2
y = 3
potencia = x ** y
print(potencia)  # Saída: 8

Operadores de Comparação

Existe oito operadores de comparação no Python, comparações podem ser encadeadas arbitrariamente; por exemplo, x < y <= z é equivalente a x < y and y <= z.

Operadores de comparação em Python.

Operador	Nome	Descrição
==	Igual a	True se um valor é igual ao outro.
!=	Diferente de	True se um valor é diferente ao outro.
>	Maior que	True se um valor é maior que outro
>=	Maior ou Igual	True se um valor é maior ou igual ao outro.
<	Menor que	True se um valor é menor que outro.
<=	Menor ou Igual	True se um valor é menor ou igual ao outro.

Utilização de cada operador comparação:

Igual (==):

a = 5
b = 3
resultado = a == b
print(resultado)  # Saída: False

Diferente (!=):

a = 5
b = 3
resultado = a != b
print(resultado)  # Saída: True

Maior que (>):

a = 5
b = 3
resultado = a > b
print(resultado)  # Saída: True

Menor que (<):

a = 5
b = 3
resultado = a < b
print(resultado)  # Saída: False

Maior ou igual que (>=):

a = 5
b = 3
resultado = a >= b
print(resultado)  # Saída: True

Menor ou igual que (<=):

a = 5
b = 3
resultado = a <= b
print(resultado)  # Saída: False

Operadores Lógicos

Os operadores lógicos servem para unir duas ou mais expressões. Isso é feito utilizando as palavras reservadas AND (e), OR (ou) e NOT (não).

Operador	Nome	Descrição
and	E	Retorna True se as duas expressões forem verdadeiras
or	OU	Retorna True se uma das expressões for verdadeira
not	NÃO	Inverte o resultado da expressão

Utilização de cada operador lógicos:

x = True
y = False

print(x and y)  # Saída: False
print(x or y)   # Saída: True
print(not x)    # Saída: False

Conclusão

Operadores em Python são símbolos especiais que realizam operações em valores ou variáveis. Eles permitem realizar cálculos, comparações e operações lógicas.

Forem: Ezzio Moreira

OpenTelemetry Collector ElasticBeanStalk

1. Criar a Pasta .ebextensions

2. Baixar o Binário do OpenTelemetry Collector

3. Criar o Serviço Linux para OtelColl

4. Copiar o Arquivo de Configuração

5. Iniciar o Serviço

Resumo

Referencia

Stack Grafana deployed on AWS ECS -Part 1 - Create a Cluster

Pre-Requirements

AWS VPC

ECS Cluster Type

Create ECS Cluster

References

Siglas da Observabilidade SLI, SLO, SLE, MTTA, MTTR, MTBF e MTTF

SLA, SLO e SLI

SLA: Acordos de Nível de Serviço

SLO: Objetivos de Nível de Serviço

SLI: Indicadores de Nível de Serviço

Exemplo

MTTA, MTTR, MTBF e MTTF

MTTA (Mean Time To Acknowledge) Tempo Médio para Reconhecimento

MTTR (Mean Time To Repair) Tempo Médio para Reparo

MTBF (Mean Time Between Failures) Tempo Médio entre Falhas

MTTF (Mean Time To Failure) Tempo Médio sem Falhas

Conclusão

Referências

Conceitos OpenTelemetry

O que é OpenTelemetry?

Conceitos do OpenTelemetry

Signals

Instrumentation

Semantic Conventions

Sampling

Conclusão

Referências:

Três Pilares da Observabilidade

Log

Trace

Métrica

Conclusão

Referências

Observabilidade e Monitoramento

O que é observabilidade?

O que é o monitoramento?

Conclusão

Referências:

Controle de fluxo com Python

Comando if

Observability in Kong API Gateway

Metrics

Trace

Logs

Operadores em Python

Operadores Aritméticos

Utilização de cada operador aritmético:

Operadores de Comparação

Utilização de cada operador comparação:

Operadores Lógicos

Utilização de cada operador lógicos:

Conclusão

Referências

1. Criar a Pasta `.ebextensions`