A telemetria tornou-se essencial para garantir a confiabilidade e a performance dos sistemas atuais. É por meio dela que conseguimos verificar se nossas pipelines de CI/CD estão executando conforme esperado, se nossas aplicações mantêm os níveis de performance adequados e, crucialmente, quando algo dá errado, é através dos dados telemétricos que identificamos rapidamente os componentes responsáveis pelo problema.

Além do aspecto operacional, a telemetria possui um valor estratégico muitas vezes subestimado: ela permite quantificar métricas em nível empresarial, transformando dados técnicos em insights de negócio. Mais que isso, com as técnicas adequadas de análise estatística, podemos detectar anomalias de forma proativa, antecipando problemas antes que impactem usuários ou processos críticos.

Níveis de Registro

Para suportar vários modelos de uso, com dados de diferentes lugares, temos diferentes níveis de registro, dos quais alguns podem disparar alertas e outros não há necessidade:

• Nível DEPURAÇÃO: Neste nível, as informações são tudo o que acontece no programa, mas frequentemente usadas durante a depuração. Frequentemente os registros da depuração são desabilitados na produção ou habilitados temporariamente durante a solução de problemas.

  Nível INFORMAÇÃO: As informações deste nível consistem em ações tomadas pelo usuário ou específicas do sistema (por exemplo, "iniciar transação de cartão de crédito").

  Nível AVISO: As informações neste nível relatam condições que podem se tornar um erro (por exemplo, uma chamada de banco de dados demorando mais do que um tempo predefinido). Elas provavelmente iniciarão um alerta e uma solução de problemas, enquanto outras mensagens de registro podem nos ajudar a entender melhor o que levou a essa condição.

  Nível ERRO: As informações neste nível focam em condições de erro (por exemplo, falhas de chamada de API, condições de erro interno).

  Nível FATAL: As informações neste nível relatam quando devemos encerrar (por exemplo, um daemon de rede não consegue vincular um soquete de rede).

Lacunas que a Telemetria pode detectar e ajudar a resolver

• Nível empresarial: Exemplos incluem o número de transações de vendas, lucro de transações de vendas, inscrições de usuário, taxa de rotatividade, resultados de testes A/B etc.

• Nível de aplicativo: Exemplos incluem tempos de transação, tempos de resposta de usuário, falhas de aplicativo etc.

• Nível de infraestrutura (por exemplo, banco de dados, sistema operacional, rede, armazenamento): Exemplos incluem tráfego de servidor web, carga de CPU, utilização de disco etc.

• Nível de software cliente (por exemplo, JavaScript no navegador cliente, aplicativo móvel): Exemplos incluem erros e falhas de aplicativo, tempos de transação medidos pelo usuário etc.

  Nível de pipeline de implementação: Exemplos incluem status do pipeline de build (por exemplo, vermelho ou verde para nossos vários conjuntos de testes automatizados), tempos de execução de implantação, mudança, frequências de implementação, promoções de ambiente de teste e status de ambiente.

O livro destaca problemas comuns que surgem quando os dados não seguem uma distribuição gaussiana (normal). Embora o uso de médias e desvio padrão seja extremamente útil em muitos casos, essas técnicas nem sempre geram os resultados desejados para diversos conjuntos de dados. Por exemplo, você pode enfrentar um cenário em que alertas são constantemente disparados ao usar a regra dos 3 desvios padrão, gerando muitos falsos positivos.

Entendendo o Desvio Padrão: O desvio padrão é uma medida estatística que indica o quanto os valores de um conjunto de dados se dispersam em relação à média. Em uma distribuição normal, aproximadamente 68% dos dados estão dentro de 1 desvio padrão da média, 95% dentro de 2 desvios padrão, e 99,7% dentro de 3 desvios padrão. No contexto de monitoramento, a regra dos 3 desvios padrão é frequentemente usada para identificar anomalias: valores que ultrapassam 3 desvios padrão da média são considerados outliers. No entanto, quando os dados não seguem uma distribuição normal, essa abordagem pode gerar alertas excessivos e imprecisos. Ferramentas que possuem essa técnica: Praticamente todas as ferramentas de monitoramento modernas suportam cálculo de desvio padrão.

Agora que sabemos quais dados são relevantes para o nosso ambiente e como classificá-los em caso de falhas, o livro apresenta uma visão crucial sobre identificação de problemas que realmente expandiu minha mente. O monitoramento eficaz não se resume apenas a gerar alertas, um dos maiores desafios que muitas empresas enfrentam hoje é o volume excessivo de incidentes abertos que, na realidade, não representam problemas reais. Essa "fadiga de alertas" acaba fazendo com que a equipe de operações descarte ou ignore notificações, incluindo aquelas que sinalizam problemas genuínos.

O monitoramento inteligente vai além de simplesmente disparar um alerta quando a CPU ultrapassa 90%. Trata-se de identificar anomalias ou padrões de uso de recursos que historicamente não ocorriam. Por exemplo, um banco de dados que normalmente recebe 100 acessos por minuto e subitamente cai para 80 acessos pode indicar um problema, mesmo que esse valor não ultrapasse nenhum limite pré-estabelecido. O livro explora como a estatística pode nos aproximar dessa identificação de problemas reais.

Técnica de Suavização (Smoothing): Uma das técnicas apresentadas é a "suavização", que envolve o uso de médias móveis para transformar dados ruidosos em tendências mais claras. A suavização calcula a média de cada ponto em relação a todos os outros dados dentro de uma janela de tempo específica. Isso reduz flutuações de curto prazo e destaca padrões de longo prazo. Por exemplo, em vez de analisar valores individuais de CPU a cada segundo (que podem variar drasticamente), você calcula a média dos últimos 5 ou 10 minutos, obtendo uma visão mais estável do comportamento do sistema. Essa técnica é especialmente útil para eliminar "ruído" nos dados e facilitar a identificação de tendências reais. Ferramentas que possuem essa técnica: Grafana, Prometheus, Datadog, Graphite, NewRelic, Dynatrace, InfluxDB, Elasticsearch/Kibana.

Teste de Kolmogorov-Smirnov: Outro método abordado, utilizado em ferramentas como Grafana e Graphite, é o teste de Kolmogorov-Smirnov (K-S). Esse é um teste estatístico não-paramétrico usado para comparar duas distribuições de dados e determinar se elas são significativamente diferentes. No contexto de monitoramento, o teste K-S é particularmente útil para analisar métricas periódicas ou sazonais. Por exemplo, você pode comparar o padrão de tráfego web de hoje com o padrão de tráfego de terças-feiras anteriores. Se o teste K-S indicar uma diferença estatisticamente significativa entre as distribuições, isso pode sinalizar uma anomalia que merece investigação. Essa abordagem é mais sofisticada do que simplesmente comparar médias, pois considera a forma completa da distribuição dos dados. Ferramentas que possuem essa técnica: Grafana, Graphite, NewRelic, Dynatrace, Datadog.

O livro também apresenta diversos casos de uso dessas ferramentas em diferentes empresas e cenários reais, demonstrando sua aplicabilidade prática.

Uma ideia interessante proposta é a implementação de uma arquitetura de monitoramento inteligente: você pode usar ferramentas tradicionais como Zabbix, Prometheus ou outras para coleta de métricas. Esses dados são então enviados para uma aplicação desenvolvida em Python ou R, que realiza processamento estatístico avançado. Através dessa análise estatística, a aplicação verifica se existe uma anomalia real antes de disparar um alerta. Essa abordagem híbrida combina a robustez das ferramentas de monitoramento estabelecidas com a flexibilidade e o poder da análise estatística, resultando em alertas mais precisos e significativos, reduzindo a fadiga de alertas e melhorando a eficiência operacional.

Recomendações por Cenário

Implementação Básica:

Prometheus + Grafana

• Desvio padrão: ✅ Nativo

• Suavização: ✅ Nativo

• K-S: ⚠️ Requer integração

Análise Estatística Avançada:

Prometheus/Zabbix (coleta) → Python/R (análise) → Grafana (visualização)

• Todas as três técnicas: ✅ Totalmente suportadas

• Controle completo sobre algoritmos

• Flexibilidade máxima

Solução Enterprise com IA/ML:

Dynatrace ou Datadog

• Desvio padrão: ✅ Automático

• Suavização: ✅ Automática

• K-S ou similar: ✅ Algoritmos proprietários de ML

Para Stack ELK:

Elasticsearch + Kibana + Machine Learning

• Todas as técnicas através de agregações e ML

• Ótimo para logs e métricas combinados

Nos dois últimos artigos publicados, exploramos a auto-instrumentação e a instrumentação utilizando o OpenTelemetry Operator no Kubernetes. Agora, vamos abordar um caso de teste prático usando a instrumentação manual do OpenTelemetry.

A principal diferença desta abordagem em relação às anteriores é que ela nos proporciona controle total sobre os dados de telemetria da nossa aplicação. Com a instrumentação manual, conseguimos capturar apenas as métricas e traces realmente relevantes para o contexto do negócio, como por exemplo: verificar se uma função crítica está sendo executada dentro do tempo esperado, monitorar etapas específicas de um fluxo de trabalho ou adicionar contexto personalizado aos spans.

Essa granularidade permite uma observabilidade mais precisa e alinhada com as necessidades específicas da sua aplicação.

Outro ponto importante é que, na sua empresa, o backend que recebe os dados de observabilidade pode mudar ao longo do tempo. Por exemplo, você pode estar usando o Dynatrace hoje e, meses depois, migrar para o New Relic. Essa mudança normalmente exigiria um retrabalho significativo na instrumentação da aplicação. No entanto, com o OpenTelemetry, é possível instrumentar sua aplicação uma única vez e, posteriormente, apenas reconfigurar o destino dos dados (backend). Isso reduz drasticamente o retrabalho e aumenta a flexibilidade na escolha de ferramentas de observabilidade.

Estrutura básica da implementação

Existem dois componentes fundamentais quando falamos de instrumentação manual: API e SDK.

API: é responsável por instrumentar o código da aplicação. Através da API, você consegue criar e manipular estruturas de observabilidade como spans, subspans (spans filhos), definir atributos personalizados, registrar eventos de erro e incrementar contadores de métricas. Em resumo, a API fornece as ferramentas para capturar os dados de telemetria diretamente no código.

SDK: fazendo uma analogia, o SDK funciona como o "motor" do OpenTelemetry. É através dele que os dados instrumentados pela API são recebidos, processados, enriquecidos e, finalmente, exportados para o OpenTelemetry Collector ou diretamente para um backend de observabilidade.

Essa separação entre API e SDK segue o princípio de responsabilidade única: a API se preocupa apenas com a coleta dos dados, enquanto o SDK cuida de todo o pipeline de processamento e exportação.

Link do repositório do projeto: htttps://github.com/joaochiroli/otel-instrumentacao-python/pull/new/instrumentacao-manual

Passo 1: Instalar as dependências necessárias

Primeiro, você precisa adicionar os pacotes OpenTelemetry ao seu requirements.txt:

flask 
Flask-SQLAlchemy
psycopg2-binary
flask_sqlalchemy
opentelemetry-api
opentelemetry-sdk
# Instrumentação automática para Flask e SQLAlchemy
opentelemetry-instrumentation-flask
opentelemetry-instrumentation-sqlalchemy
# Exporters (escolha baseado no seu backend)
opentelemetry-exporter-otlp-proto-grpc  # Para gRPC
opentelemetry-exporter-otlp-proto-http  # Para HTTP
# Opcional mas recomendado
opentelemetry-instrumentation-logging

Passo 2: Estrutura básica da instrumentação

Vou criar um arquivo separado otel_config.py para organizar melhor:

from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.sdk.resources import Resource, SERVICE_NAME, SERVICE_VERSION
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.sqlalchemy import SQLAlchemyInstrumentor
import os
import logging

logger = logging.getLogger(__name__)

def init_telemetry(app, db_engine):
    """
    Inicializa toda a instrumentação OpenTelemetry
    """

    # Passo 2.1: Criar o Resource (identifica seu serviço)
    resource = Resource.create({
        SERVICE_NAME: os.getenv("OTEL_SERVICE_NAME", "flask-app"),
        SERVICE_VERSION: "1.0.0",
        "environment": os.getenv("ENVIRONMENT", "development"),
        "team": "platform-team"
    })

    # Passo 2.2: Configurar Traces
    trace_provider = TracerProvider(resource=resource)

    # Configurar o exporter para traces
    otlp_trace_exporter = OTLPSpanExporter(
        endpoint=os.getenv("OTEL_EXPORTER_OTLP_ENDPOINT", "http://localhost:4317"),
        insecure=True  # Use False em produção com TLS
    )

    # Adicionar o processor
    trace_provider.add_span_processor(
        BatchSpanProcessor(otlp_trace_exporter)
    )

    # Registrar o provider globalmente
    trace.set_tracer_provider(trace_provider)

    # Passo 2.3: Configurar Metrics
    metric_reader = PeriodicExportingMetricReader(
        OTLPMetricExporter(
            endpoint=os.getenv("OTEL_EXPORTER_OTLP_ENDPOINT", "http://localhost:4317"),
            insecure=True
        ),
        export_interval_millis=60000  # Exporta a cada 60 segundos
    )

    metric_provider = MeterProvider(
        resource=resource,
        metric_readers=[metric_reader]
    )

    metrics.set_meter_provider(metric_provider)

    # Passo 2.4: Instrumentação automática
    FlaskInstrumentor().instrument_app(app)
    SQLAlchemyInstrumentor().instrument(engine=db_engine)

    logger.info("OpenTelemetry instrumentation initialized successfully")

    return trace.get_tracer(__name__), metrics.get_meter(__name__)

Passo 3: Modificar o app.py para usar a instrumentação

Aqui está como integrar no seu código:

import logging
import os
from flask import Flask, request, jsonify
from flask_sqlalchemy import SQLAlchemy
from datetime import datetime
import sys
from sqlalchemy.sql import text

# ============================================
# IMPORTAR OpenTelemetry
# ============================================
from opentelemetry import trace
from opentelemetry.trace import Status, StatusCode

app = Flask(__name__)

# Configuração do PostgreSQL via variáveis de ambiente
DB_USER = os.getenv('POSTGRES_USER')
DB_PASSWORD = os.getenv('POSTGRES_PASSWORD')
DB_HOST = os.getenv('POSTGRES_HOST')
DB_PORT = os.getenv('POSTGRES_PORT')
DB_NAME = os.getenv('POSTGRES_DB')

DATABASE_URL = f'postgresql://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}'

app.config['SQLALCHEMY_DATABASE_URI'] = DATABASE_URL
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False

# Configure logging
logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    handlers=[
        logging.FileHandler('app.log'),
        logging.StreamHandler(sys.stdout)
    ]
)

logger = logging.getLogger(__name__)
logger.info(f"Database configuration: Host={DB_HOST}, Port={DB_PORT}, DB={DB_NAME}, User={DB_USER}")

# Inicializar o banco de dados
db = SQLAlchemy(app)

# ============================================
# MODELS (definir antes de init_telemetry)
# ============================================
class User(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(100), nullable=False)
    created_at = db.Column(db.DateTime, default=datetime.utcnow)

    def to_dict(self):
        return {
            'id': self.id,
            'name': self.name,
            'created_at': self.created_at.isoformat()
        }

