Forem: Victor Costa

Grafana 'no pg_hba.conf entry for host' error

Victor Costa — Fri, 03 Oct 2025 17:17:38 +0000

When deploying grafana with an aws rds postgres as backend db I came across the following error:

Error: ✗ pq: no pg_hba.conf entry for host "<my-custom.grafana.pod.ip>", user "<some-user>", database "<my-custom-db-name>", no encryption

Turns out the rds was deployed with a default parameter group, which had rds.force_ssl set to 1. For my scenario having it turned off was fine. The solution was to re-deploy (a reboot also works) the rds with a customized parameter group based off of the default one with rds.force_ssl set to 0.

Python logger

Victor Costa — Sun, 04 Aug 2024 15:36:18 +0000

Context

There are too many posts defining how to configure python logs and some are too noise others are incomplete.

An example with json logger at the end

So here’s my version of it that just works and suits my purposes well

Example with plain text output

logger = logging.getLogger(__name__)
# Change this level according to your needs
logger.setLevel(level=os.getenv("LOG_LEVEL", "INFO"))
logger.propagate = False
stdout = logging.StreamHandler(stream=sys.stdout)
# Default level for root logger is NOTSET which means all messages will be logged
# I prefer having this as is to avoid two places controlling what gets to output
# Leaving this to logger.setLevel to define what should be printed is more flexible undless devs are not allowed to control this (for log volume purposes, for example)
# https://docs.python.org/3/library/logging.config.html
# stdout.setLevel(logging.DEBUG)
fmt = logging.Formatter(
    "%(name)s: %(asctime)s | %(levelname)s | %(filename)s:%(lineno)s | %(process)d >>> %(message)s"
)
stdout.setFormatter(fmt=fmt)
logger.addHandler(stdout)


# YOUR CODE BELOW

# Database connection
import psycopg2
from psycopg2.extras import RealDictCursor

logger.info(
    f"Connecting to database '{rds_host}' on port '{rds_port}' as user '{rds_user}' to database '{rds_database}'"
)
logger.debug("Debug message when creating connection to database")

connection = psycopg2.connect(
    host=rds_host,
    port=rds_port,
    user=rds_user,
    password=rds_password,
    database=rds_database,
    cursor_factory=RealDictCursor,
)

Sample output for log level set as INFO :

__main__: 2024-06-25 06:15:12,171 | INFO | main.py:39 | 61869 >>> Connecting to database 'mydbinstance.cjzjxjzjzjzj.us-west-2.rds.amazonaws.com' on port '5432' as user 'postgres' to database 'postgres'

Sample output for log level set as DEBUG :

__main__: 2024-06-25 06:17:38,664 | INFO | main.py:39 | 62437 >>> Connecting to database 'mydbinstance.cjzjxjzjzjzj.us-west-2.rds.amazonaws.com' on port '5432' as user 'postgres' to database 'postgres'
__main__: 2024-06-25 06:17:38,664 | DEBUG | main.py:42 | 62437 >>> Debug message when creating connection to database

Example with json output

Using python-json-logger dependency

logger = logging.getLogger(__name__)
# Change this level according to your needs
logger.setLevel(level=os.getenv("LOG_LEVEL", "INFO"))
logger.propagate = False
log_handler = logging.StreamHandler(stream=sys.stdout)
# Default level for root logger is NOTSET which means all messages will be logged
# https://docs.python.org/3/library/logging.config.html
# stdout.setLevel(logging.DEBUG)
fmt = "%(name)s: %(asctime)s | %(levelname)s | %(filename)s:%(lineno)s | %(process)d >>> %(message)s"
formatter = jsonlogger.JsonFormatter(fmt=fmt)
log_handler.setFormatter(fmt=formatter)
logger.addHandler(log_handler)

{"name": "__main__", "asctime": "2024-07-01 15:28:07,119", "levelname": "INFO", "filename": "main.py", "lineno": 42, "process": 60945, "message": "Connecting to database 'mydbinstance.cjzjxjzjzjzj.us-west-2.rds.amazonaws.com' on port '5432' as user 'postgres' to database 'postgres'"}
{"name": "__main__", "asctime": "2024-07-01 15:28:07,119", "levelname": "INFO", "filename": "main.py", "lineno": 207, "process": 60945, "message": "Starting execution..."}

Configuring StatsD

Victor Costa — Sat, 22 Jun 2019 14:46:34 +0000

Goal

Learn how to emit metrics with statsD.

What is StatsD

Statsd's description on its git repo is clear enough so let's just use it:

A network daemon that runs on the Node.js platform and listens for statistics, like counters and timers, sent over UDP or TCP and sends aggregates to one or more pluggable backend services (e.g., Graphite).

