DEV Community: Tomatito

Prácticas de observabilidad con Prometheus y Grafana en una aplicación FastAPI

Tomatito — Sat, 05 Jul 2025 12:28:24 +0000

``# 🧠 Observability Practices with Prometheus and Grafana in a FastAPI Application 🚀

Tags: #observability #devops #python #grafana #prometheus

🔍 Introduction

In the current era of cloud-native applications and microservices, systems are becoming increasingly complex and distributed. Monitoring is no longer enough. We need to go deeper—observability is the answer.

Observability is the practice of understanding the internal state of a system based on the data it produces, namely:

Metrics (numerical values over time)
Logs (structured/unstructured event data)
Traces (information about distributed request paths)

Where monitoring tells you what is broken, observability helps you understand why it's broken.

🌐 Why Observability Matters

Imagine a user complains that your application is slow. You check CPU usage and it looks fine. So… where do you look next?

With good observability, you can:

Trace a request end-to-end (tracing)
Visualize request volume or error rates (metrics)
Drill into error logs with detailed context (logs)

These insights are essential to maintain performance, uptime, and a smooth developer experience.

📊 Core Pillars of Observability

Metrics: Time-series data about your systems (e.g., requests per second, CPU usage).
Logs: Records of events generated by applications (e.g., errors, warnings).
Traces: Information about a single request as it moves through multiple services.

When combined, these pillars help teams quickly answer complex questions like:

“What is the latency for requests to /login over the last 5 minutes, and what caused the spike at 10:05am?”

⚒️ Tools We Will Use

For this article, we implement observability using:

🐍 FastAPI – a modern web framework for Python
📈 Prometheus – open-source metrics collection system
📊 Grafana – dashboard and visualization tool
🐳 Docker Compose – to run everything easily

This setup will let us collect, visualize, and analyze metrics from a running Python app.

🚀 Implementation Overview

We'll deploy a FastAPI application with instrumentation that tracks:

Total number of requests
HTTP methods and response codes
Response time per endpoint

These metrics will be exposed at /metrics and scraped by Prometheus every 5 seconds.

Grafana will be connected to Prometheus to show:

Request rates by endpoint
Latency trends
Real-time traffic behavior

✅ Benefits of This Approach

Feature	Benefit
🔎 Real-time Monitoring	Track endpoint usage and performance instantly
📊 Visual Dashboards	Easy-to-understand graphs in Grafana
⚡ Fast Debugging	Quickly spot slow endpoints or traffic spikes
🧩 Extendable	Add logs (ELK), tracing (Jaeger), and alerts

This observability stack is ideal for microservices, APIs, CI/CD pipelines, and production monitoring.

🎯 When to Use Prometheus + Grafana

Use Case	Recommendation
Lightweight metrics	✅ Prometheus excels here
Kubernetes/Containers	✅ Native support with service discovery
Flexible dashboards	✅ Grafana is the gold standard
Need logs/traces	🔁 Combine with ELK, Loki, or Jaeger

🧠 Best Practices for Observability

Use consistent labeling for metrics (e.g., method, endpoint, status)
Expose a /metrics endpoint in every service
Avoid high-cardinality metrics (e.g., per-user metrics)
Add alerts for SLOs and anomalies
Centralize your dashboards for all environments

📚 Summary

Observability is essential for modern application health and performance. By implementing it with tools like Prometheus and Grafana, you gain:

Deep visibility into behavior and usage
Data to improve reliability and performance
Faster root-cause analysis for issues

🧪 Code Walkthrough & Example Setup

Below is the code section that shows how to set up:

A FastAPI app instrumented with Prometheus metrics
A Dockerfile for containerization
A docker-compose.yml to launch Prometheus and Grafana
A preconfigured Grafana dashboard JSON

👉 This section is fully detailed in the next Markdown block: 📦 Code & Configuration

📥 Resources

📢 Stay Connected

If this helped you, consider giving it a ❤️, commenting, or following me on Dev.to.

You can also join our developer community on Telegram to discuss DevOps, APIs, and observability!

Enterprise Architecture Patterns

Tomatito — Sun, 27 Apr 2025 05:26:38 +0000

Enterprise Architecture Patterns