class Message(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    message = db.Column(db.Text, nullable=False)
    ip_address = db.Column(db.String(50))
    created_at = db.Column(db.DateTime, default=datetime.utcnow)

    def to_dict(self):
        return {
            'id': self.id,
            'message': self.message,
            'ip_address': self.ip_address,
            'created_at': self.created_at.isoformat()
        }

class RequestLog(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    method = db.Column(db.String(10), nullable=False)
    endpoint = db.Column(db.String(200), nullable=False)
    ip_address = db.Column(db.String(50))
    status_code = db.Column(db.Integer)
    created_at = db.Column(db.DateTime, default=datetime.utcnow)

    def to_dict(self):
        return {
            'id': self.id,
            'method': self.method,
            'endpoint': self.endpoint,
            'ip_address': self.ip_address,
            'status_code': self.status_code,
            'created_at': self.created_at.isoformat()
        }

# ============================================
# INICIALIZAR TELEMETRY DENTRO DO CONTEXTO
# ============================================
from otel_config import init_telemetry

# CRITICAL FIX: Inicializar dentro do app context
with app.app_context():
    tracer, meter = init_telemetry(app, db.engine)

    # Criar tabelas
    try:
        db.create_all()
        logger.info("Database tables created successfully")
    except Exception as e:
        logger.error(f"Error creating database tables: {e}")

# Criar métricas customizadas (fora do context é ok)
request_counter = meter.create_counter(
    name="http_requests_total",
    description="Total de requisições HTTP",
    unit="1"
)

message_counter = meter.create_counter(
    name="messages_created_total",
    description="Total de mensagens criadas",
    unit="1"
)

user_counter = meter.create_counter(
    name="users_created_total",
    description="Total de usuários criados",
    unit="1"
)

# ============================================
# ROUTES
# ============================================

@app.route('/')
def hello():
    logger.info("Hello endpoint accessed")
    return "Hello, World!"

@app.route('/user/<name>')
def get_user(name):
    with tracer.start_as_current_span("get_user_operation") as span:
        span.set_attribute("user.name", name)
        span.set_attribute("user.name.length", len(name))

        logger.info(f"User endpoint accessed for: {name}")

        try:
            if len(name) < 2:
                span.set_status(Status(StatusCode.ERROR, "Name too short"))
                raise ValueError("Name too short")

            with tracer.start_as_current_span("database.check_user"):
                user = User.query.filter_by(name=name).first()

            if not user:
                with tracer.start_as_current_span("database.create_user"):
                    user = User(name=name)
                    db.session.add(user)
                    db.session.commit()
                    logger.info(f"New user created: {name}")

                    user_counter.add(1, {"operation": "create"})
                    span.add_event("user_created", {"user_id": user.id})

            span.set_attribute("user.id", user.id)
            span.set_status(Status(StatusCode.OK))

            return jsonify({
                "message": f"Hello, {name}!",
                "user": user.to_dict()
            })

        except ValueError as e:
            logger.error(f"Validation error in get_user: {e}")
            return jsonify({"error": "Name must be at least 2 characters"}), 400
        except Exception as e:
            span.set_status(Status(StatusCode.ERROR, str(e)))
            span.record_exception(e)
            logger.error(f"Database error in get_user: {e}")
            return jsonify({"error": "Internal server error"}), 500

@app.route('/submit', methods=['POST'])
def submit_data():
    with tracer.start_as_current_span("submit_data_operation") as span:
        logger.info("Submit endpoint accessed")

        try:
            data = request.get_json()

            if not data:
                span.set_status(Status(StatusCode.ERROR, "No JSON data"))
                return jsonify({"status": "error", "message": "No JSON data received"}), 400

            if 'message' not in data:
                span.set_status(Status(StatusCode.ERROR, "Missing message field"))
                return jsonify({"status": "error", "message": "Missing 'message' field"}), 400

            span.set_attribute("message.length", len(data['message']))
            span.set_attribute("request.ip", request.remote_addr)

            with tracer.start_as_current_span("database.insert_message"):
                message_entry = Message(
                    message=data['message'],
                    ip_address=request.remote_addr
                )
                db.session.add(message_entry)
                db.session.commit()

                span.set_attribute("message.id", message_entry.id)

            message_counter.add(1, {"source": "api"})

            span.add_event("message_saved", {
                "message_id": message_entry.id,
                "timestamp": datetime.now().isoformat()
            })

            span.set_status(Status(StatusCode.OK))

            logger.info(f"Successfully processed and saved message: {data['message']}")
            return jsonify({
                "status": "success",
                "received_message": data['message'],
                "message_id": message_entry.id,
                "response": "Data received and saved successfully!",
                "timestamp": datetime.now().isoformat()
            })

        except Exception as e:
            span.set_status(Status(StatusCode.ERROR, str(e)))
            span.record_exception(e)
            logger.error(f"Unexpected error in submit_data: {e}")
            db.session.rollback()
            return jsonify({"status": "error", "message": "Internal server error"}), 500

@app.before_request
def before_request_telemetry():
    request_counter.add(1, {
        "method": request.method,
        "endpoint": request.endpoint or "unknown"
    })

@app.route('/health')
def health_check():
    logger.info("Health check accessed")
    try:
        db.session.execute(text('SELECT 1'))
        db_status = "connected"
        user_count = User.query.count()
        message_count = Message.query.count()
        log_count = RequestLog.query.count()
    except Exception as e:
        db_status = f"error: {str(e)}"
        user_count = message_count = log_count = 0

    return jsonify({
        "status": "healthy",
        "database": db_status,
        "database_stats": {
            "users": user_count,
            "messages": message_count,
            "request_logs": log_count
        },
        "timestamp": datetime.now().isoformat(),
        "version": "1.0.0"
    })

if __name__ == '__main__':
    host = os.getenv('FLASK_HOST', '0.0.0.0')
    port = int(os.getenv('FLASK_PORT', '5000'))

    logger.info(f"Starting Flask application on {host}:{port}...")
    app.run(debug=False, host=host, port=port)

Os dados podem ser vistos acessando o Jaeger

Outros arquivos usados no projeto

Dockerfile

FROM python:3.9-slim

# Defina o diretório de trabalho
WORKDIR /app

# Copie os arquivos necessários para o diretório de trabalho
COPY . /app

# Instale as dependências
RUN pip install -r requirements.txt

# Configura o OTLP
RUN opentelemetry-bootstrap -a install

# Exponha a porta que a aplicação vai rodar
EXPOSE 5000

# Comando para rodar a aplicação
CMD ["opentelemetry-instrument", "python", "app.py"]

Docker-compose

services:
  db:
    image: postgres:14.15
    container_name: postgres-db
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: simple_app
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck: # verifica se o db esta pronto para os outros servicos
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 10
    networks:
      - app-network
  app:
    build: .
    container_name: flask-app
    volumes:
      - .:/app
    ports:
      - "5000:5000"
    environment:
      POSTGRES_HOST: db
      POSTGRES_PORT: 5432
      POSTGRES_DB: simple_app
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      FLASK_ENV: development
      FLASK_DEBUG: "true"
      OTEL_SERVICE_NAME: flask-api
      OTEL_EXPORTER_OTLP_ENDPOINT: otel-collector:4317
      OTEL_EXPORTER_OTLP_PROTOCOL: grpc
      OTEL_EXPORTER_OTLP_INSECURE: "true"
      OTEL_TRACES_EXPORTER: console,otlp
      OTEL_METRICS_EXPORTER: console,otlp
      OTEL_LOGS_EXPORTER: console,otlp
      OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED: "true"
      OTEL_PYTHON_LOG_CORRELATION: "true"
      OTEL_PYTHON_FLASK_ENABLED: "true"
      OTEL_PYTHON_SQLALCHEMY_ENABLED: "true"
      OTEL_PYTHON_REQUESTS_ENABLED: "true"
      OTEL_TRACES_SAMPLER: always_on
      OTEL_METRICS_SAMPLER: always_on
      # OTEL_LOG_LEVEL: DEBUG
      # OTEL_TRACES_SAMPLER: "always_on"
      # OTEL_TRACES_SAMPLER_ARG: "1.0"
      # OTEL_PYTHON_DISABLED_INSTRUMENTATIONS: ""
      # OTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS_SERVER_REQUEST: ".*"
      # OTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS_SERVER_RESPONSE: ".*"
    networks:
      - app-network
    depends_on:
      db:
        condition: service_healthy

  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    container_name: otel-collector
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "4317:4317" # OTLP gRPC receiver
      - "4318:4318" # OTLP HTTP receiver
      - "8888:8888" # Prometheus metrics
      - "8889:8889" # Prometheus exporter metrics
    networks:
      - app-network
    restart: unless-stopped

  jaeger:
    image: jaegertracing/all-in-one:latest
    container_name: jaeger
    environment:
      - COLLECTOR_OTLP_ENABLED=true
      - LOG_LEVEL=debug
    ports:
      - "16686:16686" # Jaeger UI
      # - "4317:4317" # OTLP gRPC receiver
      # - "4318:4318" # OTLP HTTP receiver
      - "14250:14250" # Jaeger gRPC
      - "14268:14268" # Jaeger HTTP
    networks:
      - app-network

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--web.console.libraries=/usr/share/prometheus/console_libraries"
      - "--web.console.templates=/usr/share/prometheus/consoles"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"
    networks:
      - app-network
    depends_on:
      - otel-collector
    restart: unless-stopped

volumes:
  postgres_data:
  prometheus-data:

networks:
  app-network:
    driver: bridge

otel-collector-config.yaml

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s
    send_batch_size: 1024

exporters:
  debug:
    verbosity: detailed
  otlp:
    endpoint: jaeger:4317
    tls:
      insecure: true
  prometheus:
    endpoint: 0.0.0.0:8889
    namespace: flask_app

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

Pra executar o projeto basta baixar o projeto do Github ou então criar os arquivos acima e executar um docker compose up

Fluxo do projeto

A Ligação Entre os Arquivos

1. otel_config.py - O Configurador

Este arquivo contém a função init_telemetry() que:

• Configura o OpenTelemetry SDK

• Define para onde enviar os traces (exporters)

• Instrumenta automaticamente Flask e SQLAlchemy

• Retorna o tracer e meter configurados

2. app.py - O Consumidor

Importa e usa a configuração:

python

# IMPORTA a configuração
from otel_config import init_telemetry

# INICIALIZA a telemetria passando app Flask e DB engine
with app.app_context():
    tracer, meter = init_telemetry(app, db.engine)

📍 Onde os Traces São Gerados

Traces Automáticos (configurados no otel_config.py):

1. HTTP Requests - Todas as rotas Flask são automaticamente rastreadas

2. SQL Queries - Todas as queries do SQLAlchemy são automaticamente rastreadas

Traces Manuais (criados no app.py):

python

# Exemplo na rota /user/<name>
with tracer.start_as_current_span("get_user_operation") as span:
    span.set_attribute("user.name", name)  # Adiciona metadados

    # Span filho para operação específica
    with tracer.start_as_current_span("database.check_user"):
        user = User.query.filter_by(name=name).first()

🔄 O Fluxo Completo

1. Request chega → Flask (instrumentado automaticamente)
   ↓
2. Cria span root automático "HTTP GET /user/john"
   ↓
3. Seu código cria span filho "get_user_operation"
   ↓
4. Dentro dele, cria span neto "database.check_user"
   ↓
5. SQLAlchemy (instrumentado) cria span "SELECT FROM users..."
   ↓
6. Todos os spans são enviados para o coletor configurado

🎯 Para Onde Vão os Traces

O otel_config.py provavelmente configura um exporter que envia para:

• Jaeger (porta 4317 ou 14250)

• OpenTelemetry Collector (porta 4317/4318)

• Zipkin (porta 9411)

• Ou outro backend de observabilidade

📊 Estrutura da Telemetria

Trace (representa toda a requisição)
├── Span: HTTP GET /user/john [automático]
│   ├── Span: get_user_operation [manual]
│   │   ├── Span: database.check_user [manual]
│   │   │   └── Span: SELECT * FROM users [automático]
│   │   └── Span: database.create_user [manual]
│   │       └── Span: INSERT INTO users [automático]

🔍 Momentos-Chave da Complementação

1. Inicialização (linha ~95-96):

   • otel_config.py configura COMO coletar

   • app.py define O QUE coletar

2. Durante Requisições:

   • Instrumentação automática captura tudo

   • Spans manuais adicionam contexto de negócio

3. Métricas Customizadas:

python

   message_counter.add(1, {"source": "api"})  # Conta mensagens
   user_counter.add(1, {"operation": "create"})  # Conta usuários

O otel_config.py é a infraestrutura (como um sistema de câmeras), enquanto o app.py é o uso dessa infraestrutura (onde você coloca as câmeras e o que filma com elas)

Exemplo de Melhoria no Contexto de Métricas e Traces de Negócio

Você pode enriquecer a observabilidade do seu código configurando pontos estratégicos onde deseja obter mais informações sobre o comportamento da aplicação. Isso inclui:

• Adicionar contadores customizados para rastrear eventos específicos do negócio

• Implementar validadores para garantir a qualidade dos dados coletados

• Otimizar o número de spans, mantendo apenas aqueles que realmente agregam valor ao troubleshooting e à análise de performance

• Criar métricas de negócio que reflitam KPIs importantes para a operação

A instrumentação personalizada oferece possibilidades praticamente ilimitadas para adaptar sua estratégia de observabilidade às necessidades específicas do seu contexto.

@app.route('/user/<name>')
def get_user(name):
    # Span customizado com informações do SEU negócio
    with tracer.start_as_current_span("get_user_operation") as span:

        # 🎯 ADICIONAR MAIS ATRIBUTOS AO SPAN
        span.set_attribute("user.name", name)
        span.set_attribute("user.type", "premium")  # ✨ Nova métrica
        span.set_attribute("request.source", request.headers.get('User-Agent'))  # ✨
        span.set_attribute("feature.flag", "new_ui_enabled")  # ✨

        # 🎯 EVENTOS IMPORTANTES DO NEGÓCIO
        span.add_event("validation_started", {
            "validator": "name_length",
            "min_length": 2
        })

        # 🎯 SPANS FILHOS PARA OPERAÇÕES ESPECÍFICAS
        with tracer.start_as_current_span("cache_check") as cache_span:
            cache_span.set_attribute("cache.key", f"user:{name}")
            # Simular check de cache
            cache_hit = False
            cache_span.set_attribute("cache.hit", cache_hit)

            if not cache_hit:
                span.add_event("cache_miss", {"key": f"user:{name}"})

        # 🎯 MÉTRICAS DE PERFORMANCE
        import time
        db_start = time.time()

        with tracer.start_as_current_span("database.check_user") as db_span:
            user = User.query.filter_by(name=name).first()

            db_latency = (time.time() - db_start) * 1000
            db_span.set_attribute("db.latency_ms", db_latency)
            db_span.set_attribute("db.rows_examined", 1)

            # 🎯 MÉTRICAS CONDICIONAIS
            if db_latency > 100:
                db_span.set_attribute("performance.slow_query", True)
                span.add_event("slow_query_detected", {
                    "latency_ms": db_latency,
                    "query_type": "user_lookup"
                })

Conclusão

Chegamos ao final desta série de artigos sobre observabilidade e OpenTelemetry. Ao longo de quatro artigos, um introdutório e três práticos, abordamos temas fundamentais para implementar observabilidade efetiva em suas aplicações:

• Fundamentos: O que é auto-instrumentação e como ela funciona

• Prática com instrumentação automática: utilizando OTLP para auto-instrumentação em ambientes em qualquer tipo de ambiente

• Prática com Kubernetes: Como utilizar o OpenTelemetry Operator para auto-instrumentação em ambientes Kubernetes

• Instrumentação Manual: Técnicas para instrumentar manualmente suas aplicações quando você precisa de maior controle e customização

Espero que este conteúdo tenha proporcionado uma base sólida para você começar ou aprimorar sua jornada com OpenTelemetry e observabilidade.

Anteriormente, realizamos a instrumentação manual da nossa aplicação. Neste artigo, vamos explorar a auto-instrumentação utilizando o OpenTelemetry Operator, uma funcionalidade que simplifica significativamente o processo de instrumentação em ambientes Kubernetes.

Todo o código desta etapa está disponível em:

• Repositório: https://github.com/joaochiroli/otel-instrumentacao-python

• Branch: kubernetes-operator

• Diretório: /kubernetes

Etapas de Implementação:

Neste artigo, você aprenderá a configurar a auto-instrumentação seguindo estas etapas:

1. Preparação da aplicação

   • Alteração do Dockerfile

   • Alteração do requirements.txt

2. Instalação de dependências

   • Instalação do Cert Manager

   • Instalação do OpenTelemetry Operator

3. Configuração do ambiente Kubernetes

   • Criação do namespace

   • Criação e instalação do banco de dados (PostgreSQL)

4. Configuração da observabilidade

   • Criação e instalação do Jaeger

   • Criação e instalação do OpenTelemetry Collector

   • Criação e instalação do Instrumentation

5. Deploy da aplicação

   • Criação e instalação dos manifestos da aplicação Flask

Preparação da aplicação

Alteramos o arquivo requirements.txt para instalarmos apenas as dependências usadas pela aplicação, retiramos as dependências do OTLP.

flask 
Flask-SQLAlchemy
psycopg2-binary
flask_sqlalchemy

Fizemos o mesmo para o Dockerfile:

FROM python:3.9-slim

# Defina o diretório de trabalho
WORKDIR /app

# Copie os arquivos necessários para o diretório de trabalho
COPY . /app

# Instale as dependências
RUN pip install -r requirements.txt

# Exponha a porta que a aplicação vai rodar
EXPOSE 5000

# Comando para rodar a aplicação
CMD ["python", "app.py"]

Instalação de dependências

Para o o OTLP Operator funcionar precisa ter instalado o Cert Manager:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.2/cert-manager.yaml

Use o comando kubectl get pods -A para verificar se seus pods estão executando corretamente

Vamos instalar o operator com o seguinte comando:

kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

Use o comando kubectl get pods -A para verificar se seus pods estão executando corretamente

Configuração do ambiente Kubernetes

Criamos um namespace pro nosso projeto.

Para fazer o deploy do namespace execute kubectl apply -f namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: simple-app
  labels:
    name: simple-app

Para fazer o deploy do configmap execute kubectl apply -f configmap-app.yaml:

# configmap-app.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: flask-app-config
  namespace: simple-app
data:
  DATABASE_URL: "postgresql://postgres:postgres@postgres-db:5432/simple_app"
  FLASK_ENV: "development"
  FLASK_DEBUG: "false"

Para fazer o deploy do secret execute kubectl apply -f secret-postgres.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: postgres-secret
  namespace: simple-app
type: Opaque
data:
  postgres-password: cG9zdGdyZXM=  # postgres em base64
  postgres-user: cG9zdGdyZXM=     # postgres em base64
  postgres-db: c2ltcGxlX2FwcA==   # simple_app em base64

Para fazer o deploy do Banco de Dados PostgreSQL execute kubectl apply -f postgres.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
  namespace: simple-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:latest
        ports:
        - containerPort: 5432
        env:
        - name: POSTGRES_DB
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: postgres-db
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: postgres-user
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: postgres-password
        - name: POSTGRES_HOST_AUTH_METHOD
          value: "md5"
        # - name: PGDATA
        #   value: /var/lib/postgresql/data/pgdata
        # volumeMounts:
        # - name: postgres-storage
        #   mountPath: /var/lib/postgresql/data
        #   subPath: pgdata
        livenessProbe:
          exec:
            command:
            - pg_isready
            - -U
            - postgres
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          exec:
            command:
            - pg_isready
            - -U
            - postgres
          initialDelaySeconds: 5
          periodSeconds: 5
      volumes:
      - name: postgres-storage
        persistentVolumeClaim:
          claimName: postgres-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
  namespace: simple-app
spec:
  selector:
    app: postgres
  ports:
  - port: 5432
    targetPort: 5432
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
  namespace: simple-app
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Você pode verificar se os pods estão executando usando o comando kubectl get pods -n simple-app

E vendo os logs do pod pra saber se está sendo executado como deveria. kubectl logs <nome do pod> -n simple-app

Configuração da observabilidade

Podemos seguir com os próximos passos. O primeiro deles é subir nosso backend que no caso é o Jaeger. Para fazer o deploy execute kubectl apply -f jaeger.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jaeger
  namespace: simple-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: jaeger
  template:
    metadata:
      labels:
        app: jaeger
    spec:
      containers:
      - name: jaeger
        image: jaegertracing/all-in-one:latest
        ports:
        - containerPort: 5775
          protocol: UDP
        - containerPort: 6831
          protocol: UDP
        - containerPort: 6832
          protocol: UDP
        - containerPort: 5778
          protocol: TCP
        - containerPort: 16686
          protocol: TCP
        - containerPort: 4317
          protocol: TCP
        - containerPort: 4318
          protocol: TCP
        - containerPort: 14250
          protocol: TCP
        - containerPort: 14268
          protocol: TCP
        - containerPort: 14269
          protocol: TCP
        - containerPort: 9411
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: jaeger-query
  namespace: simple-app
spec:
  ports:
  - port: 16686
    targetPort: 16686
    name: query
  selector:
    app: jaeger
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  name: jaeger-collector
  namespace: simple-app
spec:
  ports:
  - port: 4317
    targetPort: 4317
    name: grpc
  - port: 4318
    targetPort: 4318
    name: http
  - port: 14268
    targetPort: 14268
    name: binary
  selector:
    app: jaeger
  type: ClusterIP

Verifique se os pods estão executando. kubectl get pods -n simple-app.

Agora pra acessar a página web da sua aplicação faça kubectl port-forward -n simple-app svc/jaeger-query 16686:16686

Vamos agora fazer o deploy do OTLP Collector ele quem vai coletar os dados e enviar para o Backend.

kubectl apply -f jaeger.yaml

# otel-collector.yaml
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel-collector
  namespace: simple-app
spec:
  mode: deployment
  image: otel/opentelemetry-collector-contrib:latest
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318

    processors:
      batch:
        timeout: 10s
        send_batch_size: 1024
      memory_limiter:
        check_interval: 1s
        limit_mib: 512

    exporters:
      debug:
        verbosity: detailed
        sampling_initial: 5
        sampling_thereafter: 200
      otlp:
        endpoint: jaeger-collector:4317
        tls:
          insecure: true

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [otlp]
        metrics:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [debug]
        logs:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [debug]

Agora vamos criar a configuração do Intrumentation. O Instrumentation é o "template de configuração" que diz ao Operator como instrumentar automaticamente suas aplicações sem modificar o código-fonte, definindo todos os parâmetros de configuração do OpenTelemetry de forma declarativa via Kubernetes.

Na documentação você pode verificar que é possível usar o Operator para instrumentar vários tipos de linguagem não só Python. Link: https://github.com/open-telemetry/opentelemetry-operator.

Vamos fazer o deploy kubectl apply -f instrumentation.yaml

# instrumentation.yaml
apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: flask-instrumentation
  namespace: simple-app
spec:  
  # propagators:
  #   - tracecontext
  #   - baggage
  # sampler:
  #   type: parentbased_traceidratio
  #   argument: "1.0"  # ou "0.25" para 25% sampling  
  python:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:latest
    env:
      - name: OTEL_TRACES_EXPORTER
        value: otlp
      # - name: OTEL_METRICS_EXPORTER
      #   value: otlp
      # - name: OTEL_LOGS_EXPORTER
      #   value: otlp
      # - name: OTEL_EXPORTER_OTLP_PROTOCOL
      #   value: http/protobuf
      # - name: OTEL_EXPORTER_OTLP_PROTOCOL
      #   value: grpc
      - name: OTEL_SERVICE_NAME
        value: flask-simple-app
      - name: OTEL_RESOURCE_ATTRIBUTES
        value: deployment.environment=development
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: http://otel-collector-collector-headless.simple-app.svc.cluster.local:4318
  exporter:
    endpoint: http://otel-collector-collector-headless.simple-app.svc.cluster.local:4318

Agora execute o comando kubectl get instrumentation -n simple-app para saber se seu instrumentation está devidamente configurado.

Deploy da aplicação

Por último e mais importante, vamos fazer o deploy da aplicação. A parte mais importante e que faz toda essa mágica ser possível é essa configuração abaixo, através dela a aplicação e o instrumentation conseguem se comunicar e enviar dados para o collector.

annotations:
        instrumentation.opentelemetry.io/inject-python: "simple-app/flask-instrumentation"

Para fazer o deploy iremos usar o comando kubectl apply -f flask-app-deployment.yaml.

# flask-app-deployment.yaml - VERSÃO CORRIGIDA
apiVersion: apps/v1
kind: Deployment
metadata:
  name: flask-app
  namespace: simple-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: flask-app
  template:
    metadata:
      labels:
        app: flask-app
      annotations:
        instrumentation.opentelemetry.io/inject-python: "simple-app/flask-instrumentation"
    spec:
      containers:
      - name: flask-app
        image: joaochiroli123/app-flask:latest
        ports:
        - containerPort: 5000
          name: http
        env:
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: postgres-user
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: postgres-password
        - name: POSTGRES_DB
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: postgres-db
        - name: POSTGRES_HOST
          value: "postgres" 
        - name: POSTGRES_PORT
          value: "5432"
        - name: FLASK_ENV
          value: "development"
        - name: FLASK_DEBUG
          value: "false"
        livenessProbe:
          httpGet:
            path: /health
            port: 5000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 5000
          initialDelaySeconds: 10
          periodSeconds: 5
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
  name: flask-app
  namespace: simple-app
spec:
  selector:
    app: flask-app
  ports:
  - name: http
    port: 80
    targetPort: 5000
  type: ClusterIP

Você pode verificar se os pods estão executando através do comando kubectl get pods -n simple-app

Verificar os logs da aplicação se estão corretos. kubectl logs <nome do pod> -n simple-app

E o mais importante através do próximo comando é possivel verificar se a instrumentação foi feita na sua aplicação sem quebrar internamente alguma coisa kubectl exec -n simple-app <nome do pod> -- python -c "import sys; print('\n'.join(sys.path))"

Para executar os comandos abaixo para testar nossa aplicação:

curl http://localhost:5000/
curl http://localhost:5000/user/John
curl -X POST http://localhost:5000/submit \
  -H "Content-Type: application/json" \
  -d '{"message": "Hello from curl!"}'
curl http://localhost:5000/health
curl -X POST http://localhost:5000/submit \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Complex request",
    "user": "admin",
    "priority": "high"
  }'
curl http://localhost:5000/09
curl http://localhost:5000/user/João

E pra ver ela na página web vamos executar. kubectl port-forward -n simple-app svc/flask-app 5000:80

Agora já é possível fazer algumas execuções na nossa página Web e verificar os traces chegando no Jaeger.

Conclusão:

Neste artigo, exploramos como a auto-instrumentação utilizando o OpenTelemetry Operator simplifica significativamente a implementação de observabilidade em aplicações Python rodando em Kubernetes. Diferentemente da instrumentação manual, essa abordagem elimina a necessidade de modificar o código-fonte da aplicação ou gerenciar manualmente as dependências do OpenTelemetry.

Através do Operator, conseguimos:

• Automatizar a injeção de bibliotecas de instrumentação via init containers

• Centralizar as configurações de telemetria usando o recurso Instrumentation

• Padronizar a coleta de traces, métricas e logs em todo o cluster

• Simplificar o gerenciamento de observabilidade em ambientes Kubernetes

Vamos começar fazendo a instrumentação de uma aplicação em Python que salva os dados em um banco de dados Postgresql. O que esse tutorial vai abordar:

• Vou compartilhar a aplicação em Python utilizada

• Criação do Dockerfile

• Criação do Docker Compose

• Criação do Arquivo de configuração do Otlp Collector

• Além de explicar o que cada componente faz pretendo mostrar algumas outras formas de como fazer essa instrumentação.

• Uma série de videos que eu recomnedo são destes dois canais no youtube: https://www.youtube.com/watch?v=NEYVJSp4rKo e https://www.youtube.com/watch?v=9mifCIFhtIQ

Entendendo o Opentelemetry Python Auto-Instrumentation:

É um projeto de código aberto que oferece uma abordagem unificada à observabilidade, oferecendo ferramentas e bibliotecas para coletar dados de telemetria, como rastros, métricas e logs. Um de seus principais recursos é a autoinstrumentação, que automatiza o processo de instrumentação de aplicativos para rastreamento distribuído sem a necessidade de alterações manuais no código.

Na documentação oficial do OTLP você consegue acessar outras linguagens que suportam este tipo de instrumentação: https://opentelemetry.io/docs/zero-code/

Passo 1:

Nessa etapa, antes de transformar nossa aplicação em um container e salvar os dados em um banco de dados Postgresql, resolvi dar um passo atrás pra mostrar como podemos fazer a instrumentação e visualização dos dados usando apenas comandos manuais e vamos progredindo a partir disso.

Então nós temos uma aplicação super simples em Python usando Flask:

import logging
from flask import Flask, request, jsonify
from datetime import datetime
import sys

app = Flask(__name__) 

# Configure logging
logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    handlers=[
        logging.FileHandler('app.log'),
        logging.StreamHandler(sys.stdout)
    ]
)

