Lightweight monitoring compatible with the sentry protocol, glitchtip

preamble

The previous post said something about restarting sentry

Because the process is so convoluted, I once thought of abandoning sentry for other lightweight open source monitoring systems.

And I found the other two.

Let's try this glitchtip this time

After using it, I realized that it is also developed with Django and is compatible with the sentry protocol, even the SDK uses sentry...

It's a lightweight alternative to sentry.

environmental preparation

Compared to sentry, glitchtip is very lightweight, using only redis and celery.

The log data resides in PostgreSQL.

This is very comfortable and much easier to deploy than heavyweight frameworks like sentry

The deployment in this article is based on the official docker-compose configuration.

PostgreSQL

First prepare the database

The official compose comes with a database, but I already have a database on my server, so I don't want to duplicate the containers.

services:
  db:
    image: postgres
    container_name: pgsql
    restart: unless-stopped
    environment:
      - POSTGRES_PASSWORD=Database administrator password
    expose:
      - 5432
    ports:
      - 5432:5432
    volumes:
      - ./data:/var/lib/postgresql/data
    networks:
      - default

networks:
  default:
    name: pgsql

Once pgsql is up and running, let's create the database and users used by glitchtip.

-- Create User: Use the CREATE ROLE or CREATE USER command to create a new user.
CREATE USER glitchtip WITH PASSWORD 'glitchtip user password';.

-- Assign permissions: To ensure that the glitchtip user can only access the glitchtip database, you need to set the appropriate permissions for that user.
GRANT ALL PRIVILEGES ON DATABASE glitchtip TO glitchtip;

-- Grant permission to create a table in public schema
GRANT CREATE ON SCHEMA public TO glitchtip;
-- Grants permission to use in public schema
GRANT USAGE ON SCHEMA public TO glitchtip; -- Grants permission to create a table in public schema.

The database's done here.

Extension: adminer

If you want to manage the database on the web, you can start an adminer service

services:
  adminer:
    image: adminer
    container_name: adminer
    restart: always
    networks:
      - swag
      - pgsql
      - mysql

networks:
  swag:
    name: swag
    external: true
  pgsql:
    name: pgsql
    external: true
  mysql:
    name: mysql
    external: true

Just do a little port 8000 reverse generation in swag after startup.

Redis

redis is lightweight, so it is recommended to use the glitchtip one, not the shared Redis one.

Unless it's clustered.

Install glitchtip

I modified the official compose configuration

There are a few things to keep in mind:

The e-mail address and password are required to use the() Escape, I'm still using corporate email here, but tried thesmtp://cap (a poem)smtps://I can't even send the prefix.
Removed the official top level volumes and put the data in the current directory for easy management. If you have a lot of data, you can consider changing OSS
Use the PostgreSQL database we deployed earlier, rather than starting a separate one in compose.

x-environment: &default-environment
  DATABASE_URL: postgres://glitchtip:glitchtipuser password@pgsql:5432/glitchtip
  SECRET_KEY: suggestion32random password # can be generated using the command openssl rand -hex 32
  PORT: 8000
  EMAIL_URL: smtp://E-mail address:Email Password@:465
  GLITCHTIP_DOMAIN:
  DEFAULT_FROM_EMAIL: E-mail address
  CELERY_WORKER_AUTOSCALE: "1,3"
  CELERY_WORKER_MAX_TASKS_PER_CHILD: "10000"

x-depends_on: &default-depends_on
  - redis

services:
  redis:
    image: redis
    restart: unless-stopped
    networks:
      - default
  
  web:
    image: glitchtip/glitchtip
    depends_on: *default-depends_on
    ports:
      - "8000:8000"
    environment: *default-environment
    restart: unless-stopped
    volumes:
      - ./uploads:/code/uploads
    networks:
      - default
      - pgsql
      - swag
  
  worker:
    image: glitchtip/glitchtip
    command: ./bin/
    depends_on: *default-depends_on
    environment: *default-environment
    restart: unless-stopped
    volumes:
      - ./uploads:/code/uploads
    networks:
      - default
      - pgsql
  
  migrate:
    image: glitchtip/glitchtip
    depends_on: *default-depends_on
    command: "./ migrate"
    environment: *default-environment
    networks:
      - pgsql
      - default

networks:
  default:
    name: glitchtip
  swag:
    name: swag
    external: true
  pgsql:
    name: pgsql
    external: true

Just start it up and be done with it.

After the first startup, you need to migrate, and the worker will report an error, it's fine, just wait for the migrate to complete.

The code uses the

Use only glitchtip

If you're just using glitchtip, just use it as a sentry.

import sentry_sdk
from sentry_sdk. import DjangoIntegration

sentry_sdk.init(
    dsn="YOUR-GLITCHTIP-DSN-HERE",
    integrations=[DjangoIntegration()],
    auto_session_tracking=False,
    traces_sample_rate=0.01,
    release="1.0.0",
    environment="production",
)

It's as simple as that.

Used in conjunction with sentry

PS: ~~That said, why use it at the same time as sentry?~~

sentry_sdk does not support initializing multiple instances at the same time by default

So with some extra logic to make this work

class GlitchtipSentrySdk:
    def __init__(self, dsn):
         = sentry_sdk.Hub(sentry_sdk.Client(dsn))

    def capture_exception(self, exc):
        with :
            sentry_sdk.capture_exception(exc)

glitchtip = GlitchtipSentrySdk('https://balabalaba@/1')

It's done.

wrap-up

Simply experiencing it, glitchtip is really a lot more rudimentary

But the most basic error-collecting features are still there

It's still good as a flat replacement for sentry if the server doesn't have enough performance.

There's also a highlight that I haven't deployed on yet, and it's a bit complicated to configure in there.