Concept

Enterprise Architecture (EA) patterns are reusable solutions to common design problems in the development of enterprise systems. They represent a set of principles, guidelines, and best practices that help organizations create and manage their IT infrastructure effectively.

What are Enterprise Architecture Patterns?

Enterprise Architecture patterns are predefined templates or models that represent an organization’s IT architecture.

These patterns provide a structured approach to designing and implementing enterprise systems, and are reusable across different applications and projects.
EA patterns are intended to simplify the complexity of enterprise architecture and reduce the time and effort required to create effective solutions.

Why are Enterprise Architecture Patterns Needed?

Enterprise Architecture patterns are essential because they offer a number of significant benefits to organizations.

Firstly, they provide a standardized approach to system design, improving the consistency and quality of solutions.
Secondly, they help organizations achieve more efficient use of resources by reusing existing patterns.
Thirdly, they support the alignment of IT architecture with business objectives, enhancing the overall strategic effectiveness of the organization. ##### What Problems Do Enterprise Architecture Patterns Solve?
Enterprise Architecture patterns solve a variety of common design problems faced by organizations.
Help organizations create scalable and flexible systems that can adapt to changing business needs.
Contribute to improving system reliability, security, and performance.
facilitate the integration of disparate systems and technologies, making it easier to manage complex IT environments.

Some Popular Enterprise Architecture Patterns

There are many Enterprise Architecture patterns available, each addressing a specific design problem. Below are some of the most popular:

Service-Oriented Architecture (SOA): Focuses on creating services that can be reused across multiple applications.
Microservices Architecture: Breaks down applications into small, independently deployable services, similar to SOA.
Event-Driven Architecture (EDA): Centers on the production, detection, and consumption of events to trigger business processes.
Layered Architecture: Organizes applications into a set of logical layers that work together to deliver functionality.
Big Data Architecture: Manages and processes large volumes of data in real time.

Combining Enterprise Architecture Patterns

Enterprise Architecture patterns can be combined to create more complex and tailored solutions. For example, it is possible to combine SOA with EDA to create an event-driven SOA, or to integrate Microservices Architecture with Layered Architecture to achieve scalable and flexible systems. Combining patterns allows organizations to create customized solutions that perfectly fit their specific needs.

Detailed Architectural and Design Patterns

Once you understand the combination of enterprise architecture patterns, it's important to delve into more specific patterns that guide the technical construction of applications. These design and architectural patterns cover aspects such as web presentation, data distribution, business logic, session state management, and data persistence. Below, we describe some of the most commonly used patterns in the development of modern enterprise systems, which can help structure applications in an efficient, flexible, and scalable manner.
These patterns are applied to solve common problems that arise in the development of complex systems, such as managing user interaction, separating responsibilities, efficiently distributing data, and improving consistency and performance in distributed systems. By understanding and using these patterns appropriately, organizations can optimize their applications, reduce complexity, and facilitate long-term maintenance.

Web Presentation Patterns

Model View Controller > Splits user interface interaction into three distinct roles.
Page Controller > An object that handles a request for a specific page or action on a Web site.
Front Controller >A controller that handles all requests for a Web site.
Template View >Renders information into HTML by embedding markers in an HTML page.
Transform View >A view that processes domain data element by element and transforms it into HTML.
Two Step View >Turns domain data into HTML in two steps: first by forming some kind of logical page, then rendering the logical page into HTML.
Application Controller >A centralized point for handling screen navigation and the flow of an application.

Distribution Patterns

Remote Facade > Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network.
Data Transfer Object > An object that carries data between processes in order to reduce the number of method calls.

Offline Concurrency Patterns

Optimistic Offline Lock > Prevents conflicts between concurrent business transactions by detecting a conflict and rolling back the transaction.
Pessimistic Offline Lock > Prevents conflicts between concurrent business transactions by allowing only one business transaction at a time to access data.
Coarse-Grained Lock > Locks a set of related objects with a single lock.
Implicit Lock > Allows framework or layer supertype code to acquire offline locks.

Session State Patterns

Client Session State > Stores session state on the client.
Server Session State > Keeps the session state on a server system in a serialized form.
Database Session State > Stores session data as committed data in the database.