# Create logger
logger = logging.getLogger(__name__)

# Request logging middleware
@app.before_request
def log_request_info():
    logger.info(f"Request: {request.method} {request.url} from {request.remote_addr}")
    if request.method == 'POST':
        logger.info(f"Request data: {request.get_data()}")

@app.after_request
def log_response_info(response):
    logger.info(f"Response: {response.status_code} for {request.method} {request.path}")
    return response

# Error handler
@app.errorhandler(404)
def not_found(error):
    logger.warning(f"404 Error: {request.method} {request.url} - {error}")
    return jsonify({"error": "Endpoint not found"}), 404

@app.errorhandler(500)
def internal_error(error):
    logger.error(f"500 Error: {request.method} {request.url} - {error}")
    return jsonify({"error": "Internal server error"}), 500

# Define a simple route
@app.route('/')
def hello():
    logger.info("Hello endpoint accessed")
    return "Hello, World!"

# GET request - retrieve user info
@app.route('/user/<name>')
def get_user(name):
    logger.info(f"User endpoint accessed for: {name}")
    try:
        if len(name) < 2:
            raise ValueError("Name too short")
        return f"Hello, {name}! This is a GET request."
    except ValueError as e:
        logger.error(f"Validation error in get_user: {e}")
        return jsonify({"error": "Name must be at least 2 characters"}), 400