When to use and when not to use StatsD

You should not expect metrics generated with statsD to be 100% precise and extract business metrics from it (e.g: how many clients bought a product, or how many users registered for your newsletter) since data is sent over UDP (more on that below). Use statsD metrics to identify abnormalities in your services (e.g.: too many error statuses; methods taking too long to complete; etc).

Packages sent over User Datagram Protocol (UDP) do not have guaranteed delivery. More on that this wikipedia page.

Our current scenario and goal with statsd

Suppose we have an application which is accessed for not so many users and has an average of 10 login operations per minute. We will have a CloudWatch Alarm to notify us in case there is more than 30 unsuccessful login operations within a minute so we can find out what is going on. The application will emit events with statsD to CloudWatch using CloudWatch Agent.

Run StatsD locally

First make sure you have docker installed and running. Then run the following command:

docker run --rm\
 --name graphite\
 -p 80:80\
 -p 81:81\
 -p 2003-2004:2003-2004\
 -p 2023-2024:2023-2024\
 -p 8125:8125/udp\
 -p 8126:8126\
 hopsoft/graphite-statsd

You can already navigate to http://localhost:81 and see an empty graph from Graphite.

Our application

My application for this demo (Instructions on how to run that can be found in the README.MD of the repository.

Here is the part of the code that matters. For simplicity I kept everything in the same file:

Generate some metrics

Make some successful requests to our api:

for i in {1..30};
do
    curl -X POST -H 'Content-type: application/json' -i localhost:8080/v1/users/login -d '{"username": "firstuser", "password": "123"}'
done;

Now some requests with wrong credentials:

for i in {1..8};
do
    curl -X POST -H 'Content-type: application/json' -i localhost:8080/v1/users/login -d '{"username": "firstuser", "password": "wrong_passwd"}'
done;

Check graphite graph for the requests by navigating http://localhost:81 and open the directories in the left hand side: Metrics > stats_counts > my > custom > app > users > login and click the success and error metrics.

Change the range of time of the displayed data in the empty Graphite Composite panel by clicking the clock icon and set its Recent Time Range to 10 min.

Check your metrics

Dynamic scaling VS Fleet management scaling

Victor Costa — Wed, 05 Jun 2019 16:27:42 +0000

Aws Auto scaling divides into 2 categories: Fleet Management and Dynamic Scaling.

Fleet management

Used for:

Replacing unhealthy instances;
Distributing instances among availability-zones to maximize resilience; E.g: You're running instances in us-east, so auto-scaling can provision instances in the following AZs: us-east-1a, us-east-1b, us-east-1c, us-east-1d, and us-east-1e;

Dynamic scaling

Used for:

Scaling based on cloudWatch alarm metrics or a metric type (more on that later) when a threshold is met or different measures should be taken depending on the breach of a cloudWatch alarm threshold.

Types of Dynamic scaling

Simple scaling: Scales based on a single cloudwatch alarm metric, and apply the measures you define;
Step scaling: Scales based on different levels of cloud watch alarm metrics, and apply the actions you define;
Target tracking scaling: Scales based on a metric type, but delegates the action to be taken to AWS;

Which one to use?

That's not the right question to ask. Actually you'll be using Fleet Management out-of-the-box, with the possibility of configuring Dynamic Scaling to take some custom actions;

Let's go through some exemples:

To get to the auto-scaling configuration you should go to the EC2 dashboard and find Auto Scaling Groups in the sidebar. Select one auto-scaling group and find in the tabs below the auto-scaling groups listing the one called Scaling Policies

Fleet management: An application running on an EC2 instance stops responding health check, then auto-scaling stops routing traffic to it and moves that instance to quarantine to be analyzed, and spins up another instance one to replace it;

Dynamic scaling - Simple scaling: You have a cloudWatch alarm that monitors EC2 instances for cpu utilization and fires an alarm whenever it goes beyond 80% for 300 seconds (5 min). Your simple scaling policy defines the action to be taken is to spin up 1 more instance.

Dynamic scaling - Step scaling:

You have a cloudWatch alarm that monitors EC2 instances for cpu utilization and fires an alarm whenever it goes beyond 50% for 300 seconds (5 min). Your step scaling policy defines the action to be taken is to:

Spin up 1 more instance when cpu utilization is <= 50% and < 60%;
Spin up 3 more instances when cpu utilization is <= 60% and < 70%;
Spin up 5 more instances when cpu utilization is <= 70% and < infinity;

Keep in mind that these instances will add up, so if your cpu utilization goes progressively until 70% you'll end up having 9 EC2 instances;

Target tracking scaling:
You want to keep the cpu utilization of your fleet at 50%, but let AWS handle how many instances should be launched or terminated in order to keep that metric.

Good to know: Aws runs algorithms and defines how to best take actions to scale out/in your EC2 instances based on the receiving demand.

Metric types:

Application Load Balancer Request Count Per Target;
Average CPU Utilization;
Average Network In (Bytes);
Average Network Out (Bytes);

Let me know if it was all clear in the comments below or with a reaction.

References:

Local AWS environment with LocalStack

Victor Costa — Sun, 19 May 2019 12:59:05 +0000

Useful links

LocalStack

The definition used in their git repo is clear enough so let's just use it here:

LocalStack provides an easy-to-use test/mocking framework for developing Cloud applications

Setup

This tutorial uses a docker-image in order to setup Localstack, so you should have Docker and Docker-compose installed to move forward here.

Create a docker-compose.localstack.yml at the root of the project with the following content (which can be found here):

version: '2.1'
services:
...
  localstack:
    image: localstack/localstack
    ports:
      - "4567-4584:4567-4584"
      - "${PORT_WEB_UI-8080}:${PORT_WEB_UI-8080}"
    environment:
      - SERVICES=${SERVICES- }
      - DEBUG=${DEBUG- }
      - DATA_DIR=${DATA_DIR- }
      - PORT_WEB_UI=${PORT_WEB_UI- }
      - LAMBDA_EXECUTOR=${LAMBDA_EXECUTOR- }
      - KINESIS_ERROR_PROBABILITY=${KINESIS_ERROR_PROBABILITY- }
      - DOCKER_HOST=unix:///var/run/docker.sock
    volumes:
      - "${TMPDIR:-/tmp/localstack}:/tmp/localstack"

Spin up a Localstack docker container with s3 and dynamodb

For MacOS users (in case your $TMPDIR contains a symbolic link that cannot be mounted by Docker):

TMPDIR=/private$TMPDIR PORT_WEB_UI=9000 SERVICES=s3,dynamodb docker-compose -f docker-compose.localstack.yml up

Other users:

PORT_WEB_UI=9000 SERVICES=s3,dynamodb docker-compose -f docker-compose.localstack.yml up

ℹ️ Quick ref:
-f - Specify an alternate compose file (default: docker-compose.yml)
-d - Run as daemon process (in background)

⚠️ The names of the services to be used must follow the official aws services naming convention which can be found in aws available services

Useful docker commands:

docker ps: List running containers
docker logs <container-name>: Output logs container

Api calls to LocalStack

Visit http://localhost:9000 to make sure your local AWS is working. You're expected to see an empty dashboard.

Lets make some api calls to our local aws to check if we can start interacting with it.

🔎 Here is a complete user guide on aws-cli (Go to S3 section)

# Create a bucket
aws-vault exec scd-stg -- aws s3 mb s3://my-custom-bucket --endpoint-url http://localhost:4572

Expected output or similar: make_bucket: my-custom-bucket

# List buckets
aws-vault exec scd-stg -- aws s3 ls --endpoint-url http://localhost:4572

Expected output or similar: 2006-02-03 14:45:09 my-custom-bucket

Let me know if you had any issues in the comments below, or leave a reaction if everything worked as expected.

How to setup a spring-boot project

Victor Costa — Sun, 19 May 2019 12:44:59 +0000

Setup

To download SpringBoot go to start.spring.io and make sure your config is as follows (remember to replace the Group description, and to add the Web dependency):

With Intellij

File > New > Project from existing sources
Select Gradle option (since we've chose it to be our build and dependencies manager)
Select the Use auto-import option so dependencies can be automatically downloaded
Select the downloaded spring-boot folder
Wait until all dependencies are downloaded (This might take a few minutes)

With command-line

Install Gradle (Install maven if you chose it as your build and dependencies manager
Copy the downloaded folder to Intellij directory
Enter the folder and run gradle build (This command also run application tests)

Runing the project with Intellij

The right upper corner of your IDE there is this green play button. Just click on it and watch the IDE's terminal for a similar output:

2019-05-19 09:36:07.615  INFO 70436 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
2019-05-19 09:36:07.751  INFO 70436 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2019-05-19 09:36:07.754  INFO 70436 --- [           main] com.example.demo.DemoApplicationKt       : Started DemoApplicationKt in 1.826 seconds (JVM running for 2.28)
2019-05-19 09:36:12.131  INFO 70436 --- [       Thread-4] o.s.s.concurrent.ThreadPoolTaskExecutor  : Shutting down ExecutorService 'applicationTaskExecutor'

Runing the project with command-line

Inside the project's folder run gradle bootRun and for an output as presented above.

Let me know if you had any issues in the commends below, or leave a reaction if everything worked as expected.