Base Patterns

Gateway >An object that encapsulates access to an external system or resource.
Mapper >An object that sets up a communication between two independent objects.
Layer Supertype >A type that acts as the supertype for all types in its layer.
Separated Interface >Defines an interface in a separate package from its implementation.
Registry >A well-known object that other objects can use to find common objects and services.
Value Object >A small simple object, like money or a date range, whose equality isn't based on identity.
Money >Represents a monetary value.
Special Case >A subclass that provides special behavior for particular cases.
Plugin >Links classes during configuration rather than compilation.
Service Stub >Removes dependence upon problematic services during testing. WSDL
Record Set >An in-memory representation of tabular data.

Domain Logic Patterns

Transaction Script >Organizes business logic by procedures where each procedure handles a single request from the presentation.
Domain Model >An object model of the domain that incorporates both behavior and data.
Table Module >A single instance that handles the business logic for all rows in a database table or view.
Service Layer >Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.

Data Source Architectural Patterns

Table Data Gateway >An object that acts as a Gateway (466) to a database table. One instance handles all the rows in the table.
Row Data Gateway >An object that acts as a Gateway (466) to a single record in a data source. There is one instance per row.
Active Record >An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
Data Mapper >A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the mapper itself.

Object-Relational Behavioral Patterns

Unit of Work >Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
Identity Map > Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them.
Lazy Load >An object that doesn't contain all of the data you need but knows how to get it.

Object-Relational Structural Patterns

Identity Field >Saves a database ID field in an object to maintain identity between an in-memory object and a database row.
Foreign Key Mapping >Maps an association between objects to a foreign key reference between tables.
Association Table Mapping >Saves an association as a table with foreign keys to the tables that are linked by the association.
Dependent Mapping > Has one class perform the database mapping for a child class.
Embedded Value >Maps an object into several fields of another object's table.
Serialized LOB >Saves a graph of objects by serializing them into a single large object (LOB), which it stores in a database field.
Single Table Inheritance >Represents an inheritance hierarchy of classes as a single table that has columns for all the fields of the various classes.
Class Table Inheritance >Represents an inheritance hierarchy of classes with one table for each class.
Concrete Table Inheritance >Represents an inheritance hierarchy of classes with one table per concrete class in the hierarchy.
Inheritance Mappers >A structure to organize database mappers that handle inheritance hierarchies.

Object-Relational Metadata Mapping Patterns

Metadata Mapping >Holds details of object-relational mapping in metadata.
Query Object >An object that represents a database query.
Repository >Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

Medio de Publicacion DEV

https://dev.to/jose25upt/enterprise-architecture-patterns-l9c/edit

Github y Automatizacion:

https://github.com/Jose25UPT/Enterprise-Architecture-Patterns

Software Design Principles

Tomatito — Tue, 08 Apr 2025 04:50:52 +0000

What is a Principle?

A principle is a broad behavioral guideline applicable to many situations. In general, a principle doesn't tell you exactly what to do, but rather gives you clues as to the correct course of action across a wide range of situations. The details are up to you.

Don't Repeat Yourself (DRY)

You should avoid repeating code as much as possible.
We must keep in mind that we must find ways to reuse code we've already created to avoid getting tangled up.

Why is it important?

➢ Makes the code more maintainable: Avoiding repeating code helps us make changing functionality more practical.
➢ Reduces code size: It makes it more readable and understandable because there's less code to understand.
➢ Saves time: By having the code available for reuse, we can use it and shorten coding time.

KISS = Keep It Simple [,] Stupid

This principle establishes that code, design, documentation, and everything related to it should be simple.

It establishes that:

➢ Software should have as few components as possible
➢ No unused functionality
➢ Documentation should contain strict and necessary information
➢ Code should be as obvious and simple as possible
➢ Design should be simple

Why is it important?

➢ More maintainable projects. The code is easier to maintain and update.
➢ Less documentation. There are fewer weird things to document by making the code simpler.
➢ Faster debugging. By reducing complexity, errors can be found more quickly.
➢ Greater economic returns. The three effects above allow the initial financial investment in the code created to yield greater returns.

"Simplicity is the ultimate sophistication."

The following principles are based on these two principles.

SOLID Principles