# POST request - create/submit data
@app.route('/submit', methods=['POST'])
def submit_data():
    logger.info("Submit endpoint accessed")
    try:
        data = request.get_json()
        if not data:
            logger.warning("No JSON data received in submit")
            return jsonify({"status": "error", "message": "No JSON data received"}), 400

        if 'message' not in data:
            logger.warning("Missing 'message' field in submit data")
            return jsonify({"status": "error", "message": "Missing 'message' field"}), 400

        logger.info(f"Successfully processed message: {data['message']}")
        return jsonify({
            "status": "success",
            "received_message": data['message'],
            "response": "Data received successfully!",
            "timestamp": datetime.now().isoformat()
        })
    except Exception as e:
        logger.error(f"Unexpected error in submit_data: {e}")
        return jsonify({"status": "error", "message": "Internal server error"}), 500

# Health check endpoint
@app.route('/health')
def health_check():
    logger.info("Health check accessed")
    return jsonify({
        "status": "healthy",
        "timestamp": datetime.now().isoformat(),
        "version": "1.0.0"
    })

# Run the application
if __name__ == '__main__':
    logger.info("Starting Flask application...")
    app.run(debug=True, host='0.0.0.0', port=5000)

A primeira coisa que devemos fazer é criar nosso ambiente virtual:

python -m venv venv
source venv/bin/activate

Agora vamos usar uma ferramente que se chama otel-tui para instalar essa ferramenta é necessário que você tenha go instalado na sua vm.

O otel-tui é uma ferramenta que vai receber os seus dados instrumtnados da sua aplicação,ou seja, ele vai se comportar como otlp collector e backend ao mesmo tempo. Essa ferramenta é muito boa para casos de troubleshooting ou visualização incial dos dados, se eles estão se comportando como você gostaria, etc.

Se quiser saber mais sobre aqui está o link do repositório: https://github.com/ymtdzzz/otel-tui

Para instalar a ferramenta basta:

go install github.com/ymtdzzz/otel-tui@latest

E para ver a ferramenta em execução faça:

otel-tui

Vai mostrar algo assim, veja que se você tiver uma aplicação instrumentada, já é possivel ver os Traces, Metricas, Logs, Topologia, etc.

Voltando ao que nos interessa, vamos definir as variáveis:
OTEL_SERVICE_NAME: nome do serviço

OTEL_EXPORTER_OTLP_ENDPOINT: pra onde seus dados devem ir, no nosso caso os dados vão ser enviados para o otel-tui.

OTEL_TRACES_EXPORTER, OTEL_METRICS_EXPORTER e OTEL_LOGS_EXPORTER: vamos definir como console e otlp, porque ativando o console conseguimos ver o que nossa aplicação instrumentada está fazendo, se realmente os dados estão sendo enviados para o destino esperado e se metricas, traces, logs estão sendo coletados.

export OTEL_SERVICE_NAME='flask-python'
export OTEL_EXPORTER_OTLP_ENDPOINT='localhost:4317'
export OTEL_EXPORTER_OTLP_INSECURE='true'
export OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED='true'
export OTEL_TRACES_EXPORTER='console,otlp'
export OTEL_METRICS_EXPORTER='console,otlp'
export OTEL_LOGS_EXPORTER='console,otlp'

vamos instalar os binários necessários para nossa aplicação executar:

pip install flask fastapi opentelemetry-distro opentelemetry-exporter-otlp

Configure o OTLP:

opentelemetry-bootstrap -a install

Agora vamos executar nossa aplicação instrumentada, primeiro em um outro cmd deixe o otel-tui executando porque ele quem vai receber os dados:

otel-tui

Execute a aplicação:

OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED=true opentelemetry-instrument --traces_exporter otlp,console --metrics_exporter otlp,console --logs_exporter otlp,console --service_name flask-python flask run -p 5000

Você vai ver algo como:

Alguns testes que você pode fazer é:

curl http://localhost:5000/
curl http://localhost:5000/user/John
curl -X POST http://localhost:5000/submit \
  -H "Content-Type: application/json" \
  -d '{"message": "Hello from curl!"}'
curl http://localhost:5000/health
curl -X POST http://localhost:5000/submit \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Complex request",
    "user": "admin",
    "priority": "high"
  }'
curl http://localhost:5000/09
curl http://localhost:5000/user/João

E no seu otel-tui você já vai começar a receber dados de traces e métricas:

Agora vamos dar um próximo passo no nosso ambiente, ao invés de usarmos o otel-tui para receber os dados, vamos fazer uma configuração usando docker-compose, nós ainda vamos fazer a instrumentação do código na mão. Porém, o destino agora será um container que vai usar uma imagem grafana/otel-lgtm:latest essa imagem já tem o otlp collector embutido, além disso, a imagem possui alguns serviços web como o prometheus, grafana, tempo, etc, que nos possibilita visualizar os dados que estão chegando. Docker-compose:

services:
    otel-lgtm:
    image: grafana/otel-lgtm
    container_name: otel-lgtm
    ports:
      - "4317:4317" # OTLP gRPC receiver
      # - "4318:4318" # OTLP HTTP receiver
      - "3000:3000" # Grafana UI
    # networks:
    #   - app-network
    restart: unless-stopped

Pode parar a execução do otel-tui e basta executar:

docker compose up -d

Para executar a aplicação vamos fazer o mesmo comando:

OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED=true opentelemetry-instrument --traces_exporter otlp,console --metrics_exporter otlp,console --logs_exporter otlp,console --service_name flask-python flask run -p 5000

Agora você pode ir Explorer no Grafana escolher o que você quer visualizar, usando Tempo, Prometheus ou até mesmo Loki:

Passo 2:

Já definimos nossa aplicação, fizemos a istrumentação e já estamos usando uma ferramenta que está recebendo nossos dados. Agora vamos dar mais uma incrementada na nossa stack, vamos melhorar nossa aplicação, agora vamos ajustar a aplicação para ela começar a salvar dados em um DB e depois veremos se a instrumentação está coletando este dado.

Você pode baixar a aplicação e os arquivos do projeto: https://github.com/joaochiroli/otel-instrumentacao-python. Criei uma nova branch pra essa etapa do projeto application-with-db.

OBS: quando estiver instrumentando sua aplicação não deixe o Debug enable, isso pode atrapalhar o otlp na hora de coletar os dados.

Vamos alterar e colocar as dependências no arquivo requirements.txt para:

flask 
fastapi 
opentelemetry-distro 
opentelemetry-exporter-otlp
Flask-SQLAlchemy
psycopg2-binary
python-dotenv
opentelemetry-instrumentation-flask
opentelemetry-instrumentation-sqlalchemy
opentelemetry-instrumentation-requests
opentelemetry-instrumentation-wsgi
flask_sqlalchemy

OBS: talvez eu tenha colocado dependencias demais, acredito que voces possam testar com menos.

Vamos fazer um ajuste no Dockerfile:

FROM python:3.9-slim

# Defina o diretório de trabalho
WORKDIR /app

# Copie os arquivos necessários para o diretório de trabalho
COPY . /app

# Instale as dependências
RUN pip install -r requirements.txt

# Configura o OTLP
RUN opentelemetry-bootstrap -a install

# Exponha a porta que a aplicação vai rodar
EXPOSE 5000

# Comando para rodar a aplicação
CMD ["opentelemetry-instrument", "python", "app.py"]

Vamos fazer um update no nosso docker-compose, iremos colocar configurações do Postgresql e colocar as variáveis necessárias para nossa aplicação enviar os traces, métricas e logs pro no backend(grafana-lgtm):

services:
  db:
    image: postgres:14.15
    container_name: postgres-db
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: simple_app
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck: 
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 10
    networks:
      - app-network

  otel-lgtm:
    image: grafana/otel-lgtm
    container_name: otel-lgtm
    ports:
      - "4317:4317" # OTLP gRPC receiver
      # - "4318:4318" # OTLP HTTP receiver
      - "3000:3000" # Grafana UI
    networks:
      - app-network
    restart: unless-stopped
  app:
    build: .
    container_name: flask-app
    volumes:
      - .:/app
    ports:
      - "5000:5000"
    environment:
      POSTGRES_HOST: db
      POSTGRES_PORT: 5432
      POSTGRES_DB: simple_app
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      FLASK_ENV: development
      FLASK_DEBUG: "true"
      OTEL_SERVICE_NAME: flask-api
      OTEL_EXPORTER_OTLP_ENDPOINT: otel-lgtm:4317
      OTEL_EXPORTER_OTLP_PROTOCOL: grpc
      OTEL_EXPORTER_OTLP_INSECURE: "true"
      OTEL_TRACES_EXPORTER: console,otlp
      OTEL_METRICS_EXPORTER: console,otlp
      OTEL_LOGS_EXPORTER: console,otlp
      OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED: "true"
      # OTEL_LOG_LEVEL: DEBUG
      OTEL_PYTHON_LOG_CORRELATION: "true"
      OTEL_PYTHON_FLASK_ENABLED: "true"
      OTEL_PYTHON_SQLALCHEMY_ENABLED: "true"
      OTEL_PYTHON_REQUESTS_ENABLED: "true"
      OTEL_TRACES_SAMPLER: always_on
      OTEL_METRICS_SAMPLER: always_on
      # OTEL_TRACES_SAMPLER: "always_on"
      # OTEL_TRACES_SAMPLER_ARG: "1.0"
      # OTEL_PYTHON_DISABLED_INSTRUMENTATIONS: ""
      # OTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS_SERVER_REQUEST: ".*"
      # OTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS_SERVER_RESPONSE: ".*"
    networks:
      - app-network
    depends_on:
      db:
        condition: service_healthy
volumes:
  postgres_data:

networks:
  app-network:
    driver: bridge

Depois basta executar: docker compose up -d —build

Comandos que você pode usar pra testar a aplicação:

curl http://localhost:5000/
curl http://localhost:5000/user/joao
curl -X POST http://localhost:5000/submit -H "Content-Type: application/json" -d '{"message":"test"}'

Depois disso, abrindo a página web do Grafana → Explore → Tempo → Query type: Search

E você vai ver os Traces e spans dos eventos que foram gerados através do curl, vai conseguir verificar os dados que foram coletados, o que foi feito, quanto tempo demorou pra cada evento acontecer, entre outras coisas.

Se você for até o Prometheus vai conseguer verificar os dados das requisições HTTP:

• GET

• POST

• PUT

• DELETE

• SELECT - do banco de dados

E você pode criar filtros de status code: 200, 404, 500, etc. Depende de quais status sua aplicação retorna.

Passo 3:

Agora já temos um projeto com uma stack a mais que seria a parte de salvar os dados em um banco. Para incremetar um pouco mais vamos retirar o Grafana LGTM e iremos substituir por um OTLP Collector, além disso, vamos subir dois backends um Jaeger e um Prometheus que serão responsáveis por recebr estes dados.

Nesse caso vamos fazer alterações apenas no docker-compose. Você pode ter acesso ao código através do repositório do projeto https://github.com/joaochiroli/otel-instrumentacao-python e foi criado a branch otlp-collector para essa parte do artigo.

Primeira coisa que devemos fazer é alterar a variável de ambiente da nossa aplicação instrumentada, antes os dados estavam indo para o Grafana LGTM e agora vamos enviar para o Otlp Collector:

  app:
    build: .
    container_name: flask-app
    volumes:
      - .:/app
    ports:
      - "5000:5000"
    environment:
      POSTGRES_HOST: db
      POSTGRES_PORT: 5432
      POSTGRES_DB: simple_app
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      FLASK_ENV: development
      FLASK_DEBUG: "true"
      OTEL_SERVICE_NAME: flask-api
      OTEL_EXPORTER_OTLP_ENDPOINT: otel-collector:4317 ### ALTERADO
      OTEL_EXPORTER_OTLP_PROTOCOL: grpc
      OTEL_EXPORTER_OTLP_INSECURE: "true"
      OTEL_TRACES_EXPORTER: console,otlp
      OTEL_METRICS_EXPORTER: console,otlp
      OTEL_LOGS_EXPORTER: console,otlp
      OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED: "true"
      OTEL_PYTHON_LOG_CORRELATION: "true"
      OTEL_PYTHON_FLASK_ENABLED: "true"
      OTEL_PYTHON_SQLALCHEMY_ENABLED: "true"
      OTEL_PYTHON_REQUESTS_ENABLED: "true"
      OTEL_TRACES_SAMPLER: always_on
      OTEL_METRICS_SAMPLER: always_on
      # OTEL_LOG_LEVEL: DEBUG
      # OTEL_TRACES_SAMPLER: "always_on"
      # OTEL_TRACES_SAMPLER_ARG: "1.0"
      # OTEL_PYTHON_DISABLED_INSTRUMENTATIONS: ""
      # OTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS_SERVER_REQUEST: ".*"
      # OTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS_SERVER_RESPONSE: ".*"
    networks:
      - app-network
    depends_on:
      db:
        condition: service_healthy

Agora vamos criar o nosso serviço do OTLP Collector:

  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    container_name: otel-collector
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "4317:4317" # OTLP gRPC receiver
      - "4318:4318" # OTLP HTTP receiver
      - "8888:8888" # Prometheus metrics
      - "8889:8889" # Prometheus exporter metrics
    networks:
      - app-network
    restart: unless-stopped

Nós iremos usar a imagem otel/opentelemetry-collector-contrib:latest. Estamos usando o collector-contrib porque é uma imagem completa que já possui todas as dependências e extensões, como vamos usar diferentes destinos de backend essa imagem vai nos ajudar. Mas esta é uma imagem para ambientes de desenvolvimento, por conta do seu tamanho e quantidade muito grande de extensões que na maioria das vezes não serão usados. https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension

para ambientes de produção é recomendado que você faça a criação da sua própria imagem do collector usando uma imagem do collector oficial, sem dependências e bibliotecas. O otel-collector-contrib é baseado no otel-collector oficial.

Arquivo de configuração do otlp collector:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s
    send_batch_size: 1024

exporters:
  debug:
    verbosity: detailed
  otlp:
    endpoint: jaeger:4317
    tls:
      insecure: true
  # prometheus:
  #   endpoint: 0.0.0.0:8889
  #   namespace: flask_app

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, otlp]
    # metrics:
    #   receivers: [otlp]
    #   processors: [batch]
    #   exporters: [debug, prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

Receivers (Receptores) - Recebem dados de telemetria das aplicações. São o "ponto de entrada" do coletor.

• otlp: Protocolo padrão do OpenTelemetry

  • gRPC (porta 4317): Protocolo binário, mais performático

  • HTTP (porta 4318): Protocolo baseado em REST, mais compatível

Processors (Processadores) - Transformam, filtram ou enriquecem os dados antes de exportá-los.

• batch: Agrupa dados em lotes para melhorar performance

  • timeout: 10s: Envia a cada 10 segundos

  • send_batch_size: 1024: Envia quando acumular 1024 itens

Exporters (Exportadores) - Enviam os dados processados para destinos finais (backends).

• debug: Exibe logs detalhados no console (útil para troubleshooting)

• otlp: Envia para o Jaeger (sistema de tracing) via gRPC sem TLS

• prometheus (comentado): Exportaria métricas no formato Prometheus

Service (Serviço) - Define os pipelines - fluxo de dados do receiver → processor → exporter.

• traces: Pipeline para rastreamento distribuído (spans)

• metrics (comentado): Pipeline para métricas

• logs: Pipeline para logs estruturados

Configuração do Jaeger:

jaeger:
    image: jaegertracing/all-in-one:latest
    container_name: jaeger
    environment:
      - COLLECTOR_OTLP_ENABLED=true
      - LOG_LEVEL=debug
    ports:
      - "16686:16686" # Jaeger UI
      # - "4317:4317" # OTLP gRPC receiver
      # - "4318:4318" # OTLP HTTP receiver
      - "14250:14250" # Jaeger gRPC
      - "14268:14268" # Jaeger HTTP
    networks:
      - app-network

Agora você pode visualizar os traces:

E pra finalizar vamos adicionar a configuração do Prometheus

Vamos começar descomentando as linhas do arquivo otel-collector-config.yaml:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s
    send_batch_size: 1024

exporters:
  debug:
    verbosity: detailed
  otlp:
    endpoint: jaeger:4317
    tls:
      insecure: true
  prometheus:
    endpoint: 0.0.0.0:8889
    namespace: flask_app

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

Vamos ajustar o arquivo de configuração do docker-compose:

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--web.console.libraries=/usr/share/prometheus/console_libraries"
      - "--web.console.templates=/usr/share/prometheus/consoles"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"
    networks:
      - app-network
    depends_on:
      - otel-collector
    restart: unless-stopped

volumes:
  postgres_data:
  prometheus-data:

Precisamos criar um arquivo prometheus.yml, ele quem vai até o collector na porta 8889 para coletar as métricas:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  # Scrape metrics do OpenTelemetry Collector
  - job_name: 'otel-collector'
    static_configs:
      - targets: ['otel-collector:8889']
        labels:
          service: 'flask-api'

  # Scrape metrics do próprio Prometheus
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

Para testar se essa parte de métricas está funcionando existem algumas maneiras, uma delas é indo até a página web do Prometheus → Target health e verificando se o Prometheus está acessando o Collector na porta correta

Para ver as métricas você pode acessar:

http://localhost:8889/metrics

E também é possivel fazer uma busca no Prometheus pelo nome do nosso serviço, assim vai me trazer todas as métricas deste serviço, usei o comando a seguir: {__name__=~"flask_app.*"}. Você pode usar diferentes filtros, o que vai depender é quais métricas você está querendo acessar e quais são os componentes.

O OTLP é tão completo que ele já me traz informações a respeito do meu outro componente o DB:

Conclusão:

Neste artigo foi feito:

• A criação de uma aplicação Flask e sua auto-instrumentação inicial, integrada com o otel-tui e depois com o Grafana LGTM.

• Depois progredimos e melhoramos a aplicação, criamos um DB para salvar os dados e fizemos a auto-instrumentação de todos os componentes que foram integrados ao Grafana LGTM.

• Por último e não menos importante fizemos a criação da stack completa com a aplicação e seus componentes auto instrumentados, enviando dados para o OTLP Collector e os dados foram enviados para o Jaeger e para o Prometheus.

Principais características:

Ele não está vinculado a nenhum fornecedor específico, permitindo que você colete dados uma vez e os exporte para diferentes backends de observabilidade como Prometheus, Jaeger, Elasticsearch, Dynatrace, etc.

Ou seja, após a instrumentação da sua aplicação você consegue fazer o envio dos dados para qualquer destino que você queira. Isso é muito útil já que as vezes existem mudanças nos provedores, por exemplo: você instrumentou sua aplicação para usar Datadog mas 2 ou 3 anos depois sua empresa decide mudar de contrato para um NewRelic, isso exigiria um retrabalho já que você vai precisar fazer alguns ajustes para a coleta e envio destes dados. Usando o OpenTelemetry (OTLP) você não teria este retrabalho já que sua aplicação já está instrumentada, basta indicar pra onde o dado precisa ir.

Três pilares da observabilidade:

• Traces: Rastreiam o fluxo de requisições através de sistemas distribuídos.

• Metrics: Coletam medições numéricas sobre performance e comportamento.

• Logs: Capturam eventos discretos e mensagens de debug.

Instrumentação:

• Auto-instrumentação: Oferece instrumentação automática para linguagens populares (Java, Python, .NET, Node.js, Go) sem necessidade de modificar o código da aplicação. Não precisa de mudanças no código.

• Auto-instrumentação no Kubernetes: É possivel receber e enviar dados da sua aplicação através do OTLP Operator, você pode ter instrumentação completamente automática apenas com annotations. São 3 modos do Operator: Deployment, Sidecar, Daemonset. Não precisa de mudanças no código.

• Instrumentação manual: Permite adicionar telemetria customizada específica para sua aplicação.Utilizado OTLP API e OTLP SDK. Precisa de mudanças no código.

OBS: também é possivel usar a instrumentação manual ou auto-instrumentação no Kubernetes, basicamente são 3 formas diferentes de conseguir coletar dados da sua aplicação. Fica a seu critério definir qual será a melhor maneira pra você.

Arquitetura:

Existem vários tipos de arquiteturas possíveis, abaixo está uma delas. Eu digo que existem várias, porque o OTLP pode enviar os dados dependendo do Backend diretamente, sem ter um OTLP Collector fazendo essa intermediação para o recebimento, processamento e envio destes dados.

O Jaeger por exemplo aceita dados OTLP, alguns outros providers de backend não aceitam, então você precisaria utilizar o OTLP Collector pra fazer esse processamento.

A arquitetura utilizando o OTLP Operator no Kubernetes é um pouco diferente também já que o Cluster Kubernetes possui um Server API para o recebimento de algumas chamadas HTTP.

O operator consegue fazer essa “mágica” de descobrir as aplicações através dessa configuração do seu Deployment:

# Sua aplicação
metadata:
  annotations:
    instrumentation.opentelemetry.io/inject-java: "true"  # 👈 ESTA é a "chave"

Vantagens:

• Padronização da coleta de telemetria

• Evita vendor lock-in

• Reduz complexidade de instrumentação

• Comunidade ativa e suporte da CNCF

• Integração nativa com Kubernetes

Próximos Passos:

Vou criar mais 3 tutoriais mostrando como é feito os diferentes tipos de implementação e qual o resultado.

Trabalhando nestes últimos meses, me questionei a respeito de alguns assuntos:

• Quais seriam as melhores práticas de uma pipeline?

• Quais estágios essa pipeline deve ter?

• Devemos nos preocupar apenas com CI/CD ou existem estágios que antecedem e sucedem o CI/CD?

• Quanto tempo deve durar uma pipeline?

Fiquei refletindo sobre essas perguntas, já que existem diversas ferramentas que podem ser integradas a uma pipeline, diversos tipos de testes, diferentes formas de deploy e afins.

Gostaria de usar este artigo para esclarecer quais componentes mínimos são necessários em uma pipeline. A ideia não é apresentar isso como uma verdade absoluta, mas sim como um guia prático que pode ajudá-lo a garantir entregas de software com qualidade.

Etapas de uma pipeline

Analisando as pipelines do dia a dia, discussões no Stack Overflow e Reddit, além de ler alguns artigos sobre o tema, identifiquei que uma pipeline pode ser dividida em 5 etapas principais.

1. Source Control & Triggers

2. Continuous Integration (CI)

3. Infrastructure & Orchestration

4. Continuous Deployment (CD)

5. Observability & Monitoring

Source Control & Triggers

É uma etapa mais focada em governança, processo humano, políticas e regras organizacionais. Dentro deste contexto existem alguns pontos interessantes que merecem um pouco de atenção:

• Git Repository

  • Etapa em que você vai definir qual plataforma será usada (AzureDevops, Gitlab, Github,etc).

  • Pode implementar regras de proteção em branches.

• Webhook Triggers

  • Dispara um evento, sendo ele um alerta por exemplo na sua caixa de e-mail, caso tenha ocorrido um push, commit ou eventos merge.

• Code Reviews

  • Manuais: você estabelece políticas que exigem um número mínimo de aprovações de revisores qualificados antes que um Pull Request (PR) possa ser merged para a branch principal.

  • Automáticos: utilizam pipelines de CI/CD para executar validações antes do merge, estabelecendo quality gates obrigatórios. Exemplos incluem: cobertura mínima de 80% em testes unitários e máximo de 4 vulnerabilidades de segurança. Esses thresholds são configuráveis conforme a maturidade do projeto. A implementação dessas automações será detalhada no próximo tópico.

Continuous Integration (CI)

É o coração da automação de qualidade do código.

• Pré build

  • Conventional Commits: Verificação do formato (feat:, fix:, docs:, etc.)

  • Prettier: verificação de formatação ou formatação automática.

  • Semantic Release Validation: verificação da semâtica, releases automáticos baseado nos commits.

  • Lint: o objetivo é detecta variável não utilizada, função sem retorno, imports não usados. A finalidade é encontrar código morto e elementos não utilizados no código.

  • Unit test (testes unitários): verifica se as funções/métodos funcionam corretamente. Exemplo testar se uma função de soma retorna o resultado esperado.

• Build & Compilação

  • Nessa etapa fazemos a instalação das dependências e bibliotecas necessárias, transforma o código em um arquivo executável e ocorre a geração de arquivos ou artefatos para os próximos estágios.

• Pós build

  • Teste de cobertura: verifica quanto do seu código está coberto por testes, identificando áreas não testadas.

  • Security Scanning: verifica se seu código tem alguma vulnerabilidade, hardcoded. Você pode usar o Sast para fazer essa verificação.

  • Sonarqube: ferramenta que faz anaálises códigos duplicados, code smell, detecta bugs, vulnerabilidades e pode ser integrada a outras ferramentas.

• Container Build & Artefatos

  • Utilização de containeres para criar uma imagem da aplicação, sempre é recomendado fazer um multi-stage build.

  • Nessa etapa é possivel fazer um scanning de vulnerabilidade da imagem.

  • Depois é recomendado que você salve essa imagem gerada em algum registry. Ecr, Acr ou até mesmo no docker.io.

Infrastructure & Orchestration

Estágio de provisionamento da infraestrutura necessária.

• Infraestrutura as Code: Terraform, Ansible, CloudFormation.

• Container Orchestration: Kubernetes, AKS, ECS.

• Multi-Cloud: AWS, Azure, GCP.

• Service Mesh: Istio.

• Secrets Management: HashiCorp Vault, AWS Secrets Manager.

Continuous Deployment (CD)

Deploy nos ambientes provisionados.

• Staging Deployment: é um ambiente de pré produção que replica um ambiente de produção. Nele você poderá fazer:

  • Smoke test: verifica se os recursos críticos de um aplicativo funcionam corretamente.

  • E2E testing: simula cenários reais de uso da aplicação, garante compatibilidade entre diferentes navegadores. Valida API.

  • Performance testing: você pode usar uma ferramenta chamada Lighthouse para fazer isso, com ela você pode fazer validações de fluxo completo da aplicação, testes de acessibilidade, verificação da performance do site.

  • Security testing: você pode usar o OWASP para fazer verificações de vulnerabilidades na sua página web, testes de penetração, DAST, etc.

• Production Deploy: utilização de estratégias de deploy em produção.

  • Blue-Green Deployment: Dois ambientes idênticos, switch instantâneo.

  • Canary Deployment: Release gradual para subset de usuários.

  • Rolling Deployment: Atualização incremental de instâncias.

  • Feature flags: Controle de features sem redeploy.

  • Health checks: Validação automática pós-deployment.

• Rollback Strategy: mecanismo de reversão em caso de problemas:

  • Automated rollback: Triggers baseados em métricas (error rate, latency)

  • Health monitoring: Monitoramento contínuo pós-deployment

  • Database migrations: Estratégias de rollback para mudanças de schema

  • Traffic routing: Redirecionamento rápido para versão anterior

  • Incident response: Procedimentos documentados para rollback manual

Observability & Monitoring

Monitoramento da aplicação em produção ou até mesmo em outros ambientes. E aqui existem várias ferramentas que podem te ajudar com isso:

• Metrics: Prometheus, Opentelemetry, Grafana.

• Trace: Jaeger, Zipikin, Opentelemetry, Hélios.

• Logs: ELK stack, Fluentd.

• APM: Site24×7, Dynatrace, Datadog.

Quanto tempo deve durar uma pipeline?

Isso também não é uma regra fixa - depende de vários fatores como tasks executando em paralelo, configuração de hardware do runner, tamanho do projeto, quantidade de testes, etc. Mas se precisássemos estabelecer um padrão aceitável, seria algo entre 5 a 15 minutos. Claro que existem casos que podem ultrapassar muito esse tempo.

Observações finais

Acredito que estes são os principais passos para ter uma pipeline moderna e performática. Várias etapas podem ser modificadas - testes podem rodar antes ou depois dos deploys, por exemplo.

É importante reforçar que nem todos os itens são necessários na sua pipeline, e nem precisam seguir exatamente essa ordem. Mas considero esta uma maneira simples e resumida de entender o que fazer do início ao fim de uma pipeline.

• Análise estática com SonarQube/SonarCloud

• Integração de ESLint + Prettier na pipeline

• Bloquear PRs com cobertura < 50%

• Notificações no Teams/Slack

• Tópicos cobertos: SAST, Code Smells, Cobertura de testes, Notificações

Pré requisitos