SOLID is an acronym that brings together five key principles for efficient, replicable, maintainable, and scalable software development.

S - Single Responsibility Principle (SRP)
- “Every class should have a single responsibility: It should have a single purpose in the system, and there should be only one reason to change it.”
Each class should have a single responsibility, a single task that should be applied to classes, components, and microservices.

O - Open/Closed Principle (OCP)

“…code should be open for extension but closed to modification. When we have a good design, we just don’t have to change code much to add new features.”

A software entity (class) should be open to extension (its functionality can be expanded with external entities) but closed to modification.

If one of the extensions doesn't work, you can remove it without damaging the original code.

L - Liskov Substitution Principle (LSP)

“Objects of subclasses should be substitutable for objects of their superclasses throughout our code.”

The Liskov Substitution Principle speaks of interfaces: if a software entity uses a class, it should be able to use classes derived from that class.

I - Interface Segregation Principle (ISP)

“A client-specific interface for a particular set of clients.”

Instead of one large, common interface, multiple scenario-specific interfaces should be planned to improve decoupling and change management:

Clients (software entities) that use a software entity (originally a class) should not be forced to depend on methods they don't use. To address this, large interfaces should be segregated, i.e., broken up, into smaller ones.

D - Dependency Inversion Principle (DIP)

“It is better to depend on interfaces or abstract classes than it is to depend on concrete classes.”

The Dependency Inversion Principle states that high-level modules, that is, those closest to human ideas of what the software should do, should not depend on low-level modules (those closest to the implementation details for the computer).

Both should depend on the abstractions of the problem (interfaces). Furthermore, the implementation details should depend on the abstractions as well.

Considerations When Applying the Principles

The SOLID Principles can be applied to all phases of object-oriented programming (OOP), as well as to functional programming (FP) and multi-paradigm programming. However, they should always be applied with proper planning and methodologies. And above all, without excessive rigidity. Excessive rigidity and rigor can make these principles the ultimate goal and hinder the development process.

Conclusion

Design principles are not simply academic rules; they are practical tools that allow you to build quality software in the real world. Applying them reduces long-term development time, improves collaboration between teams, and ensures that your code scales safely.

Code :

Application Principle

SRP The Message class is only responsible for representing a message.
OCP We can add new delivery types without modifying DeliveryService.
LSP EmailSend and SMSSend can be used without breaking the system logic.
ISP The Sender interface defines only what is necessary: send(message).
DIP DeliveryService depends on an abstraction (Sender), not on concrete classes.

DEV Community: Tomatito

Prácticas de observabilidad con Prometheus y Grafana en una aplicación FastAPI

🔍 Introduction

🌐 Why Observability Matters

📊 Core Pillars of Observability

⚒️ Tools We Will Use

🚀 Implementation Overview

✅ Benefits of This Approach

🎯 When to Use Prometheus + Grafana

🧠 Best Practices for Observability

📚 Summary

🧪 Code Walkthrough & Example Setup

📥 Resources

📢 Stay Connected

Enterprise Architecture Patterns

Enterprise Architecture Patterns

Concept

What are Enterprise Architecture Patterns?

Why are Enterprise Architecture Patterns Needed?

Some Popular Enterprise Architecture Patterns

Combining Enterprise Architecture Patterns

Detailed Architectural and Design Patterns

Web Presentation Patterns

Distribution Patterns

Offline Concurrency Patterns

Session State Patterns

Base Patterns

Domain Logic Patterns

Data Source Architectural Patterns

Object-Relational Behavioral Patterns

Object-Relational Structural Patterns

Object-Relational Metadata Mapping Patterns

Medio de Publicacion DEV

Github y Automatizacion:

Software Design Principles

What is a Principle?

Don't Repeat Yourself (DRY)

Why is it important?

KISS = Keep It Simple [,] Stupid

Why is it important?

The following principles are based on these two principles.

SOLID Principles

S - Single Responsibility Principle (SRP)

O - Open/Closed Principle (OCP)

L - Liskov Substitution Principle (LSP)

I - Interface Segregation Principle (ISP)

D - Dependency Inversion Principle (DIP)

Considerations When Applying the Principles

Conclusion

Code :

Application Principle