• Ter feito o laboratório Integração Contínua + ACR (https://joaochiroli.com.br/integracao-continua-acr) iremos usar a mesma estrutura

• Criar uma conta no Slack (https://slack.com/)

• Criar uma conta SonarQubeCloud integrada com sua pipeline (https://sonarcloud.io/login)

  

  • Basta ir dando next até aparecer a sessão com o token

  • Depois disso instale a extensão do SonarqubeCloud (https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarcloud)

  • Depois copie o token que foi criado anteriormente → vá até o service connection no AzureDevops e efetue a configuração do SonarqubeCloud

    

1️⃣ Step 1: Ponto de partida azure-pipelines.yml

• Iremos criar uma variável para workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0' deixando assim a pipeline mais clean

• E vamos comentar todo o stage 2 porque não iremos utiliza-lo agora

trigger:
  branches:
    include:
    -  main

pr:
  branches:
    include:
    -  main

variables:
  workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'


stages:

# 1️⃣ Instala, Valida e Publica o Código

  - stage: InstallAndValidate
    displayName: Install And Validate
    pool: 
      vmImage: 'ubuntu-latest'
    jobs:
    - job: InstallAndValidate
      displayName: 'InstallAndValidate'
      steps:
      - checkout: self
        displayName: 'Checkout code'

      - task: UseNode@1
        inputs:
          version: '15.x'
        displayName: 'Install Node.js'

      - script: npm ci
        workingDirectory: '$(workingDirectory)'
        displayName: 'Install dependencies with ci'

      - script: npm run lint
        workingDirectory: '$(workingDirectory)'
        displayName: 'Linter (ESLint)'      

      - script: |
          npm install --save-dev prettier
          npm run prettier
        workingDirectory: '$(workingDirectory)'
        displayName: 'Formatter (Prettier)'
        continueOnError: 'true'

      - script: npm test 
        workingDirectory: '$(workingDirectory)'
        displayName: 'Run Tests with Coverage'

      - task: PublishPipelineArtifact@1
        inputs:
          targetPath: '$(workingDirectory)'
          artifact: 'validated-source'
          publishLocation: 'pipeline'
        displayName: 'Validated Source'


# # 2️⃣ Builda e publica a imagem no Acr

#   - stage: BuildAndPackage
#     displayName: Build And Package
#     dependsOn: InstallAndValidate
#     condition: succeeded()
#     pool: 
#       vmImage: 'ubuntu-latest'
#     jobs:
#     - job: BuildAndPackage
#       displayName: 'BuildAndPackage'
#       steps:
#       - task: DownloadPipelineArtifact@2
#         inputs:
#           artifactName: 'validated-source'
#           targetPath: '$(Pipeline.Workspace)/validated-source'

#       - task: AzureCLI@2
#         inputs:
#           azureSubscription: 'projeto-user-arm'
#           scriptType: 'bash'
#           scriptLocation: 'inlineScript'
#           inlineScript: | 
#             az acr login --name acrplaygroundproject         
#             docker build -t acrplaygroundproject.azurecr.io/playgroundgapp:$(Build.BuildId) $(Pipeline.Workspace)/validated-source
#             docker push acrplaygroundproject.azurecr.io/playgroundgapp:$(Build.BuildId)
#         displayName: 'Build and Push Docker Image'

2️⃣Step 2: Adicionando o SonarQubeCloud na pipeline e alterando Dockerfile

• Nessa step além de colocar o sonarqube na nossa pipeline iremos:

  • Comentar o ruin build

  • O Sonar pra funcionar corretamente é preciso acrescentar 3 tasks novas:

    • task:SonarCloudPrepare@3 precisa estar no começo da pipeline

    • task:SonarCloudAnalyze@3 e task:SonarCloudPublish@3 devem estar na fase final da pipeline

  • Vamos acresentar o parâmetro fetchDepth: 0 logo após do parâmetro steps:

    •   jobs:
            - job: InstallAndValidate
              displayName: 'InstallAndValidate'
              steps:
              - checkout: self
                fetchDepth: 0 
                displayName: 'Checkout code'
      

  • Também vamos ajustar a task de testes para que, ao executá-lo, seja gerado um arquivo de cobertura (coverage). Esse arquivo será enviado ao SonarQube para análise dos dados. Além disso, definiremos um limiar mínimo (threshold) de cobertura para garantir a qualidade do código.

• Nessa etapa também iremos alterar o Dockerfile que está na raiz do projeto, iremos fazer o build usando o Dockerfile e não na pipeline como foi feito nos últimos laboratórios, agora ele terá a seguinte estrutura:

  •   FROM node:15 AS builder
      WORKDIR /app
      COPY . .
      RUN npm ci --ignore-scripts && npm run build
    
      FROM node:15
      WORKDIR /app
      COPY --from=builder /app .
      RUN npm ci --ignore-scripts --omit=dev 
      EXPOSE 3000
      CMD ["npm", "start"]
    

• Como ficou o azure-pipelines.yml:

  ```yaml trigger: branches: include:

  • main

    pr: branches: include:

  • main

    variables: workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'

stages:

1️⃣ Instala, Valida e Publica o Código

• stage: InstallAndValidate displayName: Install And Validate pool: vmImage: 'ubuntu-latest' jobs:

  • job: InstallAndValidate displayName: 'InstallAndValidate' steps:

    • checkout: self fetchDepth: 0 displayName: 'Checkout code'

    • task: UseNode@1 inputs: version: '15.x' displayName: 'Install Node.js'

    • task: SonarCloudPrepare@3 inputs: SonarQube: 'projeto-user-sonar' organization: 'joaochiroli123' scannerMode: 'cli' configMode: 'manual' cliProjectKey: 'joaochiroli123_Projeto-Pessoal' cliProjectName: 'Projeto Pessoal' cliSources: '.' extraProperties: | extraProperties: | sonar.qualitygate.wait=true
      sonar.javascript.lcov.reportPaths=$(workingDirectory)/coverage/lcov.info

    • script: npm ci workingDirectory: '$(workingDirectory)' displayName: 'Install dependencies with ci'

    • script: npm run lint workingDirectory: '$(workingDirectory)' displayName: 'Linter (ESLint)'

    • script: | npm install --save-dev prettier npm run prettier workingDirectory: '$(workingDirectory)' displayName: 'Formatter (Prettier)' continueOnError: 'true'

• script: npm test -- --coverage --watchAll=false --coverageThreshold='{"global":{"lines":50}}' workingDirectory: '$(workingDirectory)' displayName: 'Run Tests with Coverage' env: CI: true

• task: PublishCodeCoverageResults@2 inputs: codeCoverageTool: 'Clover' summaryFileLocation: '$(workingDirectory)/coverage/clover.xml' reportDirectory: '$(workingDirectory)/coverage'

• task: SonarCloudAnalyze@3 inputs: jdkversion: 'JAVA_HOME_17_X64'

• task: SonarCloudPublish@3 inputs: pollingTimeoutSec: '300'

• task: PublishPipelineArtifact@1 inputs: targetPath: '$(workingDirectory)' artifact: 'validated-source' publishLocation: 'pipeline' displayName: 'Validated Source' ```

  • Após a execução da pipeline podemos verficar no SonarQube que algumas métricas já começam a aparecer

  

3️⃣Step 3: Integração com Slack

• Após criação da sua conta → Vá em canais e crie um projeto

• No canto superior direito vá até os 3 pontos → clique em editar configurações

• 

  Ao abrir Editar configurações → Clique em integrações → Adicionar Apps e procure por Azure Devops Pipelines

  

  • Agora você precisa interagir com o bot usando /azrepos signin para fazer a conexão entre sua pipeline e o slack

  • 

  • Selecione sign in → copie o código que vai aparecer pra você → use este código em enter code

• Agora é preciso fazer um ajuste nas politicas da organização do Azure Devops para que essa integração realmente funcione então siga os passos abaixo:

  • Entre na sua organização (https://dev.azure.com/{yourorganization}).

  • Selecione Organization settings.

    

    • Deixe as configurações seguindo esta estrutura:

    • 

  • Agora basta executar sua pipeline que seu slack vai começar a receber as notificações:

    

4️⃣Step 4: Pipeline final azure-pipelines.yml

    trigger:
      branches:
        include:
        -  main

    pr:
      branches:
        include:
        -  main

    variables:
      workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'


    stages:

    # 1️⃣ Instala, Valida e Publica o Código

      - stage: InstallAndValidate
        displayName: Install And Validate
        pool: 
          vmImage: 'ubuntu-latest'
        jobs:
        - job: InstallAndValidate
          displayName: 'InstallAndValidate'
          steps:
          - checkout: self
            fetchDepth: 0 
            displayName: 'Checkout code'

          - task: UseNode@1
            inputs:
              version: '15.x'
            displayName: 'Install Node.js'

          - task: SonarCloudPrepare@3
            inputs:
              SonarQube: 'projeto-user-sonar'
              organization: 'joaochiroli123'
              scannerMode: 'cli'
              configMode: 'manual'
              cliProjectKey: 'joaochiroli123_Projeto-Pessoal'
              cliProjectName: 'Projeto Pessoal'
              cliSources: '.'
              extraProperties: |
                extraProperties: |
                  sonar.qualitygate.wait=true            
                  sonar.javascript.lcov.reportPaths=$(workingDirectory)/coverage/lcov.info

          - script: npm ci
            workingDirectory: '$(workingDirectory)'
            displayName: 'Install dependencies with ci'

          - script: npm run lint
            workingDirectory: '$(workingDirectory)'
            displayName: 'Linter (ESLint)'      

          - script: |
              npm install --save-dev prettier
              npm run prettier
            workingDirectory: '$(workingDirectory)'
            displayName: 'Formatter (Prettier)'
            continueOnError: 'true'


          - script: npm test -- --coverage --watchAll=false  --coverageThreshold='{"global":{"lines":50}}'
            workingDirectory: '$(workingDirectory)'
            displayName: 'Run Tests with Coverage'
            env:
              CI: true


          - task: PublishCodeCoverageResults@2
            inputs:
              codeCoverageTool: 'Clover'
              summaryFileLocation: '$(workingDirectory)/coverage/clover.xml'
              reportDirectory: '$(workingDirectory)/coverage'


          - task: SonarCloudAnalyze@3
            inputs:
              jdkversion: 'JAVA_HOME_17_X64'


          - task: SonarCloudPublish@3
            inputs:
              pollingTimeoutSec: '300'

          - task: PublishPipelineArtifact@1
            inputs:
              targetPath: '$(workingDirectory)'
              artifact: 'validated-source'
              publishLocation: 'pipeline'
            displayName: 'Validated Source'


    # 2️⃣ Builda e publica a imagem no Acr

      - stage: BuildAndPackage
        displayName: Build And Package
        dependsOn: InstallAndValidate
        condition: succeeded()
        pool: 
          vmImage: 'ubuntu-latest'
        jobs:
        - job: BuildAndPackage
          displayName: 'BuildAndPackage'
          steps:
          - task: DownloadPipelineArtifact@2
            inputs:
              artifactName: 'validated-source'
              targetPath: '$(Pipeline.Workspace)/validated-source'

          - task: AzureCLI@2
            inputs:
              azureSubscription: 'projeto-user-arm'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: | 
                az acr login --name acrplaygroundproject         
                docker build -t acrplaygroundproject.azurecr.io/playgroundgapp:$(Build.BuildId) $(Pipeline.Workspace)/validated-source
                docker push acrplaygroundproject.azurecr.io/playgroundgapp:$(Build.BuildId)
            displayName: 'Build and Push Docker Image'

• Cenário: O time agora precisa versionar builds internamente.

• Tarefas:

  • Gerar uma Docker image

  • Publicar no Azure Container Registry

  • Stages separados

• Desafio real: Garantir que somente builds que passam os testes são publicados.

Pré requisitos

• Ter feito o laboratório Pipeline CI com Validação (https://joaochiroli.com.br/pipeline-ci-com-validacao) iremos usar a mesma estrutura

• Nesta etapa iremos fazer as configurações direto na branch main, desabilite a politica que bloqueia edições e commits direto na branch main.

1️⃣ Step 1: Ajustar configurações no arquivo azure-pipelines.yml

trigger:
  branches:
    include:
    -  main

pr:
  branches:
    include:
    -  main


stages:

# 1️⃣ Instala, Valida e Publica o Código

  - stage: InstallAndValidate
    displayName: Install And Validate
    pool: 
      vmImage: 'ubuntu-latest'
    jobs:
    - job: InstallAndValidate
      displayName: 'InstallAndValidate'
      steps:
      - checkout: self
        displayName: 'Checkout code'

      - task: UseNode@1
        inputs:
          version: '15.x'
        displayName: 'Install Node.js'

      - script: npm ci
        workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
        displayName: 'Install dependencies with ci'

      - script: npm run lint
        workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
        displayName: 'Linter (ESLint)'      

      - script: |
          npm install --save-dev prettier
          npm run prettier 
        workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
        displayName: 'Formatter (Prettier)'
        continueOnError: 'true'

      - script: CI=true npm run test
        workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
        displayName: 'Test (Jest) CI=true'

      - task: PublishPipelineArtifact@1
        inputs:
          targetPath: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
          artifact: 'validated-source'
          publishLocation: 'pipeline'
        displayName: 'Validated Source'

2️⃣ Step 2: Configurar uma conexão com o ARM service Connection

1. Criar o Service Connection ARM:

   • Acesse o projeto no Azure DevOps.

   • Vá até Project Settings (canto inferior esquerdo).

   • Clique em Service connections (na seção “Pipelines”).

   • Clique em New service connection.

   • Escolha Azure Resource Manager.

   • Selecione Service principal (automatic) e clique em Next.

   • Escolha:

     • Subscription: selecione a desejada.

     • Resource Group (opcional): para limitar o escopo.

     • Service connection name: nome amigável para uso nas pipelines.

   • Marque Grant access permission to all pipelines (se necessário).

   • Clique em Save.

     

3️⃣Step 3: Criar o Docker Container Registry no Azure

1. Criar o ACR e Habilitar o Acesso Admin :

• Acesse o portal do Azure.

• No menu lateral, clique em "Container registries".

• Clique em "+ Create".

• Preencha os campos:

  • Subscription: selecione sua assinatura.

  • Resource Group: escolha um existente ou clique em "Create new".

  • Registry name: defina um nome único (ex.: meuacrdevops).

  • Location: selecione a região desejada.

  • SKU: escolha Basic, Standard ou Premium (geralmente Standard para DevOps).

• Clique em "Review + Create".

• Clique em "Create" para finalizar.

1. Habilitar o Acesso Admin (Access Keys)

   1. Após criado, acesse seu ACR (vá em Container registries → Seu Registry).

   2. No menu lateral, clique em "Access keys".

   3. Ative a opção "Admin user" → marque como "Enabled".

   4. Serão exibidos:

      • Username (usuário do ACR)

      • Password / Password2 (senhas geradas)

4️⃣ Step 4: Criar o Dockerfile na raiz do projeto

• Nesta etapa iremos realizar também a instalação dos pacotes e o build da aplicação tudo isso direto no Dockerfile.

• Dockerfile:

    FROM node:15 AS builder
    WORKDIR /app
    COPY . .
    RUN npm ci && npm run build
  
    FROM node:15
    WORKDIR /app
    COPY --from=builder /app .
    RUN npm ci --omit=dev
    EXPOSE 3000
    CMD ["npm", "start"]
  

5️⃣ Step 5: Build e push para o ACR

• Criação do stage que será responsável por fazer o build e o envio da imagem para o ACR:

  • azure-pipelines.yml

# 2️⃣ Builda e publica a imagem no Acr

  - stage: BuildAndPackage
    displayName: Build And Package
    dependsOn: InstallAndValidate
    condition: succeeded()
    pool: 
      vmImage: 'ubuntu-latest'
    jobs:
    - job: BuildAndPackage
      displayName: 'BuildAndPackage'
      steps:
      - task: DownloadPipelineArtifact@2
        inputs:
          artifactName: 'validated-source'
          targetPath: '$(Pipeline.Workspace)/validated-source'

      - task: UseNode@1
        inputs:
          version: '15.x'
        displayName: 'Install Node.js'

      - task: AzureCLI@2
        inputs:
          azureSubscription: 'projeto-user-arm'
          scriptType: 'bash'
          scriptLocation: 'inlineScript'
          inlineScript: | 
            az acr login --name acrplaygroundproject         
            docker build -t acrplaygroundproject.azurecr.io/playgroundgapp:$(Build.BuildId) $(Pipeline.Workspace)/validated-source
            docker push acrplaygroundproject.azurecr.io/playgroundgapp:$(Build.BuildId)
        displayName: 'Build and Push Docker Image'

Imagem salva no meu registry:

• Ponto de atenção: ao usar o comando az acr login --name acrplaygroundproject o acrplaygroundproject tem que ser o nome do seu acr

6️⃣ Step 6: Arquivo yaml finalizado

trigger:
  branches:
    include:
    -  main

pr:
  branches:
    include:
    -  main


stages:

# 1️⃣ Instala, Valida e Publica o Código

  - stage: InstallAndValidate
    displayName: Install And Validate
    pool: 
      vmImage: 'ubuntu-latest'
    jobs:
    - job: InstallAndValidate
      displayName: 'InstallAndValidate'
      steps:
      - checkout: self
        displayName: 'Checkout code'

      - task: UseNode@1
        inputs:
          version: '15.x'
        displayName: 'Install Node.js'

      - script: npm ci
        workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
        displayName: 'Install dependencies with ci'

      - script: npm run lint
        workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
        displayName: 'Linter (ESLint)'      

      - script: |
          npm install --save-dev prettier
          npm run prettier 
        workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
        displayName: 'Formatter (Prettier)'
        continueOnError: 'true'

      - script: CI=true npm run test
        workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
        displayName: 'Test (Jest) CI=true'

      - task: PublishPipelineArtifact@1
        inputs:
          targetPath: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
          artifact: 'validated-source'
          publishLocation: 'pipeline'
        displayName: 'Validated Source'


# 2️⃣ Builda e publica a imagem no Acr

  - stage: BuildAndPackage
    displayName: Build And Package
    dependsOn: InstallAndValidate
    condition: succeeded()
    pool: 
      vmImage: 'ubuntu-latest'
    jobs:
    - job: BuildAndPackage
      displayName: 'BuildAndPackage'
      steps:
      - task: DownloadPipelineArtifact@2
        inputs:
          artifactName: 'validated-source'
          targetPath: '$(Pipeline.Workspace)/validated-source'

      - task: AzureCLI@2
        inputs:
          azureSubscription: 'projeto-user-arm'
          scriptType: 'bash'
          scriptLocation: 'inlineScript'
          inlineScript: | 
            az acr login --name acrplaygroundproject         
            docker build -t acrplaygroundproject.azurecr.io/playgroundgapp:$(Build.BuildId) $(Pipeline.Workspace)/validated-source
            docker push acrplaygroundproject.azurecr.io/playgroundgapp:$(Build.BuildId)
        displayName: 'Build and Push Docker Image'

• Cenário: Um time começa a usar Azure DevOps para um app Node.js.

• Tarefas:

  • Criar pipeline YAML com npm install, lint, test, build.

  • Criar stage de Instalação e Build

  • Exibir badges de status no repositório.

  • Validação de PRs com lint + testes.

  • Usar cache

  • Publicar artefato no Pipeline Artifact

  • Publicar o artefato no Azure Artifact

• Desafio real: Automatizar o mínimo necessário para evitar que código quebrado entre na main.

Pré requisitos

• Azure Devops Account

1️⃣ Step 1: Criar e clonar o Repositório

1. Criar Novo Projeto:

2. Ao entrar no painel do Azure DevOps da sua organização, clique no botão "Novo Projeto", geralmente no canto superior direito ou no centro da tela.

3. Configurar Detalhes do Projeto:

4. Nome do Projeto: Insira "Projeto Pessoal" como nome do projeto.

1. Acesse Repositórios -> Importar Repositório -> Clonar URL: https://github.com/joaochiroli/Devops-Challenge

1. Como a intenção é começar um projeto novo do zero e testar algumas habilidades iremos excluir o conteúdo que está no arquivo azure-pipelines.yml

2️⃣ Step 2: Criar pipeline YAML (azure-pipelines.yml) na branch feature

1. Criar a Branch feature

   1. Clique na branch main → clique em seguida em new branch → crie a branch feature

2. Criar Pipeline:

   1. Vá até a aba Pipelines → Criar Pipeline → Integre sua Pipeline com o Azure Repos

   2. Crie o arquivo azure-pipelines.yml:

trigger: none

pr:
  branches:
    include:
    -  main


stages:

# Instala, Valida e Publica o Código

  - stage: InstallAndValidate
    displayName: Install And Validate
    pool: 
      vmImage: 'ubuntu-latest'
    jobs:
    - job: InstallAndValidate
      displayName: 'InstallAndValidate'
      steps:
      - checkout: self
        path: 'src'
        displayName: 'Checkout code'
      - task: UseNode@1
        inputs:
          version: '15.x'
        displayName: 'Install Node.js'
      - task: Cache@2
        inputs:
          key: 'npm | "$(Agent.OS)" | $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0/package-lock.json'
          restoreKeys: |
            npm | "$(Agent.OS)"
          path: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Cache node_modules'

      - script: npm ci 
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Install dependencies with ci'

      - script: npm run lint
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Linter (ESLint)'

      - script: |
          npm install --save-dev prettier
          npm run prettier
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Formatter (Prettier)'
        continueOnError: true

      - script: CI=true npm run test
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Test (Jest) CI=true'

      - task: PublishPipelineArtifact@1
        inputs:
          targetPath: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
          artifact: 'validated-source'
          publishLocation: 'pipeline'
        displayName: 'Validated Source'

• Tarefas:

  • Criar pipeline YAML com npm install, lint, test, build ✅

  • Criar stage de Instalação e Build ✅

  • Exibir badges de status no repositório ❗

  • Validação de PRs com lint + testes ❗

  • Usar cache ✅

  • Publicar artefato no Pipeline Artifact ✅

  • Publicar o artefato no Azure Artifact❗

3️⃣ Configurar Validação de Pull Request

A configuração pr: no YAML já cuida disso, mas você pode reforçar no portal:

1. Vá para o repositório → Branches

2. Clique no botão ... ao lado da branch main → Branch policies

   

3. Ative:

   • ✔️ Require a minimum number of reviewers

   • ✔️ Check for linked work items

   • ✔️ Build validation → Selecione o pipeline YAML criado (deixe como obrigatório

4. Tarefas:

   • Criar pipeline YAML com npm install, lint, test, build ✅

   • Criar stage de Instalação e Build ✅

   • Exibir badges de status no repositório ❗

   • Validação de PRs com lint + testes ✅

   • Usar cache ✅

   • Publicar artefato no Pipeline Artifact ✅

   • Publicar o artefato no Azure Artifact❗

4️⃣ Exibir badges de status no repositório

1. Vá em Pipelines → clique no pipeline → ⚙️ View YAML → Copie o Status Badge Markdown

   

   

   

2. Adicione ao seu README.md:

mdCopiarEditar![Build Status](https://dev.azure.com/<organization>/<project>/_apis/build/status/<pipeline-name>?branchName=main)

3. Depois de adicionar no README.md basta fazer o commit:

   

4. Tarefas:

   • Criar pipeline YAML com npm install, lint, test, build ✅

   • Criar stage de Instalação e Build ✅

   • Exibir badges de status no repositório ✅

   • Validação de PRs com lint + testes ✅

   • Usar cache ✅

   • Publicar artefato no Pipeline Artifact ✅

   • Publicar o artefato no Azure Artifact❗

5️⃣ Publicar o artefato no Azure Artifact

1. Criar um Azure Artifacts feed no seu projeto DevOps com o nome Projeto Pessoal

2. Adicionar a seguinte task no seu arquivo azure-pipelines.yml:

- task: UniversalPackages@0
        inputs:
          command: 'publish'
          publishDirectory: '$(Build.ArtifactStagingDirectory)'
          feedsToUsePublish: 'internal'
          vstsFeedPublish: 'ee03fcac-046a-4290-b5f4-79508dd47b04/82dd1496-0532-4c69-b3e0-feb482096c20'
          vstsFeedPackagePublish: 'validated-source'
          versionOption: 'patch'

3. Detalhe o vstsFeedPublish é o ID do meu feed no Azure Artifact ou seja, no seu caso será uma ID diferente.

4. Agora salva e executa sua pipeline.

5. No meu caso, tive o seguinte problema: User 'b83dcc85-38ca-4958-b336-c89e9ffbca0d' lacks permission to complete this action. You need to have 'AddPackage'.","@i":"c2baee9b","@l":"Error","SourceContext":"ArtifactTool.Program","UtcTimestamp":"2025-05-19 17:05:49.785Z"})

   1. Neste caso vá até seu feed → Clique na engrenagem no canto superior direito → Permissão → Add User/Group → Contributor → <Nome_do_Projeto_Service_Build>

6. Execute sua pipeline e você irá encontrar um novo artefato gerado no seu feed, neste caso é um artefato de patch mas você pode alterar esta opção.

7. Esta publicação é incremental, ou seja, cada nova execução irá gerar um novo artefato.

   

8. Tarefas:

   • Criar pipeline YAML com npm install, lint, test, build ✅

   • Criar stage de Instalação e Build ✅

   • Exibir badges de status no repositório ✅

   • Validação de PRs com lint + testes ✅

   • Usar cache ✅

   • Publicar artefato no Pipeline Artifact ✅

   • Publicar o artefato no Azure Artifact ✅

6️⃣ Merge com a branch main

1. Agora só basta ir até Azure Repos → Pull Request → Aprovar a PR e fazer o Merge com a branch main

   1. Arquivo azure-pipelines.yml completo:

trigger: none

pr:
  branches:
    include:
    -  main


stages:

# Instala, Valida e Publica o Código

  - stage: InstallAndValidate
    displayName: Install And Validate
    pool: 
      vmImage: 'ubuntu-latest'
    jobs:
    - job: InstallAndValidate
      displayName: 'InstallAndValidate'
      steps:
      - checkout: self
        path: 'src'
        displayName: 'Checkout code'
      - task: UseNode@1
        inputs:
          version: '15.x'
        displayName: 'Install Node.js'
      - task: Cache@2
        inputs:
          key: 'npm | "$(Agent.OS)" | $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0/package-lock.json'
          restoreKeys: |
            npm | "$(Agent.OS)"
          path: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Cache node_modules'

      - script: npm ci 
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Install dependencies with ci'

      - script: npm run lint
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Linter (ESLint)'

      - script: |
          npm install --save-dev prettier
          npm run prettier -- --write
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Formatter (Prettier)'
        continueOnError: true

      - script: CI=true npm run test
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Test (Jest) CI=true'

      - task: PublishPipelineArtifact@1
        inputs:
          targetPath: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
          artifact: 'build-artifact'
          publishLocation: 'pipeline'
        displayName: 'Validated Source'

      - task: UniversalPackages@0
        inputs:
          command: 'publish'
          publishDirectory: '$(Build.ArtifactStagingDirectory)'
          feedsToUsePublish: 'internal'
          vstsFeedPublish: 'ee03fcac-046a-4290-b5f4-79508dd47b04/82dd1496-0532-4c69-b3e0-feb482096c20'
          vstsFeedPackagePublish: 'validated-source'
          versionOption: patch

7️⃣ Bônus - Publicar o artefato no Azure Artifact no formato .npmrc

1. Vá até o arquivo .npmrc na raiz do projeto e coloque as seguintes informações de acordo com o seu feed:

registry=https://pkgs.dev.azure.com/joaochiroli123/ee03fcac-046a-4290-b5f4-79508dd47b04/_packaging/ProjetoPessoal/npm/registry/

engine-strict=true

2. Altere também azure-pipelines.yml:

- task: Npm@1
        inputs:
          command: 'publish'
          workingDir: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
          publishRegistry: 'useFeed'
          publishFeed: 'ee03fcac-046a-4290-b5f4-79508dd47b04/82dd1496-0532-4c69-b3e0-feb482096c20'

3. Execute a Pipeline

4. Provavelmente vai dar um erro dizendo que o arquivo package.json está com uma flag private habilitada o que você pode fazer é adicionar o script abaixo que irá remover o private do seu arquivo de configuração:

- script: |
    echo "🔧 Removendo 'private' de package.json após o npm ci"
    sed -i '/"private": true,/d' package.json
    cat package.json
  workingDirectory: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
  displayName: '🔧 Remoção do campo private após instalação'

5. Execute a pipeline

6. Observação: Quando você realiza a publicação de pacotes do tipo npm no Azure Artifacts, o processo é diferente da publicação via Universal Packages.

   No caso do npm, o Azure utiliza a versão definida no arquivo package.json. Isso significa que, se a versão 0.1.3 já tiver sido publicada no feed, será necessário atualizar o package.json para 0.1.4 (ou superior) para que a nova publicação seja aceita. Caso contrário, a pipeline falhará com erro de versão duplicada.

   Para evitar esse tipo de falha, você pode alterar o valor da versão manualmente ou automatizar a atualização da versão dentro da própria pipeline, utilizando comandos como npm version patch. Essa abordagem garante um controle incremental e contínuo das versões publicadas, evitando conflitos.

   

   Exemplo de script incremental:

     - script: |
              echo "Versão atual:"
              node -p "require('./package.json').version"
   
              npm version patch --no-git-tag-version
   
              echo "Nova versão:"
              node -p "require('./package.json').version"
            workingDirectory: $(Pipeline.Workspace)/validated-source
            displayName: 'Incrementar versão patch no package.json'
   

Deploy a Prometheus monitoring system on an Ubuntu cloud instance. The system should be secured and accessible through a reverse proxy, with proper authentication, and connected to an external Node Exporter. You can follow these steps:

• Install Prometheus and Node Exporter:

Update your package list and install Prometheus with the following commands:

sudo apt update
sudo apt install prometheus prometheus-node-exporter

Verify the installation by checking the status of Prometheus services:

sudo service prometheus status
sudo service prometheus-node-exporter status

Completion Criteria

• Use NGINX as a reverse proxy to forward requests from your server's IP address to Prometheus' default ports as follows:

http://{YOUR-SERVER-IP}/ to Prometheus (<http://localhost:9090/>)
http://{YOUR-SERVER-IP}/metrics/ to the Node Exporter (<http://localhost:9100/>)

• Basic authentication is set up, requiring credentials to access both endpoints.

• Direct access to ports 9090 (Prometheus) and 9100 (Node Exporter) is blocked, and access is only allowed via NGINX.

• Prometheus is scraping metrics from an external Node Exporter running the same saver

Prerequisites

• Azure Devops Account

• Cloud Azure Account

• Created a vm1 on Azure

Step 1: Create Vm1 on Azure and configure the security group

1. Go to Azure Portal.

2. Sign in with your Azure account.

3. In the Azure Portal, search for Virtual Machines in the search bar

4. Click Create → Azure Virtual Machine.

   1. Subscription: Select your Azure subscription.

   2. Resource Group: Choose an existing one or create a new one.

   3. Region: Select the closest or preferred Azure region.

   4. Image: Select the OS (e.g., Ubuntu 20.04 LTS).

   5. VM Size: Choose a size based on your workload (e.g., Standard_B2s for small workloads).

5. Open the NSG you just created.

6. Go to Inbound security rules under Settings.

7. Click + Add Rule to create a new rule.

   1. First, go to this site to know what your public IP is - https://nordvpn.com/pt-br/what-is-my-ip/

   2. Add an Inbound role with source your public IP and destination your VM, you will create two roles one for port 80 and the other for port 22.

   3. 

Step 2: Connect in your VM with putty

1. Go to Putty Gen with your credentials, access Conversions → Import Key, and select .pem key

2. 

   Select on creating your private key

3. Now you will open the Putty

4. Select the public IP of your VM and Go to SSH → Auth → Browser and select your .ppk key

Step 3: Configure and Install Agent Pools in Azure DevOps

1. Go to Azure DevOps.

2. Sign in with your account.

3. Select your organization

4. Click on Organization Settings (bottom left corner).

5. Under Pipelines, select Default.

6. Click + New Agent.

   

7. Select Linux and follow this installation

   

8. When you are executing the Configure Agent with ./config in one step will ask you about the token, so you will need to create this token:

   1. Click on your Profile Icon (top-right corner).

   2. Select Personal Access Tokens.

   3. Click + New Token.

   4. Put the name.

   5. Scope: Full Access.

9. After you enter the token, just click enter with the default settings.

10. Start the Agent with ./run.sh

Step 4: Create, Configure, and test your Pipeline

1. Create file azure-pipelines.yml

2. Enter these configurations:

   1.  trigger:
       - main
      
       pr:
         branches:
           include:
           -  main
      
       stages:
           - stage: Prometheus
           displayName: Prometheus
           pool:
             name: Default
             vmImage: 'vm1'
           jobs:
           - job: Prometheus
             displayName: "Prometheus"
             steps:
             - script: |
                 sudo apt install -y prometheus prometheus-node-exporter nginx apache2-utils
      
                 sudo systemctl enable --now prometheus
                 sudo systemctl enable --now prometheus-node-exporter
                 sudo systemctl enable --now nginx
      
                 systemctl status prometheus --no-pager
                 systemctl status prometheus-node-exporter --no-pager
                 systemctl status nginx --no-pager
      
               displayName: "Prometheus Install"
      
             - script: |
                 echo 'global:
                   scrape_interval: 15s
      
                 scrape_configs:
                   - job_name: "prometheus"
                     static_configs:
                       - targets: ["localhost:9090"]
      
                   - job_name: "node_exporter"
                     static_configs:
                       - targets: ["localhost:9100"]
                 ' | sudo tee /etc/prometheus/prometheus.yml
      
                 sudo systemctl restart prometheus
               displayName: "Configurar Prometheus para coletar métricas"
      
             - script: |
                 sudo ufw allow ssh
                 sudo ufw allow http
                 sudo ufw allow https
                 sudo ufw deny 9090
                 sudo ufw deny 9100
                 sudo ufw enable
               displayName: "Configurar Acessos"
      
             - script: |
                 echo 'server {
                     listen 80;
                     server_name _;
      
                     location / {
                         proxy_pass http://127.0.0.1:9090/;
                         proxy_set_header Host $host;
                         proxy_set_header X-Real-IP $remote_addr;
                         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                         auth_basic "Restricted Access";
                         auth_basic_user_file /etc/nginx/.htpasswd;
                     }
      
                     location /metrics/ {
                         proxy_pass http://127.0.0.1:9100/;
                         proxy_set_header Host $host;
                         proxy_set_header X-Real-IP $remote_addr;
                         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                         auth_basic "Restricted Access";
                         auth_basic_user_file /etc/nginx/.htpasswd;
                     }
                 }' | sudo tee /etc/nginx/sites-available/default
      
                 sudo systemctl restart nginx
               displayName: "Configurar Nginx"
      
             - script: |
                 echo "Setting up Nginx authentication..."
      
                 # Create .htpasswd file and add user
                 echo "senha123" | sudo htpasswd -c -i /etc/nginx/.htpasswd joaochiroli
      
                 sudo systemctl restart nginx
               displayName: "Configure Basic Auth for Nginx"
      

3. Test the configuration

4. See this Dashboard

Deploy the provided application to your chosen cloud provider using any service that runs the application as a Docker container. Then, create a test plan for the application's home page and generate a testing report using JMeter.

The application needs to:

Available for anyone with Internet access only during the challenge recording

Prerequisites

• Azure Devops Account

• Cloud Azure Account

• Completed Challenge 1. This is a continuation of Series 1. Challenge 1 link: https://hashnode.com/edit/cm795upao000609js5scu0j9u

Step 1: Create Azure Container Registry and Azure Devops Connections

Create Azure Registry:

1. Go to the Azure portal.

2. Create a new resource group.

3. Click on "Container registries".

4. Click on "Create container registry".

5. On the "Create container registry" page, enter the following information:

• Registry name - Enter mdcregistryID. # The name needs to be unique change the last two letters by the initials of your name

• Region - Select the region where you want to create your registry.

• Pricing tier - Select the pricing tier that you want to use for your registry.

• Security - Select the security options that you want to use for your registry.

• Choose the Resource Group you created earlier

Azure Devops Connections:

1. Navigate to Azure DevOps Service Connections

2. Sign in to Azure DevOps.

3. Select your organization and project.

4. In the left sidebar, go to Project Settings.

5. Under Pipelines, click Service Connections.

6. Click New Service Connection.

7. Choose Docker Registry

8. Authentication Type Select Service Principal

9. Enter your settings and click create

Step 2: Create Kubernetes

1. Log in to Azure

2. Log in to your Azure account via CLI: az login

3. Create the Kubernetes cluster: az aks create --resource-group projeto-flask --name k8s-cluster --node-count 2 --enable-addons monitoring --generate-ssh-keys

4. Step 3: Get ACR credentials and create a secret on Kubernetes

5. Get ACR name: az acr list --query "[].{Name:name, ResourceGroup:resourceGroup}" --output table

6. Get Docker Server Credential: az acr show --name Your_ACR_Name --query loginServer --output tsv

7. Get Docker Username: az acr credential show --name Your_ACR_Name --query username --output tsv

8. Get Docker Password: az acr credential show --name Your_ACR_Name --query passwords[0].value --output tsv

9. Access your Kubernetes: az aks get-credentials --resource-group Your_Resource_Group_Name --name mdc-aks

10. Create Secret:

      kubectl create secret docker-registry acr-secret \
              --docker-server=Your_Docker_Server \ 
              --docker-username=Your_Docker_Username \ 
              --docker-password=Your_Docker_Password \
    

11. Configure Assign AcrPull Role:

    ACR_ID=$(az acr show --name mdcrepositorychiroli --query "id" -o tsv)
    
    AKS_ID=$(az aks show --resource-group projeto-flask --name k8scluster --query "identityProfile.kubeletidentity.objectId" -o tsv)
    
    az role assignment create --assignee $AKS_ID --role AcrPull --scope $ACR_ID
    

Step 4: Create Azure Resource Manager on Connections

1. Navigate to Azure DevOps Service Connections

2. Sign in to Azure DevOps.

3. Select your organization and project.

4. In the left sidebar, go to Project Settings.

5. Under Pipelines, click Service Connections.

6. Click New Service Connection.

7. Choose Azure Resource Manager

8. Enter your settings, you can use the default setting and click create.

Step 5: Create Dockerfile

1. Access Azure Repo

2. Go to: assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0

3. Edit Dockerfile

# Etapa de build
FROM node:15 AS builder

# Define o diretório de trabalho
WORKDIR /app

# Copia os arquivos necessários
COPY package.json package-lock.json ./

# Instala dependências
RUN npm install

# Copia o restante dos arquivos da aplicação
COPY . .

# Faz o build da aplicação (se necessário)
RUN npm run build

# Etapa de produção
FROM node:15

# Define o diretório de trabalho
WORKDIR /app

# Copia arquivos do estágio anterior
COPY --from=builder /app /app

# Instala as dependências de produção
RUN npm install --only=production

# Define o comando para iniciar a aplicação
CMD ["npm", "start"]

# Exposição de porta (opcional)
EXPOSE 3000

Step 6: Create Deployment and Load Balancer

1. Access Azure Repo

2. Access the repository on the same place where azure-pipelines.yml and create the file deployment_service.yml

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nodejs-deployment
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nodejs
      template: 
        metadata:
          name: nodejs
          labels:
            app: nodejs  
        spec:
          containers:
            - name: nodejsapp
              image: mdcrepositorychiroli.azurecr.io/node.js:latest
              ports:
                - containerPort: 3000
          imagePullSecrets:
            - name: acr-secret    
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: nodejs-service
      labels: 
        app: nodejs
    spec:
      type: LoadBalancer 
      selector:
        app: nodejs
      ports: 
        - port: 3000
          targetPort: 3000
   

Step 7: Create a file for the Jmeter test

1. Access Azure Repo

2. Access the repository on the same place where azure-pipelines.yml and create the file test.jmx

    <?xml version="1.0" encoding="UTF-8"?>
    <jmeterTestPlan version="1.2" properties="5.0" jmeter="5.6.3">
      <hashTree>
        <!-- Test Plan -->
        <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Basic Test Plan" enabled="true">
          <stringProp name="TestPlan.comments"></stringProp>
        </TestPlan>
        <hashTree>
          <!-- Thread Group -->
          <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Load Test Group" enabled="true">
            <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
   
            <!-- Adicionando o Loop Controller -->
            <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControllerGui" testclass="LoopController" testname="Loop Controller" enabled="true">
              <boolProp name="LoopController.continue_forever">false</boolProp>
              <stringProp name="LoopController.loops">1</stringProp>
            </elementProp>
   
            <stringProp name="ThreadGroup.num_threads">10</stringProp>
            <stringProp name="ThreadGroup.ramp_time">5</stringProp>
            <boolProp name="ThreadGroup.scheduler">false</boolProp>
          </ThreadGroup>
          <hashTree>
            <!-- HTTP Sampler -->
            <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="HTTP Request" enabled="true">
              <stringProp name="HTTPSampler.domain">${__P(host, localhost)}</stringProp>
              <stringProp name="HTTPSampler.port">3000</stringProp>
              <stringProp name="HTTPSampler.protocol">http</stringProp>
              <stringProp name="HTTPSampler.path">/</stringProp>
              <stringProp name="HTTPSampler.method">GET</stringProp>
            </HTTPSamplerProxy>
            <hashTree/>
          </hashTree>
        </hashTree>
      </hashTree>
    </jmeterTestPlan>
   

Step 7: Configure the Pipeline

1. Access Azure Repo

2. Edit file azure-pipelines.yml

3. With the new configuration and the configuration of the last challenge the pipeline looks like this:

trigger:
- main

pr:
  branches:
    include:
    -  main

stages:
  - stage: BuildAndTest
    displayName: Build and Test Job
    pool:
      vmImage: 'ubuntu-latest'
    jobs:
    - job: Build
      displayName: 'Build and Test Job'
      steps:
      - checkout: self
        path: 'src'
        displayName: 'Checkout code'

      - task: UseNode@1
        inputs:
          version: '15.x'
        displayName: 'Install Node.js'

      - script: npm install
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Install dependencies'

      - script: npm run lint
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Linter (ESLint)'

      - script: npm install --save-dev prettier
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Install Formatter (Prettier)'

      - script: npm run prettier -- --write
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Format Code (Prettier)'

      - script: CI=true npm run test
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Test (Jest)'

      - script: npm run build
        workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
        displayName: 'Run Build'

      - task: Docker@2
        inputs:
          containerRegistry: 'MdcRegistry'
          repository: 'Node.js'
          command: 'buildAndPush'
          Dockerfile: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0/Dockerfile'
          buildContext: '$(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0'
          tags: 'latest'
        displayName: 'Build and Push Docker Image'
        continueOnError: true  

      - task: AzureCLI@2
        inputs:
          azureSubscription: 'MdcAzureRm'
          scriptType: 'bash'
          scriptLocation: 'inlineScript'
          inlineScript: |
            az aks get-credentials --resource-group projeto-flask --name k8scluster --overwrite-existing
            kubectl apply -f $(Build.SourcesDirectory)/deployment_service.yml
            kubectl get services
        displayName: 'Execute Kubernetes'
        continueOnError: true


      - script: |
          echo "Installing JMeter..."
          sudo apt-get update -y
          sudo apt-get install -y wget openjdk-11-jre  # Install Java and wget

          wget https://downloads.apache.org//jmeter/binaries/apache-jmeter-5.6.3.tgz
          tar -xvzf apache-jmeter-5.6.3.tgz
          sudo mv apache-jmeter-5.6.3 /opt/jmeter

          # Adiciona JMeter ao PATH corretamente
          echo "export PATH=/opt/jmeter/bin:\$PATH" | sudo tee -a /etc/profile
          export PATH=/opt/jmeter/bin:$PATH  # Atualiza PATH na sessão atual

          echo "JMeter installed successfully."
        displayName: 'Install JMeter'

      - script: |
          echo "Creating JMeter test file..."
          cp $(Build.SourcesDirectory)/test.jmx /opt/jmeter/test.jmx
        displayName: 'Create JMeter Test File'

      - task: AzureCLI@2
        inputs:
          azureSubscription: 'MdcAzureRm'
          scriptType: 'bash'
          scriptLocation: 'inlineScript'
          inlineScript: |
            NODEJS_IP=$(kubectl get svc nodejs-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
            echo "##vso[task.setvariable variable=NODEJS_IP]$NODEJS_IP"
            echo "Fetched IP: $NODEJS_IP"
        displayName: 'Retrieve NodeJS Service External IP'
        continueOnError: true

      - script: |
          export PATH=/opt/jmeter/bin:$PATH
          jmeter -v
          jmeter -n -t /opt/jmeter/test.jmx -l /opt/jmeter/results.jtl -j jmeter.log -Jhost=$NODEJS_IP
          cat /opt/jmeter/results.jtl
          cat jmeter.log
        displayName: 'Run JMeter'

Step 8: Access the application

1. Log in to Azure

2. Log in to your Azure account via CLI: az login

3. Access your Kubernetes: az aks get-credentials --resource-group Your_Resource_Group_Name --name mdc-aks

4. Execute the command az get services and access the page with the external IP

5. Access http://Your_external_ip:3000/

Step 8: See the Jmeter test results

Set up a new repository and CI pipeline using any code version provider The CI steps should be created. The pipeline should run the following steps:

• Install dependencies npm install

• Linter (ESLint) npm run lint

• Formatter (Prettier) npm run prettier

• Test (Jest) CI=true npm run test

• Build npm run build

The pipeline should be successful. Please provide some pull requests to show pass or fail status in the CI pipeline.

Prerequisites

• Azure Devops Account

Step 1: Create and clone the Repository

1. Create New Project:

2. Once inside your organization's Azure DevOps dashboard, click on the "New Project" button, usually at the top right or in the center of the screen.

3. Configure Project Details:

4. Project Name: Enter "DevOps Challenge" as the project name.

5. Go to Repos -> Import Repository -> Clone URL: https://github.com/joaochiroli/Devops-Challenge

Step 2: Create and configure azure-pipelines.yml

1. Create file azure-pipelines.yml

    trigger:
    - main
   
    pr:
      branches:
        include:
        -  main
   
    stages:
      - stage: BuildAndTest
        displayName: Build and Test Job
        pool:
          vmImage: 'ubuntu-latest'
        jobs:
        - job: Build
          displayName: 'Build and Test Job'
          steps:
          - checkout: self
            path: 'src'
            displayName: 'Checkout code'
   
          - task: UseNode@1
            inputs:
              version: '15.x'
            displayName: 'Install Node.js'
   
          - script: npm install
            workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
            displayName: 'Install dependencies'
   
          - script: npm run lint
            workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
            displayName: 'Linter (ESLint)'
   
          - script: npm install --save-dev prettier
            workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
            displayName: 'Install Formatter (Prettier)'
   
          - script: npm run prettier -- --write
            workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
            displayName: 'Format Code (Prettier)'
   
          - script: CI=true npm run test
            workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
            displayName: 'Test (Jest)'
   
          - script: npm run build
            workingDirectory: $(Build.SourcesDirectory)/assessment-cc-sre-kubernetes-sr-01/codebase/rdicidr-0.1.0
            displayName: 'Run Build'
   

2. Commit and Save

3. Explanations:

   1. I created trigger main and pr to start my pipeline. I use 1 stage to Build my application.

   2. Task: UseNode@1 → Define the Node.js version

   3. The other tasks do what the above steps ask, and the key to this build is to run it in the correct repository.

Step 3: Results